SynologyRS
Security

Locking down SSH the practical way

📅 2024-12-08✎ 7 min read

Keys, a non-standard port, fail2ban — what actually earns its keep.

SSH hardening is full of rituals people repeat without asking why. Port changing, MOTD tricks, banner edits. Some help, most just make you feel safe. This is the part that matters and the part that does not.

Keys, period

Generate an ed25519 key if you have not. Drop the public key, delete the private key from any shared machine, and set a passphrase. A key with no passphrase is a key anyone who touches the file owns.

ssh-keygen -t ed25519 -C "you@box"
ssh-copy-id -p 22 alex@SERVER
ssh -p 22 alex@SERVER

ssh_config, not just sshd_config

Most of the safety lives on the client side. Force the key, disable agent forwarding unless you need it, and set a short serveralive interval so dead sessions do not linger open.

Host SERVER
    HostName 194.87.199.61
    User alex
    IdentityKey ~/.ssh/id_ed25519
    ForwardAgent no
    ServerAliveInterval 60

The port thing

Moving off 22 cuts the ocean of automated scans by a lot, which makes the real logs readable. It is obfuscation, not security — do not dress it up as a wall. fail2ban still earns its keep on whatever port you keep.

What I would not bother with

PAM complexity, custom banners, and “hide sshd” name changes. They add friction for you and nothing for an attacker who is already decided.