Configure SSH Key Authentication on Linux — A Clear, Secure Guide

Secure shell (SSH) key authentication is the recommended way to access Linux servers remotely. Compared with password-based login, SSH keys offer stronger security, convenience for automation, and better resistance to brute-force attacks. This guide explains the principles, shows detailed configuration steps, compares advantages and trade-offs, and provides practical selection and troubleshooting advice for administrators, developers, and site owners.

How SSH Key Authentication Works

SSH key authentication uses public-key cryptography. Each user generates a key pair consisting of a private key (kept secret) and a public key (shared with the server). When connecting, the SSH client proves possession of the private key without sending it across the network. The server verifies the client using the public key stored in the user’s ~/.ssh/authorized_keys file.

Key Concepts

• Private key: Stored on the client; must be protected by file permissions and ideally by a passphrase.
• Public key: Placed on the server; safe to distribute.
• Authorized_keys: Server-side file that lists accepted public keys for an account.
• sshd: The SSH daemon that handles authentication and configuration via /etc/ssh/sshd_config.
• Host keys: Server-side keys used to verify server identity to clients (stored in /etc/ssh/ssh_host_*).

When to Use SSH Keys

SSH key authentication is appropriate in almost all production environments, including:

• Remote administration of VPS instances and cloud servers.
• Automated deployment and CI/CD pipelines where non-interactive login is required.
• SFTP and secure file transfers for applications and backups.
• Multi-user hosting where each user must have individual access control.

For interactive personal use, keys with a passphrase plus an SSH agent balance security and convenience. For automation, use dedicated keys with proper restrictions (command=, from=, etc.) in authorized_keys and limit key scope.

Step-by-Step: Generating and Installing Keys

1. Generate a key pair on the client

Use OpenSSH’s ssh-keygen. Recommended modern options:

• ED25519: high security, small size, fast. Command: ssh-keygen -t ed25519 -C "your_email@example.com"
• RSA: use when ED25519 is unsupported. Prefer at least 3072 bits: ssh-keygen -t rsa -b 3072 -C "your_email@example.com"

When prompted, set a passphrase for the private key unless the key is strictly for fully automated tasks. A passphrase greatly improves security if the key file is compromised.

2. Secure the private key

• Store keys in ~/.ssh/ with permissions 700 on the directory and 600 on private keys: chmod 700 ~/.ssh; chmod 600 ~/.ssh/id_ed25519.
• Keep backups offline (encrypted) and rotate keys periodically or when a device is lost.

3. Install the public key on the server

Preferred: ssh-copy-id automates appending the public key to ~/.ssh/authorized_keys and sets permissions:

• ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server

Manual method (if ssh-copy-id not available):

• On client: cat ~/.ssh/id_ed25519.pub and copy the output.
• On server: create ~/.ssh if missing: mkdir -p ~/.ssh; chmod 700 ~/.ssh.
• Append the public key: echo "ssh-ed25519 AAAA... user@host" >> ~/.ssh/authorized_keys and set permissions: chmod 600 ~/.ssh/authorized_keys.

4. Test the connection

From the client:

• ssh -i ~/.ssh/id_ed25519 user@your-server
• Successful connection without password prompt (or with passphrase prompt for the key) indicates correct setup.

Server Configuration and Hardening

Editing sshd_config

Open /etc/ssh/sshd_config and verify the following options to enforce key-based authentication:

• PubkeyAuthentication yes
• AuthorizedKeysFile .ssh/authorized_keys (default)
• Once keys are fully tested, disable password authentication to reduce attack surface: PasswordAuthentication no
• Consider also setting: PermitRootLogin prohibit-password or no to block direct root SSH logins.

After making changes, restart the SSH daemon: sudo systemctl restart sshd (or service sshd restart on older systems).

Firewall, Fail2Ban and SELinux

• Ensure the firewall allows SSH (port 22 or a custom port): ufw allow 22/tcp or equivalent iptables/nft rules.
• Protect against brute-force attempts with Fail2Ban or similar intrusion prevention tools.
• If SELinux is enabled and you place authorized keys under unusual paths, set proper SELinux contexts (use restorecon -Rv ~/.ssh).

Advanced Topics and Best Practices

Key Types, Sizes and Algorithms

• ED25519 is recommended for most users: strong security and performance.
• RSA with 3072+ bits is acceptable if legacy support is required; avoid 1024-bit RSA.
• DSA is deprecated and should not be used.

SSH Agent and Forwarding

• Use ssh-agent or platform equivalents (e.g., ssh-pageant, macOS Keychain) to cache decrypted private keys and avoid repeated passphrase prompts.
• Avoid enabling agent forwarding on untrusted servers as it can expose keys to that host. If necessary, use with caution and only to known-trusted hosts.

Key Restrictions and Forced Commands

For automation accounts, restrict what a key can do by prepending options in authorized_keys entries. Examples:

• command="/usr/local/bin/deploy.sh",no-pty,no-agent-forwarding,no-X11-forwarding ssh-ed25519 AAAA...
• from="192.0.2.0/24" to limit the source IPs that may use the key.

Hardware Tokens and FIDO2

For higher-assurance setups, use hardware tokens (YubiKey, libfido2) to store keys. FIDO2 support in OpenSSH allows using U2F/FIDO security keys as private keys, adding physical two-factor protection to SSH authentication.

Advantages and Trade-offs

Advantages

• Stronger security: Keys are immune to simple brute-force password attacks.
• Automation-friendly: Non-interactive workflows (scripts, CI) can securely authenticate with keys.
• Granular control: Per-key restrictions and logging ease access management.

Trade-offs

• Key management adds operational overhead: creation, rotation, and proper distribution.
• Lost private keys can be abused if not protected by a passphrase and proper device security.
• Agent forwarding and weak configuration can inadvertently expose keys to compromised hosts.

Troubleshooting Common Issues

Permission errors

The most common cause of key-based login failure is incorrect permissions. Ensure:

• ~/.ssh is 700 and authorized_keys is 600.
• User home directory is not writable by others; some SSH servers reject logins if home dir permissions are insecure.

sshd logs

Check server logs for clues:

• Debian/Ubuntu: sudo tail -f /var/log/auth.log
• RHEL/CentOS: sudo tail -f /var/log/secure

Debugging from client

Use verbose SSH output to see key negotiation details:

• ssh -vvv -i ~/.ssh/id_ed25519 user@server

This will show whether the client offered the key, whether the server accepted it, and any error messages.

Selecting Keys and Server Options for Your VPS

When choosing keys for a VPS environment (for example, cloud or hosted VPS instances), consider the following:

• Use ED25519 where possible for new keys; keep RSA (3072+) for compatibility with older clients.
• Use unique keys per device and per developer; avoid sharing a single key across multiple users or systems.
• For production automation, create separate deployment keys with strict authorized_keys restrictions and dedicated service accounts.
• Implement centralized key management for larger teams (LDAP, Git-based authorized_keys management, or configuration management tools such as Ansible/Chef/Puppet).

Summary

SSH key authentication is a fundamental, high-impact security measure. By generating strong keys, protecting private keys with passphrases, configuring the server to prefer public-key authentication, and applying best practices such as limited key scope, firewall rules, and logging, administrators can significantly reduce the attack surface of Linux servers. Regular key rotation, centralized management for teams, and consideration of hardware-backed keys for high security will further harden access.

If you manage remote infrastructure or host services on a VPS, consider using a reliable provider to ensure consistent network and console access while you configure SSH keys. For those looking for VPS solutions, VPS.DO offers a range of VPS plans including options in the USA — see the USA VPS plans at https://vps.do/usa/ and explore VPS.DO at https://vps.do/.