SSH Key Authentication Setup: Why Passwords Are a Bad Default

Password-based SSH authentication is the single most common attack vector for Linux servers. Every day, automated bots scan every public IP address, hammering port 22 with dictionary passwords. If you are running a VPS with password login enabled, you are already being brute-forced. SSH key authentication replaces passwords with asymmetric cryptography, making brute-force attacks mathematically impractical.

Why Passwords Fail as a Default

A typical Linux VPS receives hundreds of failed login attempts within its first hour online. Fail2ban can slow the flood, but the underlying problem remains: a human-chosen password is a weak secret compared to a 2048-bit RSA or 25519 elliptic curve key pair. Keys are not guessable, not susceptible to dictionary attacks, and can be rotated without touching user accounts.

The second advantage is workflow automation. Ansible, Terraform, CI/CD pipelines, and deployment scripts all need non-interactive authentication. Embedding API keys or passwords in scripts is a security anti-pattern. SSH keys solve this cleanly: the private key lives on your workstation, the public key lives on the server, and no secret crosses the wire in plaintext.

Generate a Key Pair on Your Local Machine

On Linux, macOS, or WSL, run the following to generate an Ed25519 key pair. Ed25519 is faster, more secure, and better supported than legacy RSA.

ssh-keygen -t ed25519 -C "your-email@example.com" -f ~/.ssh/id_ed25519

This creates two files: ~/.ssh/id_ed25519 (private key, never share) and ~/.ssh/id_ed25519.pub (public key, safe to copy anywhere). You can also use RSA with -t rsa -b 4096 if your infrastructure requires it, but Ed25519 is preferred for new deployments.

If you already have an existing key and want to add a comment or change the passphrase, use ssh-keygen -f ~/.ssh/id_ed25519 -c. The passphrase is optional but recommended on shared workstations.

Copy the Public Key to Your VPS

The simplest method is ssh-copy-id, which handles file permissions and the authorized_keys format automatically:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@YOUR_VPS_IP

If ssh-copy-id is not available, you can append the key manually:

cat ~/.ssh/id_ed25519.pub | ssh root@YOUR_VPS_IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

The critical detail is file permissions. The ~/.ssh directory must be mode 700, and authorized_keys must be mode 600. SSH will refuse to use keys if the permissions are too open.

Disable Password Authentication

Once you have confirmed key-based login works, disable password authentication entirely. Edit the SSH daemon configuration on your VPS:

sudo sed -i 's/^#?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#?PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
sudo systemctl restart sshd

This forces all users to authenticate with keys. Root login is restricted to key authentication only. Before restarting sshd, open a second terminal and test your key login to avoid locking yourself out.

Harden Further with Agent Forwarding and Key Rotation

For jump-host workflows, SSH agent forwarding lets you use a local key to authenticate through an intermediate server without copying private keys to the jump host:

ssh -A root@JUMP_HOST ssh root@TARGET_HOST

Set up key rotation with a cron job or use a tool like ssh-audit to scan your server periodically for weak algorithms. A clean sshd_config with only modern ciphers, no password login, and root key-only access eliminates the vast majority of SSH attack surface.

Takeaway

Generating an Ed25519 key pair, copying the public key, and disabling password authentication is a ten-minute task that removes the most common attack vector from your VPS. Spin up a Linux VPS on Netbay in under 60 seconds and follow along at netbayhosts.in.