Red Hat System Administration I · RH124

Chapter 19

Configuring and Securing SSH
Protect SSH communication · Host keys · Key-based authentication
CIS126RH — Mesa Community College

Chapter Objective

Configure and secure the OpenSSH service on Red Hat Enterprise Linux. Manage host keys, implement SSH key-based authentication for users, and harden the SSH daemon configuration file.

Key Commands

  • ssh
  • ssh-keygen
  • ssh-copy-id
  • scp
  • sftp
  • ssh-agent
  • ssh-add

What Is SSH?

SSH (Secure Shell) is a cryptographic network protocol that replaces older, plaintext remote-access tools such as telnet, rsh, and rcp. Every byte transmitted — including your password and the commands you type — is encrypted inside an SSH tunnel.

On RHEL, the OpenSSH package provides both the client (ssh) and the server daemon (sshd). The daemon listens on TCP port 22 by default and is managed by systemd.

Why It Matters — As a system administrator you will manage remote servers almost exclusively over SSH. Understanding how authentication, host keys, and configuration work is one of the most practical skills in this course.

The SSH Protocol — Three Guarantees

GuaranteeMeaningMechanism
ConfidentialityNobody can read the data in transitSymmetric encryption (AES)
IntegrityData cannot be altered undetectedHMAC checksums
AuthenticationBoth sides prove who they areHost keys + user auth
# Check whether sshd is running
systemctl status sshd

# Start and enable sshd at boot
systemctl enable --now sshd

# Confirm sshd is listening on port 22
ss -tlnp | grep ssh

Connecting with ssh

The basic syntax is ssh [user@]hostname [command]. If you omit user, SSH uses your current local username.

# Open an interactive shell on remotehost as your own username
ssh remotehost

# Log in as a different user
ssh student@remotehost

# Run a single command remotely without opening a shell
ssh student@remotehost hostname

# Connect to a non-default port
ssh -p 2222 student@remotehost

# Enable X11 forwarding (run graphical apps remotely)
ssh -X student@remotehost
Tip — First Connection — The very first time you connect to a host, SSH displays its host key fingerprint and asks you to verify it. Type yes to accept and the key is saved in ~/.ssh/known_hosts. Future connections compare silently.

SSH Host Keys

When the sshd daemon is installed for the first time, it generates host key pairs in /etc/ssh/. These keys prove the server's identity — they are the SSH equivalent of a TLS certificate.

FileTypePurpose
/etc/ssh/ssh_host_rsa_keyRSA privateServer's RSA identity (private, root-only)
/etc/ssh/ssh_host_rsa_key.pubRSA publicSent to clients during handshake
/etc/ssh/ssh_host_ecdsa_keyECDSA privateServer's ECDSA identity
/etc/ssh/ssh_host_ed25519_keyEd25519 privateModern, preferred algorithm

The known_hosts File

Each user's ~/.ssh/known_hosts file stores the fingerprints of servers they have connected to. If a server's fingerprint changes unexpectedly, SSH refuses the connection and warns you — protecting against man-in-the-middle (MITM) attacks.

# View the fingerprint of a server's host key
ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub

# Remove a stale entry from known_hosts (e.g., after a server rebuild)
ssh-keygen -R remotehost

# Scan and display a remote host's fingerprint before connecting
ssh-keyscan remotehost
Warning — Changed Fingerprint — If SSH warns you that a remote host's identification has changed, do NOT simply delete the entry and reconnect. First verify with the server owner that the host key legitimately changed (e.g., due to a rebuild). An unexpected change can indicate an active attack.

Key-Based Authentication

Password authentication requires a password over the network on every login. Key-based authentication is more secure and can be automated (for scripts, Ansible, etc.). You generate a key pair: the private key stays on your client; the public key is copied to the server.

Step 1 — Generate a Key Pair

# Generate an Ed25519 key pair (recommended algorithm on modern RHEL)
ssh-keygen -t ed25519

# You will be prompted for:
#   - a file path  (default: ~/.ssh/id_ed25519)
#   - a passphrase (strongly recommended — protects the private key)

# For RSA (still widely used, 4096-bit for stronger security)
ssh-keygen -t rsa -b 4096
FileKeep it…Notes
~/.ssh/id_ed25519SecretNever share; permissions must be 600
~/.ssh/id_ed25519.pubPublicSafe to share; copy to servers

Step 2 — Copy the Public Key to the Server

# The easiest way — ssh-copy-id handles everything
ssh-copy-id student@remotehost

# Behind the scenes it appends the public key to:
#   ~/.ssh/authorized_keys   (on the remote server)

# Manual alternative (if ssh-copy-id is unavailable)
cat ~/.ssh/id_ed25519.pub | ssh student@remotehost \
  "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Step 3 — Log In Without a Password

ssh student@remotehost
# Prompts for your key passphrase (not the account password)
# With ssh-agent loaded, not even the passphrase is needed interactively

Using ssh-agent to Cache Your Passphrase

# Start the agent (usually done automatically by the desktop session)
eval $(ssh-agent)

# Add your private key to the agent
ssh-add ~/.ssh/id_ed25519
# You will be prompted for the passphrase once

# List keys currently loaded in the agent
ssh-add -l
Exam Note — You need to know the full three-step workflow: generate → copy → test. Also know the default file names and locations, and that authorized_keys lives on the server while known_hosts lives on the client.

SSH Configuration Files

OpenSSH behaviour is controlled by two configuration files: the server-side daemon config and the client-side user config.

FileSideWho edits it
/etc/ssh/sshd_configServerroot / system administrator
/etc/ssh/ssh_configClient (system-wide)root
~/.ssh/configClient (per-user)Each user for themselves

Useful Per-User Client Config (~/.ssh/config)

Define host aliases so you never have to remember IP addresses or long usernames:

# Example ~/.ssh/config
Host bastion
    HostName 192.168.1.10
    User     admin
    Port     22
    IdentityFile ~/.ssh/id_ed25519

Host lab
    HostName 10.0.0.5
    User     student
    ForwardX11 yes

With this file in place, ssh bastion is equivalent to ssh -i ~/.ssh/id_ed25519 admin@192.168.1.10.

Tip — File Permissions Matter — SSH is strict about permissions. If permissions are too open, SSH refuses to use the files. ~/.ssh/ directory must be 700; ~/.ssh/config and private keys must be 600; ~/.ssh/authorized_keys must be 600.

Copying Files: scp — Secure Copy

SSH provides two tools for encrypted file transfer: scp (non-interactive, like cp over a network) and sftp (interactive, like ftp but encrypted).

# Copy a local file TO a remote host
scp localfile.txt student@remotehost:/home/student/

# Copy a file FROM a remote host to the current directory
scp student@remotehost:/etc/hostname .

# Copy an entire directory recursively
scp -r ~/project/ student@remotehost:/home/student/

# Use a non-default port
scp -P 2222 file.txt student@remotehost:~/

Copying Files: sftp — Secure FTP

# Open an interactive sftp session
sftp student@remotehost

# Useful sftp commands once connected:
sftp> ls            # list remote directory
sftp> lls           # list local directory
sftp> get file.txt  # download file
sftp> put file.txt  # upload file
sftp> mkdir backup  # create remote directory
sftp> bye           # exit
Notescp uses the same ~/.ssh/config host aliases and key files as ssh. If you've already set up key-based auth, scp works without a password automatically.

Securing the SSH Daemon (sshd_config)

The default RHEL sshd_config is reasonably secure, but production servers benefit from additional hardening. After any change, reload the daemon: systemctl reload sshd

DirectiveRecommended ValueWhy
PermitRootLoginnoForce admins to su/sudo; avoids brute-force on root
PasswordAuthenticationnoDisables password login; requires key-based auth
PubkeyAuthenticationyesEnables key-based auth (default on RHEL)
AllowUsersstudent opsWhitelist; only listed users may log in
Portoptional non-22Reduces noise from automated scanners
ClientAliveInterval300Disconnect idle sessions after 5 minutes
MaxAuthTries3Limits brute-force attempts per connection
X11ForwardingnoDisable unless graphical forwarding is needed

Hardened Configuration Example

# Example hardened snippet in /etc/ssh/sshd_config
PermitRootLogin        no
PasswordAuthentication no
PubkeyAuthentication   yes
AllowUsers             student
ClientAliveInterval    300
ClientAliveCountMax    2
MaxAuthTries           3

# Validate the config syntax before reloading
sshd -t
systemctl reload sshd
Warning — Lock-Out Risk — Set PasswordAuthentication no only after you have verified that key-based login works. Otherwise you may lock yourself out of the server permanently.

SELinux and Firewall Considerations

# If you change the SSH port (e.g., to 2222), update SELinux policy:
semanage port -a -t ssh_port_t -p tcp 2222

# Then open the new port in firewalld:
firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --reload

# Remove the old port if no longer needed:
firewall-cmd --permanent --remove-service=ssh
firewall-cmd --reload

Key Terms for Chapter 19

ssh
OpenSSH client — opens encrypted remote shells and tunnels
sshd
The SSH daemon; listens on TCP 22, managed by systemd
ssh-keygen
Generates SSH key pairs; also inspects and manages key files
ssh-copy-id
Installs a public key into a remote user's authorized_keys
ssh-agent
Memory-resident agent that caches decrypted private keys for a session
ssh-add
Adds a private key to a running ssh-agent
known_hosts
Client-side file (~/.ssh/known_hosts) storing trusted server fingerprints
authorized_keys
Server-side file (~/.ssh/authorized_keys) listing permitted public keys
scp
Secure copy — non-interactive encrypted file transfer over SSH
sftp
Secure FTP — interactive encrypted file transfer session over SSH
PermitRootLogin
sshd_config directive controlling whether root can log in directly
PasswordAuthentication
Controls whether password-based SSH logins are allowed
Host key
Server's long-lived key pair in /etc/ssh/; proves the server's identity

Review Questions

  1. You run ssh student@server1 and are warned that the remote host identification has changed. What should you do before accepting the new key?
  2. What command copies your default public key to the account ops on server2?
  3. A colleague set PasswordAuthentication no before copying their public key. Now they cannot log in. What likely happened and how can you recover (assuming console access)?
  4. After generating a key pair with ssh-keygen -t ed25519, where is the public key stored by default?
  5. What sshd_config directive would you use to allow only the users alice and bob to log in via SSH?
  6. Explain the difference between ~/.ssh/known_hosts and ~/.ssh/authorized_keys. Which file lives on the client, and which on the server?
  7. You change the SSH daemon port to 2222 on a RHEL system. Name two additional configuration steps required before the change takes effect.
1 / 19