RED HAT ENTERPRISE LINUX

Securing SSH Communication

Host Keys and Key-Based Authentication

CIS126RH | RHEL System Administration 1
Mesa Community College

Welcome to this essential security module on protecting SSH communication in Red Hat Enterprise Linux. SSH (Secure Shell) is the primary way administrators access Linux servers remotely, making its security absolutely critical. A compromised SSH connection gives attackers complete control over your systems. In this module, we'll cover two major aspects of SSH security. First, we'll learn about host keys - how servers prove their identity to clients, preventing man-in-the-middle attacks. You'll understand what happens when you see "the authenticity of host can't be established" and why that fingerprint matters. Second, we'll implement key-based authentication - replacing passwords with cryptographic keys. This is more secure, more convenient once set up, and can be required as part of a security policy. We'll generate key pairs, distribute public keys, and configure SSH to require key authentication. These skills are fundamental for secure system administration and essential for the RHCSA exam.

Learning Objectives

Understand SSH host keys

Explain how host keys verify server identity and prevent MITM attacks

Manage known hosts

Handle host key verification, updates, and the known_hosts file

Generate SSH key pairs

Create secure RSA and Ed25519 keys with appropriate passphrases

Configure key-based authentication

Deploy public keys and optionally disable password authentication

We have four main learning objectives for this module. First, we'll understand SSH host keys. When you connect to a server, how do you know you're really connecting to that server and not an attacker? Host keys provide cryptographic proof of the server's identity. We'll explore how this works and why it matters. Second, we'll manage known hosts. Your SSH client remembers servers it's connected to before. We'll learn how this works, what to do when host keys change, and how to handle the known_hosts file properly. Third, we'll generate SSH key pairs. You'll create your own public and private keys using modern, secure algorithms. We'll discuss key types, key lengths, and the importance of passphrases for protecting private keys. Fourth, we'll configure key-based authentication end-to-end. You'll deploy your public key to servers, test authentication, and learn how to disable password authentication entirely for maximum security. This is the gold standard for SSH access in enterprise environments.

SSH Security Overview

SSH (Secure Shell) provides encrypted communication between systems. Security depends on verifying both the server (host keys) and the user (authentication).

Encryption

All traffic is encrypted, protecting data from eavesdropping

Host Verification

Host keys prove server identity, preventing MITM attacks

User Authentication

Passwords or keys verify the user's identity

Integrity

MACs detect any tampering with transmitted data

⚠ Critical: Encryption alone isn't enough. Without host verification, an attacker could intercept your connection and decrypt everything.

Before diving into specifics, let's understand what makes SSH secure and where vulnerabilities can exist. SSH provides multiple layers of security. Encryption protects all data transmitted between client and server. Even if someone captures your network traffic, they can't read it. SSH negotiates encryption algorithms when connecting. Host verification is often overlooked but critical. When you connect to a server, how do you know it's really that server? Without verification, an attacker could intercept your connection (man-in-the-middle attack), pretend to be the server, capture your password, and relay everything to the real server. You'd never know. Host keys solve this. User authentication proves to the server that you are who you claim to be. Passwords are familiar but have weaknesses - they can be guessed, stolen, or captured. SSH keys are stronger because they require possession of the private key file, not just knowledge of a secret. Integrity checking (MACs - Message Authentication Codes) ensures data isn't modified in transit. If an attacker somehow modified encrypted packets, the MAC verification would fail. The key insight: encryption without authentication is dangerous. If you ignore host key warnings and connect anyway, your "encrypted" connection might be to an attacker who decrypts, reads everything, then re-encrypts to the real server. Always verify host keys.

Understanding Host Keys

Every SSH server has host key pairs that uniquely identify it. When you connect, the server proves its identity using these keys.

# Server's host keys are stored in /etc/ssh/
[root@server ~]# ls -la /etc/ssh/ssh_host_*
-rw-r-----. 1 root ssh_keys  480 Jan 15 10:30 /etc/ssh/ssh_host_ecdsa_key
-rw-r--r--. 1 root root      162 Jan 15 10:30 /etc/ssh/ssh_host_ecdsa_key.pub
-rw-r-----. 1 root ssh_keys  387 Jan 15 10:30 /etc/ssh/ssh_host_ed25519_key
-rw-r--r--. 1 root root       82 Jan 15 10:30 /etc/ssh/ssh_host_ed25519_key.pub
-rw-r-----. 1 root ssh_keys 2578 Jan 15 10:30 /etc/ssh/ssh_host_rsa_key
-rw-r--r--. 1 root root      550 Jan 15 10:30 /etc/ssh/ssh_host_rsa_key.pub

Key Type	Files	Notes
Ed25519	ssh_host_ed25519_key[.pub]	Modern, fast, recommended
ECDSA	ssh_host_ecdsa_key[.pub]	Elliptic curve, widely supported
RSA	ssh_host_rsa_key[.pub]	Legacy compatibility, use 3072+ bits

Host keys are how SSH servers prove their identity. Each server generates unique key pairs during installation or first boot. The private key stays secret on the server; the public key is shared with connecting clients. Multiple key types exist for compatibility with different clients. Ed25519 is the newest and recommended - it's fast, secure, and has small keys. ECDSA uses elliptic curve cryptography and is widely supported. RSA is the oldest, still used for compatibility with legacy clients. Notice the permissions: private keys are readable only by root and the ssh_keys group (mode 640 or 600). Public keys are world-readable (644). If private key permissions are wrong, SSH will refuse to start - this is a security protection. Each key type has both a private key file (no extension) and public key file (.pub). The server uses all available key types and negotiates with connecting clients to use a mutually supported algorithm. When clients connect, they receive the server's public host key and can verify it matches what they expect. If it doesn't match, something is wrong - either the server changed legitimately, or an attacker is intercepting the connection.

First Connection: Verification

[student@workstation ~]$ ssh student@server.example.com
The authenticity of host 'server.example.com (192.168.1.100)' can't be established.
ED25519 key fingerprint is SHA256:xH7vK9mPqL2nR4wY8sT6uB3fJ5aD1eG9hC0iZ2kM7nQ.
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.
student@server.example.com's password:

The fingerprint is a hash of the public key:

SHA256:xH7vK9mPqL2nR4wY8sT6uB3fJ5aD1eG9hC0iZ2kM7nQ

⚠ Security Decision: Don't blindly type "yes"! In secure environments, verify the fingerprint through an out-of-band channel (phone call, secure document, physical access).

This prompt is one of the most important security decisions in SSH, yet it's often dismissed without thought. Let's understand what's happening. When you first connect to a server, your client has never seen it before. The server sends its public host key, but how do you know this key really belongs to the server and not an attacker? The client displays the key's fingerprint - a hash that uniquely identifies the key - and asks you to verify. The fingerprint is a SHA256 hash of the public key. It's shorter and easier to compare than the full key. In high-security environments, you should verify this fingerprint through another channel: call the server's administrator and read it to them, check it against documentation, or verify it during physical server setup. In practice, many people just type "yes" - this is a calculated risk. On a trusted network connecting to a known server, it's usually fine. On untrusted networks or connecting to critical systems, verification matters more. Once you accept, the key is saved to ~/.ssh/known_hosts. Future connections compare against this saved value automatically. If they match, connection proceeds silently. If they don't match, you get a loud warning - that's the protection kicking in.

The known_hosts File

# Client stores known host keys in ~/.ssh/known_hosts
[student@workstation ~]$ cat ~/.ssh/known_hosts
server.example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...
192.168.1.100 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...
webserver.lab.local ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNo...

# View fingerprints of known hosts
[student@workstation ~]$ ssh-keygen -l -f ~/.ssh/known_hosts
256 SHA256:xH7vK9mPqL2nR4wY8sT6uB3fJ5aD1eG9hC0iZ2kM7nQ server.example.com (ED25519)
256 SHA256:xH7vK9mPqL2nR4wY8sT6uB3fJ5aD1eG9hC0iZ2kM7nQ 192.168.1.100 (ED25519)
256 SHA256:aB3cD4eF5gH6iJ7kL8mN9oP0qR1sT2uV3wX4yZ5aB6c webserver.lab.local (ECDSA)

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

Format: Each line contains: hostname[,IP] key-type public-key. A host may have multiple entries for different key types or names.

The known_hosts file is your SSH client's memory of servers it has connected to. Understanding this file helps you manage host key verification. Each line contains a hostname (and optionally IP address), the key type, and the public key. When you connect by hostname, SSH also stores the IP address if resolved. This means the same server might have multiple entries - one for its hostname, one for its IP. The ssh-keygen command with -l and -f shows fingerprints for keys in a file. This is useful for auditing what hosts your client knows about and comparing fingerprints. ssh-keygen -R removes a host entry. You'll need this when a server's key legitimately changes - like after reinstallation. Without removing the old entry, SSH will refuse to connect (which is the intended security behavior). System-wide known hosts can be configured in /etc/ssh/ssh_known_hosts. This is useful for organizations to pre-populate host keys for internal servers so users don't have to verify each one manually. A security note: never copy known_hosts between users or machines carelessly. It represents trust relationships. If someone compromises this file, they could add entries that redirect you to malicious servers.

Host Key Changed Warning

[student@workstation ~]$ ssh student@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:nEwKeY9fInGeRpRiNt8xYz7AbCdEfGhIjKlMnOpQrSt.
Please contact your system administrator.
Add correct host key in /home/student/.ssh/known_hosts to get rid of this message.
Offending key in /home/student/.ssh/known_hosts:1
Host key for server.example.com has changed and you have requested strict checking.
Host key verification failed.

STOP! This warning means the server's key doesn't match what you expect. Either the server was reinstalled/changed, or you're being attacked.

This warning is SSH's most important security feature in action. It means the server's current host key doesn't match what's stored in your known_hosts file. Take this warning seriously. SSH is refusing to connect to protect you. There are legitimate reasons for this: the server was reinstalled and got new host keys, the server's IP address was reassigned to a different machine, you're connecting to a different server than before (DNS changed), or the server's SSH configuration changed. But there's also a malicious reason: an attacker is intercepting your connection (man-in-the-middle attack). Never blindly remove the old key without investigating. The proper response is to verify the change is legitimate through another channel. Contact the server administrator, check change logs, or physically verify the server. Once you've confirmed the change is legitimate: remove the old key with ssh-keygen -R hostname, then reconnect and verify the new fingerprint. In automated systems, this warning can break scripts. Organizations should have processes for distributing new host keys when servers are rebuilt, rather than disabling strict checking.

Verifying Host Key Fingerprints

# On the SERVER, view host key fingerprints
[root@server ~]# ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
256 SHA256:xH7vK9mPqL2nR4wY8sT6uB3fJ5aD1eG9hC0iZ2kM7nQ root@server (ED25519)

# View all host key fingerprints
[root@server ~]# for key in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf "$key"; done
256 SHA256:eC2dSa... root@server (ECDSA)
256 SHA256:xH7vK9... root@server (ED25519)
3072 SHA256:rS4aKe... root@server (RSA)

# Show fingerprint in different format (legacy MD5)
[root@server ~]# ssh-keygen -E md5 -lf /etc/ssh/ssh_host_ed25519_key.pub
256 MD5:a1:b2:c3:d4:e5:f6:a7:b8:c9:d0:e1:f2:a3:b4:c5:d6 root@server (ED25519)

# On the CLIENT, compare when connecting
[student@workstation ~]$ ssh -o FingerprintHash=sha256 server.example.com

Verification Process: Get the fingerprint from the server through a trusted channel (console, documentation, phone) and compare it with what SSH displays when connecting.

Proper host key verification requires comparing fingerprints through an out-of-band channel. Here's how to get and verify them. On the server, use ssh-keygen with -l (show fingerprint) and -f (file) to display fingerprints of the host keys. This shows the algorithm, fingerprint hash, comment, and key type. You can loop through all host key files to see all available fingerprints. Different servers might negotiate different key types based on client capabilities. The -E option changes the hash format. Modern OpenSSH uses SHA256 by default, but older systems might show MD5 (the colon-separated hexadecimal format). You can specify either format on either end for comparison. The verification workflow: before first connection, get the fingerprint from a trusted source. During physical server setup, document the fingerprints. Have an administrator read the fingerprint to you over the phone. Check against securely distributed documentation. When you connect and see the fingerprint prompt, compare character by character. If they match, the server is authentic. If not, don't connect - investigate first. For organizations managing many servers, consider using SSH certificates or pre-distributing known_hosts entries to avoid individual verification for each connection.

Public Key Cryptography

🔐

Private Key

id_ed25519

Secret! Never share.
Used to prove identity.

↔

🔓

Public Key

id_ed25519.pub

Safe to share.
Place on servers.

How it works: Data encrypted with the public key can only be decrypted with the private key. The server sends a challenge encrypted with your public key. Only you can decrypt it with your private key, proving your identity without transmitting secrets.

Before generating keys, let's understand the cryptographic concept behind them. Public key cryptography uses mathematically related key pairs. The private key and public key are generated together using complex mathematics. They have a special relationship: what one key encrypts, only the other can decrypt. The private key must be kept absolutely secret. It's stored on your workstation, protected by file permissions and optionally a passphrase. Anyone with your private key can impersonate you. Never share it, never email it, never put it on shared storage. The public key can be freely distributed. It's designed to be public - you put it on every server you need to access. Knowing the public key doesn't help an attacker derive the private key (with current technology). Authentication works through challenge-response: the server picks random data, encrypts it with your public key (from authorized_keys), and sends this challenge. Only someone with the matching private key can decrypt and respond correctly. Your private key never leaves your machine, and the secret data is never transmitted. This is fundamentally more secure than passwords. With passwords, the secret is transmitted (even if encrypted). With key authentication, the secret (private key) never moves.

Generating SSH Key Pairs

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

# Generate RSA key (for legacy compatibility, use 4096 bits)
[student@workstation ~]$ ssh-keygen -t rsa -b 4096

# Generate with specific filename and comment
[student@workstation ~]$ ssh-keygen -t ed25519 -f ~/.ssh/work_key -C "work laptop 2024"

Let's generate SSH key pairs for authentication. The ssh-keygen command creates key pairs for user authentication. The -t option specifies the key type. Ed25519 is recommended - it's modern, fast, and secure with small keys. RSA with 4096 bits is used for compatibility with older systems that don't support Ed25519. When you run ssh-keygen, it asks for the file location. The default (~/.ssh/id_ed25519 or ~/.ssh/id_rsa) works well for most cases. You can specify a different path for multiple keys (work vs personal, different purposes). The passphrase prompt is important. A passphrase encrypts your private key file. If someone steals the file, they still can't use it without the passphrase. For security, always use a strong passphrase. The only exception might be keys used for automated, unattended processes - we'll discuss that later. The -f option specifies the filename. The -C option adds a comment stored in the public key - useful for identifying keys (which computer, which user, what purpose). The randomart image is a visual representation of the key fingerprint - some people find it easier to recognize visually than reading hex or base64. Two files are created: the private key (no extension) and public key (.pub extension).

SSH Key Permissions

~/.ssh/

700

drwx------

~/.ssh/id_ed25519

600

-rw-------

~/.ssh/id_ed25519.pub

644

-rw-r--r--

~/.ssh/authorized_keys

600

-rw-------

~/.ssh/known_hosts

644

-rw-r--r--

~/.ssh/config

600

-rw-------

# Fix permissions if needed
[student@workstation ~]$ chmod 700 ~/.ssh
[student@workstation ~]$ chmod 600 ~/.ssh/id_ed25519
[student@workstation ~]$ chmod 644 ~/.ssh/id_ed25519.pub

# Check permissions
[student@workstation ~]$ ls -la ~/.ssh/

SSH will refuse to use keys with wrong permissions! Private keys must be readable only by the owner. This prevents other users from stealing your keys.

SSH enforces strict permissions on key files as a security measure. If permissions are too open, SSH refuses to use the keys - this protects you from yourself. The ~/.ssh directory must be 700 (rwx------) - only you can access it. If others can read it, they could read your private keys. Private key files (id_ed25519, id_rsa) must be 600 (rw-------). No one else should be able to read them. SSH checks this before using the key - if the permissions are wrong, it won't authenticate. Public key files can be 644 (rw-r--r--) - they're meant to be shared, so readable by others is fine. The authorized_keys file should be 600 - this file controls who can log in as you, so it shouldn't be writable by others. The config file should be 600 - it might contain sensitive information about hosts. known_hosts can be 644 - it's not secret, just your record of known servers. If you copy keys between systems or extract them from backups, permissions might be wrong. Always check and fix them with chmod. The most common error is "Permissions 0644 for '/home/user/.ssh/id_ed25519' are too open" - fix it with chmod 600.

Deploying Public Keys: ssh-copy-id

# Copy public key to remote server (easiest method)
[student@workstation ~]$ ssh-copy-id student@server.example.com
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/student/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
student@server.example.com's password: [Enter password]

Number of key(s) added: 1

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

# Test key-based authentication
[student@workstation ~]$ ssh student@server.example.com
Enter passphrase for key '/home/student/.ssh/id_ed25519': [Key passphrase, not password]
[student@server ~]$

# Copy specific key file
[student@workstation ~]$ ssh-copy-id -i ~/.ssh/work_key.pub student@server.example.com

ssh-copy-id is the easiest way to deploy your public key to a server. It handles all the details automatically. When you run ssh-copy-id, it: connects to the server using password authentication (this is the last time you'll need the password), creates ~/.ssh directory on the server if needed with correct permissions, creates or appends to ~/.ssh/authorized_keys with correct permissions, adds your public key to that file. After ssh-copy-id completes, you can test by connecting again. This time, instead of asking for your password, SSH asks for your key passphrase (if you set one). The passphrase decrypts your local private key - it's never sent to the server. The -i option specifies which public key to copy if you have multiple keys or used a non-default filename. By default, ssh-copy-id tries all your default keys. After copying, verify the key works before making any changes that might lock you out (like disabling password authentication). Connect, verify you're prompted for the key passphrase (not password), and confirm you can access the system.

Manual Key Deployment

# View your public key
[student@workstation ~]$ cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... student@workstation

# Method 1: Pipe through SSH
[student@workstation ~]$ cat ~/.ssh/id_ed25519.pub | ssh student@server \
    "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

# Method 2: Copy and paste manually
# 1. Display the public key
[student@workstation ~]$ cat ~/.ssh/id_ed25519.pub
# 2. On the server, create the authorized_keys file
[student@server ~]$ mkdir -p ~/.ssh
[student@server ~]$ chmod 700 ~/.ssh
[student@server ~]$ vim ~/.ssh/authorized_keys   # Paste the key
[student@server ~]$ chmod 600 ~/.ssh/authorized_keys

# Verify the authorized_keys file
[student@server ~]$ cat ~/.ssh/authorized_keys

⚠ Key Format: Each key must be on a single line. Don't add line breaks! The entire key from "ssh-ed25519" to the comment is one line.

Sometimes ssh-copy-id isn't available or you need more control. Here's how to deploy keys manually. First, understand what goes where: your public key (the .pub file content) goes into ~/.ssh/authorized_keys on the server. This file can contain multiple public keys, one per line - anyone with a matching private key can authenticate. Method 1 pipes the key through SSH in a single command. This creates the .ssh directory if needed, sets its permissions, appends the key to authorized_keys, and sets its permissions. It's a bit complex but accomplishes everything in one step. Method 2 is copy-paste: display your public key, copy it (carefully!), then SSH to the server and manually create the file structure. This is useful when you can't pipe through SSH or need to verify each step. The critical detail: each key must be exactly one line. Public keys look long, but they're a single line with no line breaks. If your terminal wraps the display, that's fine, but don't insert actual newlines when pasting. A malformed authorized_keys file won't work. After manual deployment, always test before disconnecting from any existing sessions. Verify you can connect with the key before making changes that might lock you out.

The authorized_keys File

# Located at ~/.ssh/authorized_keys on the SERVER
[student@server ~]$ cat ~/.ssh/authorized_keys
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... student@workstation
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAB... student@laptop
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... admin@management

# Keys can have options prepended
from="192.168.1.*" ssh-ed25519 AAAAC3... restricted-user
command="/usr/bin/backup.sh" ssh-ed25519 AAAAC3... backup-key
no-pty,no-port-forwarding ssh-ed25519 AAAAC3... limited-key

Option	Purpose
from="pattern"	Only allow connections from matching hosts
command="cmd"	Force specific command, ignore client request
no-pty	Prevent terminal allocation
no-port-forwarding	Disable port forwarding
no-agent-forwarding	Disable agent forwarding

The authorized_keys file on the server controls who can authenticate with keys. Understanding its format helps you manage access securely. Basic format is: key-type base64-encoded-key comment. Multiple keys can be listed, one per line. Anyone with a matching private key for any listed public key can authenticate. The comment (usually user@host) helps identify keys but has no security function. Advanced users can prepend options to restrict what a key can do. These options appear before the key type. The "from" option restricts which IP addresses can use this key - useful for limiting where administrators can connect from. The "command" option forces a specific command regardless of what the user requests - perfect for backup keys or restricted automation. The no-* options disable specific features - useful for service accounts that shouldn't have interactive access or forwarding capabilities. To revoke access, simply remove the corresponding line from authorized_keys. Unlike passwords, you don't need to coordinate with the user - just delete their public key. This is one reason key-based auth is easier to manage at scale. For organizations, consider using SSH certificates instead of authorized_keys for centralized management, but that's an advanced topic beyond our scope.

SSH Authentication Flow

Client connects - TCP connection to server port 22

Key exchange - Establish encrypted channel, verify host key

Client offers public key - "I want to authenticate with this key"

Server checks authorized_keys - Is this key allowed?

Server sends challenge - Random data encrypted with public key

Client decrypts and responds - Using private key (may need passphrase)

Server verifies response - Correct? Grant access!

Key Point: The private key never leaves the client. The server verifies identity through challenge-response, not by receiving the private key.

Let's trace through exactly what happens during SSH key authentication. This understanding helps with troubleshooting. Step 1: The client initiates a TCP connection to port 22. Basic networking must work. Step 2: Before any authentication, SSH establishes an encrypted channel. This includes verifying the server's host key against known_hosts. If the host key is unknown or changed, the process might stop here for user confirmation. Step 3: The client announces it wants to use public key authentication and offers its public key. The client says "I have the private key for this public key." Step 4: The server looks in the target user's authorized_keys file. If the offered public key isn't there, this authentication method fails (might try others like password). Step 5: The server generates random challenge data, encrypts it with the client's public key, and sends it. Only someone with the matching private key can decrypt this. Step 6: The client's SSH process needs the private key to decrypt the challenge. If the key has a passphrase, the user is prompted. The decrypted challenge is sent back. Step 7: The server verifies the response matches what it expected. If correct, authentication succeeds and the session begins. The beauty is that the private key never moves. Even if someone captures all network traffic, they can't recover the private key or replay the authentication.

SSH Agent: Passphrase Caching

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

# Start ssh-agent (usually automatic in desktop environments)
[student@workstation ~]$ eval $(ssh-agent)
Agent pid 12345

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

# List keys in agent
[student@workstation ~]$ ssh-add -l
256 SHA256:yOuRkEyFiNgErPrInT... student@workstation (ED25519)

# Now connections don't prompt for passphrase
[student@workstation ~]$ ssh server.example.com
[student@server ~]$    # Connected without passphrase prompt!

# Remove all keys from agent (security)
[student@workstation ~]$ ssh-add -D

Passphrases protect your private key, but entering them repeatedly is tedious. The SSH agent solves this by caching decrypted keys in memory. ssh-agent runs as a background process. On desktop Linux systems with a graphical environment, it's usually started automatically at login. On servers or minimal installations, you might need to start it manually. The eval $(ssh-agent) command starts the agent and sets environment variables so ssh commands know how to contact it. ssh-add loads a key into the agent. You enter the passphrase once, and the decrypted key stays in the agent's memory. Subsequent SSH connections use the agent automatically - no passphrase prompt. ssh-add -l lists keys currently in the agent. ssh-add -D removes all keys, which you might do before leaving your workstation. Security considerations: the agent holds decrypted keys in memory. If someone compromises your running session, they could potentially use your keys. On shared systems, be careful. Desktop environments often integrate with keyrings that persist agent keys across logins. Some people add ssh-add to their login scripts. You can also use ssh-add -t seconds to auto-expire keys after a time limit. For the RHCSA exam, understanding ssh-agent is useful but not required. Focus on key generation and deployment.

Configuring sshd for Security

# /etc/ssh/sshd_config - Server configuration # Disable root login (recommended) PermitRootLogin no # Disable password authentication (keys only) PasswordAuthentication no # Enable public key authentication (usually default) PubkeyAuthentication yes # Specify allowed users or groups AllowUsers student admin AllowGroups sshusers wheel # Disable empty passwords PermitEmptyPasswords no # Use only SSH protocol 2 Protocol 2

# After editing, validate and restart
[root@server ~]# sshd -t                          # Test config syntax
[root@server ~]# systemctl restart sshd

The SSH server configuration file controls how the server accepts connections. Hardening these settings is important for security. /etc/ssh/sshd_config contains server-side settings. Changes require restarting sshd to take effect. PermitRootLogin controls whether root can log in directly. Set to "no" to require users to log in as themselves then use sudo. This provides accountability and an extra authentication layer. "prohibit-password" allows root login only with keys. PasswordAuthentication disables password login entirely when set to "no". Only key-based authentication works. This eliminates password brute-force attacks. Only enable this AFTER you've verified key authentication works! PubkeyAuthentication enables key-based authentication - usually enabled by default, but verify it. AllowUsers and AllowGroups restrict who can SSH in. Even valid users can't connect unless listed. This is a whitelist approach - very secure but requires maintenance. PermitEmptyPasswords should always be "no" - never allow accounts with no password to log in via SSH. Always test configuration changes with "sshd -t" before restarting. A syntax error could lock you out! Keep another terminal session open when making changes, so you can fix problems if the restart fails.

Disabling Password Authentication

Generate keys on your workstation: ssh-keygen -t ed25519
Deploy public key to server: ssh-copy-id user@server
Test key authentication - Verify you can connect without password
Keep current session open - Your safety net!
Edit sshd_config: Set PasswordAuthentication no
Test and restart: sshd -t && systemctl restart sshd
Test from new terminal - Verify key auth still works
⚠ CRITICAL: Do NOT close your existing session until you've verified key authentication works after the change. If something goes wrong, you need that session to fix it!

Disabling password authentication is a major security improvement but must be done carefully. If you disable passwords before keys work, you'll be locked out. This is the safe procedure. Step 1: Generate your SSH key pair on your workstation if you haven't already. Step 2: Deploy the public key to the server using ssh-copy-id or manual methods. Step 3: Test that key authentication works. Connect to the server - you should be prompted for your key passphrase (not the server password). If you're still asked for a password, something is wrong. Fix it before proceeding. Step 4: Keep your current SSH session open. This is your lifeline. If something goes wrong after the change, you can use this session to fix it. Step 5: Edit /etc/ssh/sshd_config and set PasswordAuthentication to no. Step 6: Test the configuration with sshd -t, then restart the service. Step 7: From a NEW terminal (not your safety session), try to connect. Verify you can authenticate with your key. If everything works, you can close the safety session. If it fails, use the safety session to investigate and fix. Common problems: key not in authorized_keys, wrong permissions, SELinux issues. Always have console access (physical, IPMI, or cloud console) as a final backup.

SSH Client Configuration

# ~/.ssh/config - Per-user client configuration
Host webserver
    HostName webserver.example.com
    User admin
    Port 22
    IdentityFile ~/.ssh/work_key

Host database
    HostName 192.168.1.50
    User dbadmin
    IdentityFile ~/.ssh/db_key
    
Host *.internal.example.com
    User developer
    IdentityFile ~/.ssh/internal_key
    StrictHostKeyChecking yes

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

# Now connect using the alias
[student@workstation ~]$ ssh webserver       # Expands to full connection
[student@workstation ~]$ ssh database        # Uses the defined settings

Benefit: Define complex connection settings once, then use simple aliases. Different keys for different purposes, different usernames per host.

The SSH client configuration file lets you define connection presets, making complex scenarios simple. ~/.ssh/config is the per-user client configuration. Each "Host" block defines settings for matching hostnames. Settings can include: HostName (the actual hostname or IP), User (default username), Port (if not 22), IdentityFile (which key to use), and many others. Host can be an alias or a pattern. "Host webserver" creates an alias - "ssh webserver" connects to webserver.example.com as admin using the work_key. Host patterns with wildcards match multiple hosts. "Host *.internal.example.com" applies to any host in that domain. The "Host *" block at the end applies to all connections as defaults. ServerAliveInterval sends keepalive packets to prevent idle disconnection. This configuration file is powerful for managing access to many servers. Different environments (work, personal, different projects) c