知識庫

Beyond changing the port and disabling root login (see SSH Hardening: Change the Port, Disable Root Login & Use SSH Keys), SSH's cryptographic configuration itself can be tightened to remove legacy, weaker algorithms.

Prerequisites

• SSH already configured with key-based authentication
• Root or sudo access
• An active SSH session (keep it open throughout)

Checking Currently Supported Algorithms

ssh -Q cipher
ssh -Q mac
ssh -Q kex

Restricting to Strong Ciphers Only

sudo nano /etc/ssh/sshd_config

Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr

Restricting to Strong MACs (Message Authentication Codes)

MACs [email protected],[email protected],[email protected]

Restricting to Strong Key Exchange Algorithms

KexAlgorithms curve25519-sha256,[email protected],diffie-hellman-group16-sha512

Disabling Weak Host Key Types

HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

Regenerating Host Keys with Stronger Parameters (If Needed)

If your SSH host keys were generated long ago with weaker defaults:

sudo rm /etc/ssh/ssh_host_*
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
sudo ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""

Additional Hardening Directives

Protocol 2
X11Forwarding no
AllowTcpForwarding no
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2

MaxAuthTries 3 limits authentication attempts per connection; ClientAliveInterval/ClientAliveCountMax disconnect idle sessions after a defined period.

Validating the Configuration

sudo sshd -t

Restarting SSH

sudo systemctl restart ssh

Testing in a New Session (Critical)

Without closing your current session, verify connectivity in a new terminal window before assuming success.

Verifying Your Configuration Externally

Use an external SSH configuration scanner (search "SSH audit tool") to check your server's configuration against current best practices from outside, confirming the changes took effect as intended.

Common Errors

Older SSH clients can't connect after restricting algorithms — some legacy clients don't support modern ciphers/KEX algorithms; balance security against your actual client compatibility needs, and update client software where possible rather than weakening the server.

Locked out after regenerating host keys — existing clients will show a host key mismatch warning; this is expected after intentionally regenerating keys, but verify the change was actually intentional before proceeding past the warning on the client side.

Best Practices

• Always test configuration changes in a new session before closing the current one
• Regenerate weak host keys if the server has been running for years without renewal
• Re-audit periodically as cryptographic best practices evolve over time

Continue Reading

• SSH Hardening: Change the Port, Disable Root Login & Use SSH Keys
• How to Set Up Centralized Authentication with SSH Certificates
• How to Enable Two-Factor Authentication (2FA) for SSH

Browse more articles in Advanced Security & Compliance.