RED HAT ENTERPRISE LINUX

SSH Security

Host Keys and Key-Based Authentication

College-Level Course Module | RHEL System Administration

Welcome to this essential module on securing SSH communication. SSH, the Secure Shell, is the primary method for remote system administration in Linux. Every time you connect to a server, transfer files, or run remote commands, SSH protects that communication. But SSH security goes beyond just encrypting traffic. You need to verify you are connecting to the right server (host key verification) and prove who you are without transmitting passwords (key-based authentication). In this module, you will learn how SSH encryption protects your connections, how host keys verify server identity and prevent man-in-the-middle attacks, how to generate and manage SSH key pairs, how to configure key-based authentication for passwordless but secure login, and how to harden SSH configuration for better security. These skills are critical for securing your infrastructure and are tested on the RHCSA exam.

Learning Objectives

Understand SSH security concepts

Encryption, authentication, and the SSH protocol

Manage host keys

Verify server identity and handle host key changes

Generate SSH key pairs

Create public/private key pairs with ssh-keygen

Configure key-based authentication

Deploy public keys and authenticate without passwords

Harden SSH configuration

Secure SSH server settings and best practices

Why SSH Security Matters

SSH (Secure Shell) provides encrypted communication between systems. It protects against eavesdropping, connection hijacking, and other attacks on remote sessions.

Without SSH (Telnet, rsh):

Passwords sent in clear text
Data visible to network sniffers
No server verification
Vulnerable to man-in-the-middle

With SSH:

All traffic encrypted
Server identity verified
Strong authentication options
Protection from interception

SSH uses: Remote shell access, secure file transfer (scp, sftp), tunneling, port forwarding, and Git operations.

SSH exists because the old remote access tools were dangerously insecure. Telnet, rsh, and rlogin sent everything in clear text - including passwords. Anyone sniffing the network could capture credentials and data. SSH solves these problems with encryption. Every byte between client and server is encrypted, so eavesdroppers see only garbage. Server identity verification prevents man-in-the-middle attacks where an attacker impersonates the server. Strong authentication options include passwords (encrypted in transit) and key-based authentication (no password transmitted at all). SSH is used for far more than just remote shells. scp and sftp transfer files securely. SSH tunneling forwards ports through encrypted connections. Git uses SSH for authenticated repository access. Understanding SSH security protects all of these use cases.

SSH Architecture

SSH Client
(your machine)

↔

Encrypted
Connection

↔

SSH Server
(sshd daemon)

Component	Location	Purpose
ssh	Client	Connect to remote servers
sshd	Server	Accept incoming connections
Host keys	Server (/etc/ssh/)	Prove server identity
User keys	Client (~/.ssh/)	Prove user identity
known_hosts	Client (~/.ssh/)	Remember trusted servers
authorized_keys	Server (~/.ssh/)	Accepted public keys for login

# SSH client connects to SSH server (sshd)
[user@client ~]$ ssh user@server.example.com

SSH has a client-server architecture. The ssh client on your local machine initiates connections. The sshd daemon on the remote server accepts connections. All communication flows through an encrypted channel. Several key files are involved. On the server, host keys in /etc/ssh prove the server's identity. These are generated when the SSH server is first installed. On the client, ~/.ssh/known_hosts stores fingerprints of servers you have connected to, so you can detect if a server's identity changes. For key-based authentication, you have user keys. The private key stays on the client in ~/.ssh. The public key goes to the server's ~/.ssh/authorized_keys file. When you connect, the server challenges you to prove you have the private key matching an authorized public key. Understanding this architecture helps you troubleshoot connection issues and configure SSH properly.

Host Keys Explained

Host keys are cryptographic keys that identify an SSH server. They prove you are connecting to the real server, not an imposter.

# Server's host keys (on the server)
[root@server ~]# ls -la /etc/ssh/ssh_host_*
-rw-r-----. 1 root ssh_keys  480 Jan 15 ssh_host_ecdsa_key
-rw-r--r--. 1 root root      162 Jan 15 ssh_host_ecdsa_key.pub
-rw-r-----. 1 root ssh_keys  387 Jan 15 ssh_host_ed25519_key
-rw-r--r--. 1 root root       82 Jan 15 ssh_host_ed25519_key.pub
-rw-r-----. 1 root ssh_keys 2590 Jan 15 ssh_host_rsa_key
-rw-r--r--. 1 root root      554 Jan 15 ssh_host_rsa_key.pub

Key Types:

ed25519 - Modern, fast, secure (preferred)
ecdsa - Elliptic curve (good)
rsa - Traditional (3072+ bits recommended)

Files:

Private key: ssh_host_*_key (secret!)
Public key: ssh_host_*_key.pub
Permissions must be restrictive

Host keys are how servers prove their identity. When you connect to a server, it presents its host key. Your client checks this against known good values to verify you are talking to the real server. Each server has multiple host key pairs in /etc/ssh - one for each algorithm type. ed25519 is the modern choice - fast, secure, with small keys. ecdsa uses elliptic curve cryptography. rsa is the traditional algorithm, still widely used, requiring larger keys for equivalent security. Each key type has a private key and public key. The private key (no .pub extension) must be kept secret - only readable by root and the ssh_keys group. If an attacker gets the private key, they can impersonate the server. The public key (.pub) can be shared freely. Host keys are generated automatically when sshd is first installed. If you reinstall the OS or regenerate keys, clients will see the key has changed.

First Connection

# First time connecting to a server
[user@client ~]$ ssh user@server.example.com
The authenticity of host 'server.example.com (192.168.1.100)' can't be established.
ED25519 key fingerprint is SHA256:AbCdEf1234567890xYzAbCdEf1234567890xYz.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'server.example.com' (ED25519) to the list of known hosts.

Security moment: This prompt is asking "Do you trust this server?" You should verify the fingerprint through a separate channel before typing "yes".

# On the server: get the fingerprint to verify
[root@server ~]# ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
256 SHA256:AbCdEf1234567890xYzAbCdEf1234567890xYz root@server (ED25519)

Verification methods: Console access, phone call to admin, published fingerprints, configuration management

The first time you connect to a server, SSH cannot verify the server's identity because it has no prior knowledge of the key. It shows you the key fingerprint and asks if you want to trust it. This is a critical security moment. If you blindly type yes, you could be connecting to an attacker's machine that intercepted your connection. The fingerprint should be verified through an out-of-band channel. Options include logging into the server console to check the fingerprint, calling the administrator to confirm it, checking documentation where fingerprints are published, or using configuration management that pre-populates known_hosts. ssh-keygen -lf displays the fingerprint of a key file. Run this on the server to get the correct value to compare. After you type yes, the server's public key is added to ~/.ssh/known_hosts. Future connections will verify against this stored value.

The known_hosts File

~/.ssh/known_hosts stores public keys of servers you have connected to. SSH uses this to detect if a server's identity changes.

# View known_hosts
[user@client ~]$ cat ~/.ssh/known_hosts
server.example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBcd...
192.168.1.100 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBcd...
webserver.lab ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC...

# Show fingerprints in known_hosts
[user@client ~]$ ssh-keygen -lf ~/.ssh/known_hosts
256 SHA256:AbCdEf... server.example.com (ED25519)
256 SHA256:AbCdEf... 192.168.1.100 (ED25519)
3072 SHA256:XyZabc... webserver.lab (RSA)

# System-wide known hosts (all users)
/etc/ssh/ssh_known_hosts

# Remove a specific host entry
[user@client ~]$ ssh-keygen -R server.example.com
# Host server.example.com found: line 1
/home/user/.ssh/known_hosts updated.

known_hosts is your client's memory of trusted servers. Each line contains a hostname or IP address and the server's public key. When you connect to a server, SSH checks if the presented key matches what is stored in known_hosts. The file can contain multiple entries for the same server if you connect via different names or IP addresses. You might have entries for both server.example.com and 192.168.1.100 if they are the same machine. ssh-keygen -lf displays the fingerprints in a more readable format. This helps you audit what servers you trust. There is also a system-wide file /etc/ssh/ssh_known_hosts that applies to all users. Administrators can pre-populate this with known good server keys. ssh-keygen -R removes a specific host from known_hosts. You need this when a server's key legitimately changes - for example, after OS reinstallation.

Host Key Changed Warning

[user@client ~]$ ssh user@server.example.com
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:NewFingerprint1234567890abcdef.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:1
Host key for server.example.com has changed and you have requested strict checking.
Host key verification failed.

This warning means: The server's key is different from what you previously accepted. This could be an attack OR a legitimate change (server rebuild, key rotation).

This alarming warning appears when the server presents a different key than what is stored in known_hosts. SSH refuses to connect because this could indicate a man-in-the-middle attack - an attacker intercepting your connection. However, there are legitimate reasons for key changes: the server was rebuilt or reinstalled, the operating system was upgraded, the administrator rotated the host keys, or you are connecting to a different server that now has that hostname or IP address. The critical question is: why did the key change? You must verify through an out-of-band channel before proceeding. Contact the administrator, check change management records, or access the server console to verify the new fingerprint. Never blindly remove the old key and accept the new one without verification - that defeats the entire purpose of host key checking.

Resolving Host Key Issues

# Step 1: Verify the key change is legitimate
# (Contact admin, check console, verify through secure channel)

# Step 2: Remove the old key
[user@client ~]$ ssh-keygen -R server.example.com
# Host server.example.com found: line 1
/home/user/.ssh/known_hosts updated.
Original contents retained as /home/user/.ssh/known_hosts.old

# Also remove by IP if you used that
[user@client ~]$ ssh-keygen -R 192.168.1.100

# Step 3: Connect again and verify new fingerprint
[user@client ~]$ ssh user@server.example.com
The authenticity of host 'server.example.com (192.168.1.100)' can't be established.
ED25519 key fingerprint is SHA256:NewFingerprint1234567890abcdef.
Are you sure you want to continue connecting (yes/no)? yes

# Alternative: manually edit known_hosts
[user@client ~]$ vim ~/.ssh/known_hosts
# Delete the offending line, save, reconnect

When you have verified that a host key change is legitimate, here is how to resolve it. First, remove the old key with ssh-keygen -R. This removes entries matching that hostname. A backup of the original file is saved with .old extension. If you connected via multiple names or IPs, remove each one. For example, both the hostname and the IP address might have entries. Then connect again. You will see the first-connection prompt for the new key. Verify this fingerprint matches what the administrator told you or what you saw on the server console. Alternatively, you can manually edit known_hosts with a text editor. The warning message tells you which line number contains the offending key. Delete that line, save, and reconnect. The key point is verification before removal. Removing a key and accepting a new one without verification makes you vulnerable to the exact attack that host key verification is designed to prevent.

Key-Based Authentication

Key-based authentication uses cryptographic key pairs instead of passwords. It is more secure and enables passwordless login.

🔐

Private Key

~/.ssh/id_ed25519

KEEP SECRET!

↔

🔓

Public Key

~/.ssh/id_ed25519.pub

Share freely

How it works: Your private key proves your identity. The server has your public key and challenges you to prove you have the matching private key - without ever transmitting it.

Key-based authentication replaces password transmission with cryptographic proof. Instead of sending a password over the network, you prove you possess a private key that matches a public key the server knows about. You generate a key pair - a private key and matching public key. The private key stays on your machine and must be kept secret. If anyone gets your private key, they can impersonate you. The public key is placed on servers you want to access. It goes in ~/.ssh/authorized_keys on each server. When you connect, the server sends a challenge encrypted with your public key. Only someone with the matching private key can decrypt and respond correctly. Your private key never leaves your machine. This is more secure than passwords for several reasons: no password is transmitted, keys are much longer than passwords (256+ bits versus perhaps 8-12 characters), and keys cannot be guessed or brute-forced practically.

Generating Key Pairs

# Generate an Ed25519 key (recommended)
[user@client ~]$ ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519): [Enter for default]
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase): [Enter strong passphrase]
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_ed25519
Your public key has been saved in /home/user/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:YourKeyFingerprint1234567890 user@client
The key's randomart image is:
+--[ED25519 256]--+
|     .o+*O=+o    |
|     ..oB+*.     |
...

# Generate RSA key (if Ed25519 not supported)
[user@client ~]$ ssh-keygen -t rsa -b 4096

# Generate with specific filename
[user@client ~]$ ssh-keygen -t ed25519 -f ~/.ssh/work_key

ssh-keygen creates your key pair. The -t option specifies the key type. Ed25519 is the modern recommendation - it is fast, secure, and produces small keys. For older systems that do not support Ed25519, use RSA with at least 4096 bits. The command asks where to save the key. The default ~/.ssh/id_ed25519 works for most situations. Press Enter to accept it. You can specify a different filename if you need multiple keys for different purposes. The passphrase protects your private key. Even if someone gets the key file, they cannot use it without the passphrase. You can leave it empty for truly passwordless operation, but this means anyone who gets your key file can use it. A passphrase is strongly recommended. The command creates two files: the private key (no extension) and the public key (.pub). The randomart image is a visual representation that some people use to verify keys at a glance.

Examining Your Keys

# View files in .ssh directory
[user@client ~]$ ls -la ~/.ssh/
drwx------. 2 user user   80 Jan 20 10:00 .
-rw-------. 1 user user  419 Jan 20 10:00 id_ed25519
-rw-r--r--. 1 user user   96 Jan 20 10:00 id_ed25519.pub
-rw-r--r--. 1 user user  442 Jan 20 10:00 known_hosts

# View public key (this is what you share)
[user@client ~]$ cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBcd... user@client

# View key fingerprint
[user@client ~]$ ssh-keygen -lf ~/.ssh/id_ed25519.pub
256 SHA256:YourKeyFingerprint1234567890 user@client (ED25519)

# NEVER share or display your private key!
# Private key should only be readable by you (mode 600)

Permissions are critical: Private key must be mode 600 (owner read/write only). SSH refuses to use keys with wrong permissions.

After generating keys, examine what was created. The .ssh directory should have permissions 700 (rwx for owner only). The private key must be 600 (rw for owner only). SSH enforces this - if permissions are too open, it refuses to use the key because it could have been read by others. The public key can be readable by anyone (644 is fine) since it is not secret. Your public key is a single long line starting with the key type (ssh-ed25519), followed by the key data, and ending with a comment (usually user@hostname). This entire line goes into authorized_keys on servers. The fingerprint is a shorter representation of the key, useful for verification. You can compare fingerprints rather than entire key strings. Never share, display, or transmit your private key. Never paste it into websites, emails, or chat. If you suspect it was compromised, generate a new key pair and remove the old public key from all servers.

Deploying Public Keys

Copy your public key to the server's ~/.ssh/authorized_keys file to enable key-based login.

# Method 1: ssh-copy-id (easiest, recommended)
[user@client ~]$ ssh-copy-id user@server.example.com
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/user/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s)
user@server.example.com's password: [enter password]
Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'user@server.example.com'"
and check to make sure that only the key(s) you wanted were added.

# Method 2: Manual copy (if ssh-copy-id unavailable)
[user@client ~]$ cat ~/.ssh/id_ed25519.pub | ssh user@server 'mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'

# Method 3: Copy and paste manually
# 1. cat ~/.ssh/id_ed25519.pub (copy output)
# 2. SSH to server with password
# 3. Paste into ~/.ssh/authorized_keys

To use key-based authentication, your public key must be in the server's authorized_keys file. There are several ways to get it there. ssh-copy-id is the easiest method. It handles creating the .ssh directory if needed, setting correct permissions, and appending your key. You authenticate with your password this one time, then future connections use the key. For manual deployment, you can pipe your public key over SSH to append it to authorized_keys. The command also creates the directory and sets permissions. This works when ssh-copy-id is not available. The manual copy-paste method works when all else fails. Display your public key, copy it, SSH to the server with a password, and paste it into authorized_keys using a text editor. Whatever method you use, verify permissions afterward. The .ssh directory must be 700, and authorized_keys must be 600 or 644. SSH is strict about permissions.

Using Key-Based Auth

# Connect using your key (key is used automatically)
[user@client ~]$ ssh user@server.example.com
Enter passphrase for key '/home/user/.ssh/id_ed25519': [passphrase if set]
Last login: Mon Jan 20 10:30:00 2024
[user@server ~]$

# Specify a different key file
[user@client ~]$ ssh -i ~/.ssh/work_key user@server.example.com

# Verbose mode to troubleshoot authentication
[user@client ~]$ ssh -v user@server.example.com
...
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:abc...
debug1: Server accepts key: /home/user/.ssh/id_ed25519 ED25519 SHA256:abc...
debug1: Authentication succeeded (publickey).
...

# If key auth fails, SSH falls back to password

Success! If you set a passphrase, you enter it locally - it is never transmitted. If no passphrase, login is completely passwordless.

Once your public key is deployed, SSH automatically uses key-based authentication. When you connect, SSH offers your private key. If it matches an authorized public key on the server, you are in. If you set a passphrase on your private key, you enter it locally. The passphrase decrypts your private key for use - it is never sent over the network. With no passphrase, login is completely passwordless. The -i option specifies a different key file if you have multiple keys. This is useful when different servers require different keys. Verbose mode (-v) shows the authentication process. You can see SSH offering keys, the server accepting or rejecting them, and which method succeeded. Use this to troubleshoot authentication problems. If key authentication fails (wrong key, missing from authorized_keys, permission problems), SSH typically falls back to password authentication. You can configure the server to require keys and reject passwords entirely.

SSH Agent

ssh-agent caches your private keys in memory, so you only enter the passphrase once per session instead of every connection.

# Start ssh-agent (often already running in desktop environments)
[user@client ~]$ eval $(ssh-agent)
Agent pid 12345

# Add your key to the agent
[user@client ~]$ ssh-add
Enter passphrase for /home/user/.ssh/id_ed25519: [passphrase]
Identity added: /home/user/.ssh/id_ed25519 (user@client)

# Add a specific key
[user@client ~]$ ssh-add ~/.ssh/work_key

# List loaded keys
[user@client ~]$ ssh-add -l
256 SHA256:YourFingerprint user@client (ED25519)

# Remove all keys from agent
[user@client ~]$ ssh-add -D
All identities removed.

Agent forwarding: ssh -A forwards your agent to the remote server, allowing onward SSH connections using your local keys.

If you have a passphrase on your key (which you should), entering it for every SSH connection gets tedious. ssh-agent solves this. The agent runs in the background and holds your decrypted private keys in memory. SSH clients can ask the agent to perform key operations without needing the key file directly. eval $(ssh-agent) starts the agent and sets environment variables so SSH knows how to contact it. Desktop environments often start an agent automatically. ssh-add loads keys into the agent. With no arguments, it loads the default key (~/.ssh/id_ed25519 or similar). You enter the passphrase once, then subsequent SSH connections do not require it. ssh-add -l lists loaded keys. ssh-add -D clears all keys from the agent - useful if you're stepping away from your workstation. Agent forwarding (-A) is a powerful feature that lets you use your local keys from a remote server. You SSH to server A, then from there SSH to server B, using your local keys for both connections. Be cautious - if server A is compromised, an attacker could use your forwarded agent.

The authorized_keys File

# View authorized_keys on server
[user@server ~]$ cat ~/.ssh/authorized_keys
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBcd... user@client
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIXyz... user@laptop
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAB... admin@workstation

# Each line is one authorized public key
# Format: key-type key-data comment

# Add restrictions to a key
from="192.168.1.*",no-port-forwarding ssh-ed25519 AAAAC3... user@client

# Common restrictions:
# from="pattern"      - Only allow from specific hosts/IPs
# command="cmd"       - Only run this command
# no-port-forwarding  - Disable port forwarding
# no-X11-forwarding   - Disable X11 forwarding
# no-pty              - Disable terminal allocation

Permissions: authorized_keys must be mode 600 (rw-------) and owned by the user. SSH ignores it if permissions are wrong.

authorized_keys is the gatekeeper for key-based authentication. Each line contains one public key that is allowed to log in as this user. The format is key-type, key-data, and an optional comment. The comment helps identify whose key it is. You can have multiple keys - one per line. This allows login from multiple machines or allows multiple people to access an account. You can add restrictions at the beginning of a line. from="pattern" limits which hosts can use that key - useful for restricting access to known IPs. command="cmd" forces a specific command to run instead of a shell - useful for restricted backup accounts. Various no-* options disable specific features. Permissions are critical. The file must be readable only by the owner. If group or world can read it, SSH assumes it might have been tampered with and ignores it. The .ssh directory must also have restrictive permissions (700).

SSH Server Configuration

The SSH server (sshd) is configured in /etc/ssh/sshd_config. Adjust settings to harden security.

[root@server ~]# vim /etc/ssh/sshd_config

# Key security settings:
PermitRootLogin no              # Disable direct root login
PasswordAuthentication no        # Require key-based auth only
PubkeyAuthentication yes         # Enable key-based auth
AuthorizedKeysFile .ssh/authorized_keys  # Key file location

# Limit access
AllowUsers alice bob             # Only these users can SSH
AllowGroups sshusers             # Or only members of this group

# Other hardening
X11Forwarding no                 # Disable X11 forwarding
MaxAuthTries 3                   # Limit auth attempts
ClientAliveInterval 300          # Timeout idle connections
ClientAliveCountMax 2

# After changes, restart sshd
[root@server ~]# systemctl restart sshd

The sshd configuration file controls server behavior. Several settings are important for security. PermitRootLogin controls whether root can log in directly. Set to no and use sudo instead - this provides accountability and prevents brute-force attacks on the root password. PasswordAuthentication set to no disables password login entirely, requiring keys. This eliminates password guessing attacks. Only do this after verifying key-based auth works! PubkeyAuthentication yes enables key-based authentication (usually the default). AllowUsers and AllowGroups restrict who can SSH in. Even if someone has valid credentials, they cannot connect unless listed. This is useful for limiting SSH access to specific administrators. X11Forwarding no disables X11 forwarding if you do not need it, reducing attack surface. MaxAuthTries limits failed attempts before disconnecting. ClientAlive settings timeout idle connections. After modifying sshd_config, restart the service. Keep an existing session open while testing - if you lock yourself out, you can fix it from the existing session.

Disabling Password Auth

Warning: Only disable password authentication AFTER verifying key-based auth works! Otherwise you will lock yourself out.

# Step 1: Verify key-based auth works
[user@client ~]$ ssh -o PasswordAuthentication=no user@server
# If this works, you're safe to proceed

# Step 2: Edit sshd_config on server
[root@server ~]# vim /etc/ssh/sshd_config
PasswordAuthentication no

# Step 3: Restart sshd (keep current session open!)
[root@server ~]# systemctl restart sshd

# Step 4: Test from another terminal
[user@client ~]$ ssh user@server
# Should connect using key, no password prompt

# If locked out and have console access:
[root@server ~]# vim /etc/ssh/sshd_config
# Change back to: PasswordAuthentication yes
[root@server ~]# systemctl restart sshd

Disabling password authentication is a major security improvement - it eliminates password guessing attacks entirely. But it is also dangerous if done incorrectly. Before disabling, verify key-based authentication works. Test with ssh -o PasswordAuthentication=no to force key-only auth. If you can log in, your keys are working. Keep an existing SSH session open while making changes. If something goes wrong, you can fix it from that session without needing console access. Edit sshd_config and set PasswordAuthentication to no. Restart sshd. Then test from a new terminal - try to connect and verify you get in without a password prompt. If you get locked out and have console or out-of-band access, you can edit the config and re-enable passwords. This is why you always maintain some alternative access method during changes. Consider also setting ChallengeResponseAuthentication to no, as some configurations can still allow password-like prompts through that mechanism.

SSH Client Config

~/.ssh/config stores client-side settings for SSH connections. Define aliases, specify keys, and set options per host.

[user@client ~]$ cat ~/.ssh/config

# Default settings for all hosts
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

# Shortcut for production server
Host prod
    HostName production.example.com
    User admin
    IdentityFile ~/.ssh/prod_key
    Port 2222

# Jump through bastion host
Host internal
    HostName 10.0.0.50
    User developer
    ProxyJump bastion.example.com

# Now you can simply type:
[user@client ~]$ ssh prod
# Instead of: ssh -i ~/.ssh/prod_key -p 2222 admin@production.example.com

The client config file makes SSH much more convenient. Instead of remembering long command lines with multiple options, you define everything in the config and use simple aliases. Host * applies settings to all connections. ServerAliveInterval sends keepalives to prevent idle disconnection. Named host sections define connection profiles. Host prod creates an alias. HostName specifies the actual server. User sets the default username. IdentityFile specifies which key to use. Port sets a non-standard port. With this config, ssh prod is equivalent to the full command with all options. ProxyJump is powerful for bastion/jump host setups. SSH connects to the bastion first, then through it to the internal server. This is cleaner than manual port forwarding or multiple SSH commands. The config file has many more options. You can set preferred ciphers, enable or disable forwarding, set connection timeouts, and more. This file is not created by default - create it as needed.

Best Practices

Do

Verify host key fingerprints
Use Ed25519 keys when possible
Set passphrases on private keys
Use ssh-agent to cache keys
Disable password auth after key setup
Disable direct root login
Keep an open session during config changes
Restrict SSH access with AllowUsers

Do Not

Ignore host key warnings
Share private keys
Use weak or no passphrases
Store private keys on shared systems
Disable password auth before testing keys
Use RSA keys smaller than 3072 bits
Forward agent to untrusted servers
Leave default SSH port if targeted

Recovery plan: Always have console access or out-of-band management before making SSH changes that could lock you out.

Let me summarize security best practices. Always verify host key fingerprints - never blindly accept. This is your protection against man-in-the-middle attacks. Use Ed25519 keys - they are modern, fast, and secure. Fall back to RSA with at least 3072 bits if Ed25519 is not supported. Set passphrases on private keys. Even if your key file is stolen, the attacker cannot use it without the passphrase. Use ssh-agent to avoid typing the passphrase repeatedly. Disable password authentication after verifying key-based auth works. This eliminates password attacks. Disable direct root login and use sudo for accountability. Restrict who can SSH in with AllowUsers or AllowGroups. Never share private keys - each user should have their own. Never ignore host key warnings without investigation. Never disable password auth before testing keys - you will lock yourself out. Be careful with agent forwarding to untrusted servers. Always have a fallback access method (console, IPMI, cloud console) before making SSH config changes.

Key Takeaways

Host Keys: Verify server identity. Check fingerprints on first connect. Investigate changed keys - could be attack or legitimate change.

Key Pairs: Generate with ssh-keygen -t ed25519. Private key stays secret, public key goes to servers.

Key Auth: Deploy with ssh-copy-id. Keys go in ~/.ssh/authorized_keys. More secure than passwords.

Hardening: Disable password auth, disable root login, use AllowUsers. Configure in /etc/ssh/sshd_config.

LAB EXERCISES

Generate an Ed25519 key pair with a passphrase
Deploy your public key to a remote server
Verify key-based authentication works
Use ssh-agent to cache your key
Examine and modify known_hosts
Disable password authentication on a test server
Create SSH client config shortcuts

Next: Secure File Transfer with scp and sftp

Let me summarize the key points about SSH security. Host keys verify server identity. On first connection, verify the fingerprint through a secure out-of-band channel. When keys change, investigate before accepting - it could be an attack. known_hosts stores accepted keys for future verification. Key pairs enable authentication without transmitting passwords. Generate Ed25519 keys with ssh-keygen. The private key is secret and stays on your machine. The public key is deployed to servers. Use a passphrase to protect the private key. Key-based authentication is deployed with ssh-copy-id, which places your public key in authorized_keys on the server. This is more secure than passwords and enables passwordless operation when combined with ssh-agent. For hardening, disable password authentication after verifying keys work, disable direct root login, and restrict access with AllowUsers. All server settings are in /etc/ssh/sshd_config. Your lab exercises provide hands-on practice with the complete key-based authentication workflow.