Most SSH hardening articles cover the same checklist: disable root login, use key pairs, change the port, install fail2ban. If you’ve done all that, you’re already ahead of the average server. But once you manage more than a handful of VPS instances, a new class of problems appears: key sprawl, credential rotation, and safely accessing private networks. This guide covers the SSH security practices that matter once you move past the basics.<\/p>\n\n
Set Every VPS with a public SSH port is a target. For a fleet, the clean architecture is one hardened bastion host that is the only<\/em> machine reachable on port 22 from the internet. All other servers listen on a private network interface only. Clients reach them through the bastion:<\/p>\n\n On the bastion, enforce Sometimes you don’t want any<\/em> inbound SSH. If a VPS only sends data out (monitoring agents, backup pushes) but you need occasional admin access, use a reverse tunnel from the VPS to a trusted management server, then reach it through the tunnel:<\/p>\n\n With Key sprawl is the silent killer of SSH security. When engineers leave, their keys should die too. The practical fix for small teams is a simple triage of your Modern OpenSSH defaults are good, but explicit is better. On each host set:<\/p>\n\n Use Ed25519 keys exclusively\u2014older RSA-2048 keys should be rotated. Also set PasswordAuthentication no<\/code> in \/etc\/ssh\/sshd_config<\/code>, but also disable the fallbacks that quietly undermine it: PermitEmptyPasswords no<\/code>, ChallengeResponseAuthentication no<\/code>, and UsePAM no<\/code> (unless you specifically need PAM for two-factor). Then verify with ssh -o PreferredAuthentications=password user@host<\/code>\u2014it should fail. A single password-authenticated account, even a low-privilege one, is a foothold for credential-stuffing bots.<\/p>\n\nUse Jump Hosts Instead of Exposing Everything<\/h2>\n\n
Host app-server\n HostName 10.0.0.5\n User deploy\n ProxyJump bastion.example.com\n IdentityFile ~\/.ssh\/deploy_key<\/code><\/pre>\n\nAllowUsers<\/code> to an explicit list and consider MaxStartups 3:50:10<\/code> to blunt connection-flooding. If you must expose multiple hosts, restrict each one to a non-standard high port and geo-block at the firewall\u2014but a jump host remains the correct long-term design.<\/p>\n\nReverse Tunnels for Private Services<\/h2>\n\n
ssh -R 2222:localhost:22 user@management-host<\/code><\/pre>\n\nExitOnForwardFailure yes<\/code> and a systemd unit that keeps the tunnel alive, this gives you a firewall-less SSH path that exposes no ports locally. It is a favourite pattern for edge devices and database servers that should never be publicly reachable.<\/p>\n\nKey Management at Scale<\/h2>\n\n
authorized_keys<\/code> files:<\/p>\n\nssh-keygen -t ed25519 -C \"alice@workstation-2026\"<\/code>. A key without a comment is a liability you can’t audit.<\/li>authorized_keys<\/code> list from a canonical source (Ansible, a git repo, or a small script) and diff it against live servers to surface drift.<\/li>ssh-agent<\/code> with a passphrase-protected key.<\/li><\/ul>\n\nHarden the Cryptographic Settings<\/h2>\n\n
KexAlgorithms curve25519-sha256\nHostKeyAlgorithms ssh-ed25519\nMACs hmac-sha2-256\nCiphers chacha20-poly1305@openssh.com<\/code><\/pre>\n\nClientAliveInterval 300<\/code> and ClientAliveCountMax 0<\/code> to silently drop dead sessions instead of leaving zombie connections holding resources.<\/p>\n\nLog, Alert, and Automate the Response<\/h2>\n\n