Replace password SSH with keys, then lock it down

short · 40 min · Objective 3.5

Task

Configure key-based SSH between your lab hosts, disable password authentication, and confirm the change actually took effect rather than merely appearing in the config file. Remote access is the most attacked service on any network, and this is the hardening that matters most.

Steps

  1. On Host A, generate a key pair: ssh-keygen -t ed25519 -C "lab". Choose ed25519 over RSA: shorter, faster, and no key-size decision to get wrong.
  2. Install the public key on Host B: ssh-copy-id user@192.168.20.10. This appends it to ~/.ssh/authorized_keys with the right permissions, which is the part people get wrong by hand.
  3. Confirm key authentication works before disabling anything: ssh -o PasswordAuthentication=no user@192.168.20.10 hostname. If that fails, stop and fix it; do not proceed.
  4. Edit /etc/ssh/sshd_config on Host B: PasswordAuthentication no, PermitRootLogin no, and PubkeyAuthentication yes. Test the config with sudo sshd -t before restarting — that single command prevents most lockouts.
  5. Restart sshd from a session you keep open, then prove the change from a new session: attempt a password login and confirm it is refused.

Verify

ssh -o BatchMode=yes -o ConnectTimeout=5 user@192.168.20.10 hostname
sudo sshd -T | grep -E "^(passwordauthentication|permitrootlogin|pubkeyauthentication)"
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no user@192.168.20.10 hostname; echo "password login exit $?"

sshd -T prints the effective configuration — what the daemon is actually running, not what the file says. That distinction is the point of the lab: a setting below a Match block, or a second config file in sshd_config.d, can make the file and the behaviour disagree. The password attempt must fail.

Notes

sshd -T is the command worth taking away. Reading a config file tells you what someone intended; asking the daemon tells you what is true. The same distinction applies to firewalls, routers and DNS servers, and domain 5 is largely the practice of preferring the second kind of answer.

The remote access methods in the objective sit on a spectrum worth placing. SSH for command line, RDP for Windows desktops, VPN for network-level access, and a jump box or bastion as the single audited entry point that the others go through.

Out-of-band management is the different one, and its value is exactly that it does not depend on the network. A console server on its own cellular or dialup path lets you fix a router you have just disconnected yourself from. Every engineer learns why it exists by needing it once.