RHEL SSH Administration and Secure Remote Access

Anil Jalela · Published Sep 3, 2026 · 8 min read

SSH protects a connection only when both sides make trustworthy identity decisions. A client that accepts an unexplained host-key change loses server authentication. A server that accepts a copied private key from many people loses individual attribution. Secure administration combines verified host identity, named users, scoped authentication, least privilege, current cryptography, session evidence and a console-backed change procedure.

Separate server identity from user authentication

Host keys identify the server to clients. User public keys or certificates authenticate a principal to the server. They are different trust chains. Rebuilds, load-balanced endpoints and host certificates require an owned distribution method so clients can distinguish planned identity change from interception.

Agent and port forwarding extend trust across boundaries. Keep them disabled unless the workflow and destination are controlled. A bastion reduces exposed entry points but becomes a high-value identity and audit boundary.

Build an evidence map

Operating sequence

1. Inventory listeners, host keys, users, keys, bastions and automation dependencies.
2. Back up exact configuration and retain console plus two privileged sessions.
3. Validate a proposed drop-in with sshd -t and inspect effective values with sshd -T.
4. Add one control at a time, preferably through a Match block with known scope.
5. Reload rather than restart when supported, keeping the existing session open.
6. Test new login, intended denial, sudo and automation from the real source.
7. Remove superseded keys only after every owner and job has migrated.

Commands and expected evidence

ss -lntp | grep ':22'
sshd -t
sshd -T | grep -E '^(passwordauthentication|pubkeyauthentication|permitrootlogin|allowagentforwarding|allowtcpforwarding)'
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
ssh-keygen -lf ~/.ssh/authorized_keys
ssh -G host.example | grep -E '^(hostname|user|proxyjump|identityfile)'
ssh -o StrictHostKeyChecking=yes host.example
journalctl -u sshd --since '-30 minutes' --no-pager

• Use sshd -T -C user=...,host=...,addr=... when Match rules depend on connection context.
• Never print private-key material; fingerprints of approved public keys are adequate inventory evidence.
• Strict host checking should fail an unrecognized change until identity is verified independently.
• Reload only after syntax passes and the recovery session remains usable.

Evidence and acceptance criteria

Worked operating scenario

After a rebuild, automation reports a host-key mismatch. Deleting the known-host entry would restore connectivity but erase the only warning that server identity changed. The operator checks the rebuild record and console-displayed fingerprint through a trusted inventory path, then updates the centrally managed host identity.

The old fingerprint is retained in the change record. Automation resumes only after strict verification, and no user is told to disable host-key checking.

Practical how-to cases

ssh-keygen -t ed25519 -a 64 -f ~/.ssh/id_ed25519_lab
ssh-copy-id -i ~/.ssh/id_ed25519_lab.pub student@servera
ssh-keygen -lf ~/.ssh/id_ed25519_lab.pub
ssh -i ~/.ssh/id_ed25519_lab student@servera

printf '%s\n' 'PermitRootLogin no' 'PasswordAuthentication no' | sudo tee /etc/ssh/sshd_config.d/40-site-policy.conf
sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
sudo systemctl reload sshd

ssh -J [email protected] [email protected]
ssh -G serverb.example.test | grep -E 'hostname|user|proxyjump|identityfile'
ssh-keyscan -t ed25519 serverb.example.test

ssh -vvv student@servera
sudo journalctl -u sshd --since '-10 minutes' --no-pager
sudo sshd -T -C user=student,host=servera,addr=192.0.2.50
namei -om /home/student/.ssh/authorized_keys
ls -ldZ /home/student/.ssh /home/student/.ssh/authorized_keys

sha256sum package.tar.gz
scp -o StrictHostKeyChecking=yes package.tar.gz student@servera:/tmp/
ssh student@servera 'sha256sum /tmp/package.tar.gz'
sftp -b batch.txt student@servera

Independent practice tasks

1. Configure key-only access and prove password rejection.
2. Use Match Address for a lab subnet and inspect contextual output.
3. Configure local and remote forwarding, then state the exposure risk.
4. Recover from an invalid sshd drop-in through console.

For this lesson on RHEL SSH Administration, complete each task without copying the worked command sequence. Record the initial state, exact change, verification, negative test and recovery command. A task is unfinished if it works now but does not survive a reboot where persistence is required.

Troubleshooting by symptom

Unsafe operations and recovery boundaries

• Unsafe: disabling host-key verification permits silent redirection or interception.
• Unsafe: replacing sshd configuration remotely without console and retained sessions can lock out every operator.
• Unsafe: shared private keys and unrestricted agent forwarding expand impersonation across hosts.

Rewritten knowledge checks

Guided lab and acceptance test

1. Record lab server host-key fingerprints at the console.
2. Create a named lab user and a new protected key pair; install only the public key.
3. Verify strict host checking and record the accepted fingerprint.
4. Add a scoped sshd drop-in, validate and reload while retaining one session.
5. Test approved login plus password/root denial.
6. Remove the lab key/account only after checking files, jobs and sessions.

Primary references

• RHEL 10 security hardening
• RHEL 10 documentation
• RHEL 9 documentation