How to Make Your SSH Password More Secure

SSH passwords are inherently vulnerable to brute-force attacks, making strong password creation only the first step. True security requires disabling password authentication entirely in favor of SSH keys, enforcing strict access controls via sshd_config, and implementing multi-factor authentication. This approach eliminates the risk of credential guessing while maintaining secure remote access.

The Limitations of Password-Only Authentication

While creating a complex password is better than using a simple one, it does not solve the fundamental problem of how SSH handles authentication. The Secure Shell protocol allows for various methods, but relying solely on a password exposes your server to dictionary attacks and brute-force attempts. Attackers can use tools like Hydra or Medusa to test millions of combinations against your open port 22.

Even with a high-entropy password, the risk remains because the server must store or verify this secret in a way that can be intercepted or guessed if the network traffic is compromised. Therefore, enhancing security means moving away from shared secrets toward public-key cryptography. This shift ensures that even if an attacker knows your username, they cannot gain entry without the corresponding private key.

Generating and Deploying SSH Keys

The most effective way to secure your SSH connection is to generate an RSA or Ed25519 key pair and deploy the public key to your server. Start by generating a new key on your local machine using the following command:

ssh-keygen -t ed25519 -C "[email protected]"

This command creates a key pair using the Ed25519 algorithm, which is faster and more secure than older RSA implementations. You will be prompted to save the file and set a passphrase for the private key. This passphrase adds an extra layer of protection; if someone steals your private key file, they still cannot use it without knowing this second secret.

Next, copy the public key to your remote server. You can do this manually by appending the content of ~/.ssh/id_ed25519.pub to the ~/.ssh/authorized_keys file on the remote host, or use the convenient ssh-copy-id utility:

ssh-copy-id user@remote_host

Once deployed, you can test the connection by attempting to log in. If configured correctly, the server will challenge you with the key signature rather than asking for a password. For detailed steps on securing the host after connecting, consider reviewing Securing Host After Connecting Through OpenSSH: A Comprehensive Guide.

Disabling Password Authentication

After confirming that your key-based login works reliably, you must disable password authentication to prevent fallback attacks. Edit the SSH daemon configuration file, typically located at /etc/ssh/sshd_config. Look for the directive PasswordAuthentication and set it to no:

PasswordAuthentication no

You should also ensure that PubkeyAuthentication is set to yes. After saving the changes, restart the SSH service to apply the new settings. On systemd-based systems, use sudo systemctl restart sshd. This change ensures that even if an attacker discovers your password, they cannot use it to log in.

Implementing Multi-Factor Authentication

If disabling password authentication is not immediately feasible due to legacy system constraints, you can implement Multi-Factor Authentication (MFA). OpenSSH supports PAM (Pluggable Authentication Modules), which allows you to integrate third-party MFA solutions. Tools like Google Authenticator can be installed on the server to require a time-based one-time password (TOTP) in addition to your standard credentials.

To configure this, install the PAM module for Google Authenticator and run google-authenticator as your user. This generates a QR code and secret key for your authenticator app. Then, modify /etc/pam.d/sshd to include the required PAM module. Finally, update sshd_config to enable ChallengeResponseAuthentication. This setup ensures that possession of the password alone is insufficient for access.

Hardening SSH Configuration Further

Beyond authentication methods, several other settings in sshd_config contribute to overall security. Disable root login by setting PermitRootLogin no. This prevents attackers from targeting the most privileged account directly. Instead, log in as a regular user and use sudo when necessary.

Additionally, restrict the SSH protocol version to 2 by ensuring Protocol 2 is specified, although modern versions of OpenSSH default to this. Limit the number of authentication attempts with MaxAuthTries 3 to slow down brute-force attacks. Consider changing the default port from 22 to a non-standard port to reduce noise from automated scanners, though this is security through obscurity and should not be relied upon as a sole defense.

For insights into managing complex SSH setups across multiple gateways, see Understanding Different Hash Values in SSH-Keygen SHA256.

Frequently Asked Questions

What happens if I lose my SSH private key?

If you lose your private key, you will be locked out of the server unless you have another method of access. You must regain console access physically or through a cloud provider’s recovery console to remove the public key from the authorized_keys file. Always keep encrypted backups of your private keys in a secure location.

Can I use SSH keys with Windows?

Yes, modern Windows 10 and 11 include OpenSSH client support natively. You can generate keys using PowerShell commands similar to Linux, such as ssh-keygen -t ed25519. You can also use PuTTYgen to create keys in PuTTY format if you prefer traditional Windows SSH clients.

Is it safe to leave the SSH port open to the internet?

Leaving port 22 open increases exposure to scanning and attack attempts. While strong authentication mitigates many risks, it is safer to restrict access using firewall rules (like UFW or iptables) to allow only specific IP addresses. Alternatively, use a VPN to connect before accessing SSH.

How do I rotate SSH keys regularly?

To rotate keys, generate a new key pair and add the new public key to the server alongside the old one. Test login with the new key, then remove the old public key from authorized_keys once you confirm the new key works. This process minimizes downtime and maintains continuous security.

Why is Ed25519 preferred over RSA?

Ed25519 offers stronger security with smaller key sizes and faster performance compared to RSA. It is less susceptible to implementation errors and provides better resistance against certain cryptographic attacks. Most modern servers and clients support Ed25519 by default.