SSH hardening: keys, ciphers, and CA-signed certificates
Disable passwords, pick modern ciphers, and issue SSH certificates so you stop managing authorized_keys by hand.
SSH is still the front door to most Linux fleets — and the first service attackers probe on port 22. A hardened sshd disables password authentication, restricts algorithms to modern sets, limits who can log in, and optionally trusts a SSH certificate authority so you issue short-lived host and user certs instead of copying authorized_keys to five hundred machines. Hardening is configuration, not mystery: /etc/ssh/sshd_config plus a reload.
This note walks client and server settings, shows CA-signed user cert flow, and warns about lockout — always keep a console session open while testing. For broader host defense, continue with Linux hardening; for detecting brute force and lateral movement, see Linux detection engineering.
Validate config with sshd -t before reload. Test from a second session. Roll out CA before disabling old keys.
Core sshd_config settings
Set PermitRootLogin no — use sudo on a named account. Disable empty passwords and challenge-response. MaxAuthTries 3 slows brute force. Pair with fail2ban or network-level rate limits; sshd alone will still log noise.
AllowUsers or AllowGroups restrict which identities may authenticate at all — useful when LDAP returns every employee but only ssh-users should reach production. LoginGraceTime 30 shortens hung connection windows. Disable agent forwarding (AllowAgentForwarding no) on jump hosts unless you explicitly need it; forwarding is a lateral movement path.
PasswordAuthentication noKbdInteractiveAuthentication noPermitRootLogin noAllowGroups ssh-usersMaxAuthTries 3X11Forwarding noKexAlgorithms curve25519-sha256,[email protected]Ciphers [email protected],[email protected]MACs [email protected]
SSH CA for user certificates
Generate a CA key offline. Sign user public keys into short-lived certificates with -O permit-pty,force-command only if you need restrictions. On each host, set TrustedUserCAKeys /etc/ssh/ca.pub. Revocation is centralized — rotate the CA or publish a KRL instead of editing every authorized_keys.
Host certificates (HostCertificate signed by a host CA) let clients trust servers without StrictHostKeyChecking=no in scripts. Vault, step-ca, and small internal CAs automate signing. Offboarding becomes revoking the user cert template or removing the principal from the next issued cert — not grep across fleet authorized_keys.
# On CA workstation (offline)ssh-keygen -t ed25519 -f ssh_ca -C "corp-user-ca"# Sign alice's key — valid 8 hoursssh-keygen -s ssh_ca -I alice@corp -n alice,admin \-V +8h -O permit-pty id_ed25519.pub# On server: TrustedUserCAKeys /etc/ssh/ca.pub
sshd -t -f /etc/ssh/sshd_configSyntax OKssh -vv [email protected]Offering public key: ED25519-CERT ...Authenticating with public key ...Welcome — cert auth succeededWhere this goes next
Layer network controls — allowlist admin IPs with nftables or security groups, forward sshd logs to SIEM, and alert on new keys in authorized_keys if you have not migrated to CA yet. Linux hardening covers the full stack; Linux detection engineering shows auditd and journal rules for SSH anomalies.
Bastion hosts deserve the same cipher suite as internal servers — weak edge sshd undermines the whole model. Rotate host keys after imaging clones; duplicate host keys break StrictHostKeyChecking for automation.
Go deeper in a courseLinux hardeningSSH, firewall, systemd sandboxing, and production host baselines.View course