Hardening SSH: keys, port, restrictions

SSH is the only door into the machine you use every day, and the main target of automated brute-force attacks. You configure it once, and after that it needs no attention.

Make all edits in a separate file, /etc/ssh/sshd_config.d/99-hardening.conf — that way a package update won't overwrite your work and leave you without access.

Keys instead of passwords

PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
PermitEmptyPasswords no

Before applying, make sure the key actually works: log in with it in a separate window. Keys added in the “Access” tab of the /hosting/vds/m/<id> panel go to the root user; for other users you have to put them into ~/.ssh/authorized_keys by hand.

Generating a key on your side:

ssh-keygen -t ed25519 -C "work laptop"

ed25519 is shorter and faster than RSA. If your tool doesn't support it, use rsa with a length of at least 4096 bits.

Who can log in

PermitRootLogin prohibit-password
AllowUsers artem deploy
MaxAuthTries 3
LoginGraceTime 20
ClientAliveInterval 300
ClientAliveCountMax 2

AllowUsers is the most effective rule after disabling passwords: brute-forcing other people's names stops immediately. More on root — disable root login by password.

An address restriction, if you work from a fixed location:

Match Address 203.0.113.5
    PermitRootLogin yes

Changing the port

Moving SSH from 22 to a non-standard port doesn't protect you from a targeted attack, but it removes almost all the noise from automated scanners in your logs.

Port 2222

The order of steps is strictly this:

ufw allow 2222/tcp
sshd -t
systemctl restart ssh
ssh -p 2222 artem@<address>
ufw delete allow 22/tcp

The firewall rule comes before the restart, and removing the old one only after a successful login on the new port. See also ports.

Applying and verifying

sshd -t
sshd -T | grep -Ei "passwordauth|permitroot|allowusers|port"
systemctl restart ssh

sshd -t checks the syntax, sshd -T shows the final effective configuration — that one, not what you wrote in the file.

Keep your current session open while you configure. It will survive an sshd restart, and through it you can roll back a failed edit. If you do lock yourself out — the “Console” tab in the panel works independently of SSH.

Common mistakes

In sshd_config, the first occurrence of a parameter wins, and files from sshd_config.d are included at the beginning. So verify the result with sshd -T instead of reading the file.

fail2ban will remove the remaining brute-force noise.