Securing SSH involves a wide range of possible techniques, but not all are equally practical for every environment. The recommendations in this article are widely recognized, high-impact methods that balance ease of implementation with robust protection. They’re drawn from standards set by organizations like NIST, CERT, and the OpenSSH project, and reflect core principles that SSL.com also applies in securing digital certificates—protecting keys, using strong encryption, and limiting privileged access.
Once you’ve set up these foundational best practices, you can explore more advanced tactics—such as certificate-based SSH, port knocking, or SSH over VPN—as needed.
1. Use Key-Based Authentication Instead of Passwords
What it is:
You replace password logins with a cryptographic public/private key pair. The public key goes on your server, while the private key stays on your local machine.
Why it’s more secure:
- Passwords are susceptible to brute-force attacks
- An attacker must physically obtain your private key to break in, which is far harder than guessing a password
How to implement:
Generate a Key Pair
On Linux or macOS, open a terminal and run:
ssh-keygen -t ed25519
For extra security (if ed25519 isn’t available in your environment), you can use:
ssh-keygen -t rsa -b 4096
Copy the Public Key to Your Server
You can use the ssh-copy-id command (on Linux/macOS) to easily transfer your public key:
ssh-copy-id user@server_address
If ssh-copy-id isn’t available, manually append the contents of your id_ed25519.pub (or id_rsa.pub) file to the server’s ~/.ssh/authorized_keys file.
Disable Password Authentication
In /etc/ssh/sshd_config, set:
PasswordAuthentication no
Restart the SSH service:
sudo systemctl restart ssh
Just like managing digital certificates, SSH key-based authentication ensures that only someone with the correct private key can establish a connection.
2. Disable Root Login
What it is:
Prevent the root user from logging in directly via SSH.
Why it’s more secure:
- The root account holds unlimited privileges and is an attractive target for attackers
- Disabling direct root access forces attackers to guess not only a key or password but also a valid username
How to implement:
In /etc/ssh/sshd_config, find or add:
PermitRootLogin no
Restart SSH:
sudo systemctl restart ssh
This step effectively narrows your attack surface by removing the most powerful account from easy reach.
3. Enforce Strong Encryption and MAC Algorithms
What it is:
SSH allows you to specify which ciphers and message authentication codes (MACs) to use for encrypting data and verifying data integrity.
Why it’s more secure:
- Older or weak algorithms (e.g., DES, RC4) can be vulnerable to cryptographic attacks
- Using modern ciphers (like AES-256) and strong MACs (like HMAC-SHA2) helps keep your session data confidential and tamper-proof
How to implement:
In /etc/ssh/sshd_config, add or update your cipher/MAC list:
Ciphers aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-256,hmac-sha2-512
Restart SSH:
sudo systemctl restart ssh
Keeping cryptography up to date for SSH is just as vital as ensuring secure protocols and ciphers are used in TLS.
4. Keep SSH (and Your System) Updated
What it is:
Ensuring that OpenSSH, along with the rest of your operating system, gets regular security patches.
Why it’s more secure:
- Outdated software frequently contains known vulnerabilities
- Attackers often target older versions with unpatched exploits
How to implement:
On Debian or Ubuntu-based systems:
sudo apt-get update && sudo apt-get upgrade
On CentOS, Fedora, or RHEL-based systems:
sudo yum update
Make sure to also check for firmware updates if you’re running SSH on network appliances or other hardware.
5. Implement Two-Factor or Multi-Factor Authentication (2FA/MFA)
What it is:
Adds an extra layer of security by requiring something in addition to a password or key (e.g., a one-time code on your phone).
Why it’s more secure:
- Even if attackers obtain your SSH key, they still need the second factor to log in
- Helps defend against credential theft
How to implement:
Install and Configure an MFA Tool
For example, Google Authenticator can be installed on Linux servers and set up as a PAM (Pluggable Authentication Modules) module. Follow installation instructions specific to your distribution.
Edit /etc/pam.d/sshd and /etc/ssh/sshd_config
- Enable the Google Authenticator or another MFA module
- Set ChallengeResponseAuthentication yes and AuthenticationMethods publickey,keyboard-interactive (or whichever combination suits your environment)
Restart SSH:
sudo systemctl restart ssh
6. Enable Logging and Monitoring
What it is:
Capture SSH login events, track suspicious activity, and receive alerts when something’s amiss.
Why it’s more secure:
- Intrusion attempts are often visible in logs as repeated failed logins or unauthorized actions
- Early detection means you can respond quickly—blocking IPs or changing configurations before damage is done
How to implement:
Increase Log Verbosity
In /etc/ssh/sshd_config, set:
LogLevel VERBOSE
Aggregate Logs
- Tools like syslog, rsyslog, or syslog-ng help collect and centralize logs
- A SIEM (Security Information and Event Management) solution can offer advanced analytics and alerting
Use Intrusion Prevention Tools
fail2ban scans log files and bans IPs showing malicious signs, such as too many password failures.
7. Implement Access Controls and Restrictions
What it is:
Limit who can connect to SSH and from where, preventing unauthorized or excessive inbound requests.
Ways to do it:
Firewall Restrictions
Only allow SSH from known or trusted IP addresses. For instance, on Linux with ufw:
sudo ufw allow from 192.168.1.0/24 to any port 22
Port Configuration
Running SSH on a non-standard port (e.g., 2222) can reduce automated scanning attempts. It’s not a substitute for real security measures, but it can cut down on noise.
User/Group Restrictions
In /etc/ssh/sshd_config, specify:
AllowUsers alice bob
or
AllowGroups sshadmins
8. Use SSH Key Passphrases and Secure Key Storage
What it is:
Encrypt your private key with a passphrase so that even if your machine is compromised, the key itself isn’t immediately usable.
Why it’s more secure:
- A stolen key file without a passphrase can grant instant access
- Passphrases act as an additional layer of encryption on your local key
How to implement:
Set a Passphrase During Key Generation
ssh-keygen -t ed25519
(You’ll be prompted to enter a passphrase.)
Protect Your Key Files
Restrict permissions to your .ssh folder and key files:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
Consider Hardware Security Modules (HSMs) or Tokens
For larger organizations, using dedicated hardware for key storage can mitigate risks of software-based theft or malware.
Conclusion
SSH security boils down to layers of protection. By implementing key-based authentication, disabling direct root access, using strong encryption, staying updated, requiring multi-factor authentication, monitoring logs, restricting access, and safeguarding your keys with passphrases, you cover the most common (and most serious) risks.
These measures align with the same broader security philosophy SSL.com advocates for digital certificates: protect cryptographic keys, use robust encryption, restrict privileged access, and keep vigilant watch over your systems. Once you’ve established these foundational best practices, you can explore more advanced options like SSH certificate authorities, port knocking, or running SSH over a VPN to further tailor your security posture.