SSH Keys: Why You Should Never Use Passwords for Servers

The Fatal Flaws of Password Authentication

When it comes to server security, passwords represent an outdated, vulnerable approach to authentication. Despite decades of security warnings, many servers still use password-based authentication, creating significant security risks. Here's why passwords fail for server security:

Brute Force Vulnerability

Internet-facing servers using password authentication are constantly targeted by automated brute force attacks. Log analysis from virtually any internet-connected server shows thousands of login attempts daily from bots scanning for weak passwords.

Credential Stuffing

When passwords are reused (as they often are), a breach on one service can compromise your servers. Attackers routinely try credentials from public data breaches against servers.

Password Sharing Risks

Teams often share server passwords through insecure channels. Once shared, passwords become nearly impossible to track and rotate properly across all team members.

The Human Factor

Under pressure to create "strong" passwords, users often choose passwords that are:

• Hard for humans to remember
• Relatively easy for computers to crack
• Written down or stored insecurely
• Rarely changed

SSH Key Authentication: The Superior Alternative

SSH (Secure Shell) key-based authentication addresses these fundamental security weaknesses through asymmetric cryptography—the same technology that powers PGP encryption.

How SSH Key Authentication Works

1. You generate a key pair: a private key (kept secret on your computer) and a public key
2. The public key is placed on the server in an "authorized_keys" file
3. When connecting, your SSH client proves you have the private key without transmitting it
4. The server verifies this using the public key

Key Advantages of SSH Keys

• Stronger mathematical security: Even a "weak" SSH key offers vastly more protection than the strongest human-memorable password
• Immune to brute force: Attackers can't brute force private keys effectively
• No transmission of secrets: Your private key never leaves your machine during authentication
• Better control and revocation: Keys can be added/revoked individually without affecting other users
• Automation friendly: Key-based authentication enables secure automated processes

Setting Up SSH Key Authentication

Step 1: Generate Your SSH Key Pair

Generate a new SSH key pair with stronger encryption using ssh-keygen -t ed25519. For older systems that don't support Ed25519, use ssh-keygen -t rsa -b 4096.

The command will ask where to save the key (accept the default location) and prompt for a passphrase. Always use a strong passphrase to protect your SSH key against theft.

Step 2: Copy Your Public Key to the Server

You can use the ssh-copy-id utility (if available): ssh-copy-id [email protected]

Or manually copy and add your public key using a combination of cat, ssh, and file redirects.

Step 3: Test Your Key Authentication

Try logging in with your key using ssh [email protected]. You should be prompted for your key's passphrase (not the server account password).

Step 4: Disable Password Authentication

Once key authentication is working, disable password authentication in the SSH server configuration by setting PasswordAuthentication no, ChallengeResponseAuthentication no, and UsePAM no in /etc/ssh/sshd_config, then restart the SSH service.

Advanced SSH Key Management

Using SSH Config Files

The SSH client config file (~/.ssh/config) lets you define host-specific settings, including which key to use for each server.

Managing Authorized Keys

On the server side, the ~/.ssh/authorized_keys file controls which keys are allowed to connect.

Key Security Best Practices

• Use passphrases: Always protect SSH keys with strong passphrases
• Key permissions: Set chmod 600 on private keys and chmod 644 on public keys
• Use SSH agents: For convenience without compromising security, use ssh-agent to cache your passphrase
• Different keys for different purposes: Use separate keys for different servers or roles
• Regular rotation: Change keys periodically, especially for high-security environments
• Physical security: Consider hardware security keys (like YubiKey) for storing SSH keys

SSH Key Authentication for Teams

Centralized Key Management

For team environments, consider:

• Using configuration management tools (Ansible, Puppet, etc.) to distribute authorized keys
• Implementing role-based access through SSH key restrictions
• Setting up SSH bastion hosts for centralized access control
• Exploring SSH certificates (covered in the next module) for enterprise-scale key management

Auditing and Monitoring

Even with key-based authentication, implement proper auditing:

• Enable detailed SSH logging
• Set up alerting for failed authentication attempts
• Periodically review authorized_keys files for unauthorized additions
• Consider tools like auditd for more comprehensive tracking

Addressing Common Objections

"But passwords are easier!"

While key setup requires a one-time effort, the daily convenience of not typing passwords and the elimination of lockouts due to forgotten passwords actually makes SSH keys more user-friendly in the long run.

"What about emergency access?"

Emergency access methods should be:

• A secondary secured SSH key stored in a secure, accessible location
• Console access through your hosting provider
• NOT a fallback password authentication option

"We need multiple people to access servers"

This is actually a strength of SSH keys—each person can have their own unique key, providing better accountability and easier revocation when someone leaves the team.

Conclusion

Password-based authentication for servers represents an outdated, high-risk approach that continues to be exploited by attackers. SSH key authentication provides a dramatically more secure alternative that is also more convenient for legitimate users.

By implementing SSH key authentication and disabling password access, you eliminate one of the most common attack vectors against servers. This single change can significantly enhance your server security posture with minimal effort.

In the next module, we'll explore SSH certificates, which build upon key-based authentication to provide even more powerful and scalable security for enterprise environments.