Moving Beyond Passwords: Implementing SSH Key Authentication with PuTTY

The Vulnerability of the Password Prompt

\n

Relying on passwords for remote server access creates a persistent security bottleneck. Passwords are susceptible to brute‑force attacks, credential stuffing, and human error. Even with a complex password, the manual entry process is tedious for engineers managing multiple environments.

\n

The solution is Public Key Infrastructure (PKI). By replacing a shared secret (the password) with a cryptographic key pair, you ensure that only the holder of a specific private key file can access the server. In the PuTTY ecosystem, this requires a specific workflow involving PuTTYgen and the .ppk file format.

\n\n

Generating the Key Pair with PuTTYgen

\n

PuTTY does not natively use the OpenSSH key format found in Linux or macOS. Instead, it uses a proprietary format with the .ppk (PuTTY Private Key) extension. To create these, you must use PuTTYgen, the standalone key generator utility.

\n

When generating a key, you will encounter a choice of algorithms. While RSA is the most universally compatible, Ed25519 is the modern standard for better security and smaller key sizes. If your server is running an outdated version of OpenSSH (pre‑6.5), you may need to stick with RSA, ensuring the bit‑length is at least 2048 or 4096.

\n

Crucially, you should apply a Key Passphrase. This encrypts the private key on your local disk, meaning that if your laptop is stolen, the attacker still cannot use the key without the passphrase.

\n\n

Deploying the Public Key to the Server

\n

The private key stays on your machine. The public key—the string of text displayed in the PuTTYgen window—must be placed on the remote server. The SSH daemon (sshd) checks this list during the handshake to verify your identity.

\n

The public key must be appended to the ~/.ssh/authorized_keys file in the user’s home directory. A common point of failure is incorrect file permissions; the SSH daemon will ignore the key if the directory or file is world‑writable.

\n\n

Example: Manual Key Installation

\n

Assuming you have temporary password access to your server, run these commands on the remote Linux server as the target user:

\n

# Create the .ssh directory if it doesn't exist
mkdir -p ~/.ssh\n\n# Set directory permissions to read/write/execute for the owner only
chmod 700 ~/.ssh\n\n# Append the public key string from PuTTYgen to the authorized_keys file
# Replace 'ssh-rsa AAAAB3...' with your actual public key string
echo \"ssh-rsa AAAAB3...user@workstation\" >> ~/.ssh/authorized_keys\n\n# Set file permissions to read/write for the owner only
chmod 600 ~/.ssh/authorized_keys

\n

Risk: If you disable password authentication before verifying the key works, you may lock yourself out of the server permanently.

\n\n

Configuring PuTTY for Automatic Login

\n

Once the server is prepared, you must tell PuTTY which private key to present during the connection attempt.

\n

\n
1. Open PuTTY and navigate to Connection > SSH > Auth (In newer versions, this is under Auth > Credentials).
\n
2. In the Private key file for authentication field, browse to and select your .ppk file.
\n
3. Return to the Session category, enter your hostname, and save the session to avoid repeating this configuration.
\n

\n\n

Streamlining with Pageant

\n

Entering a key passphrase for every single session is a friction point. Pageant is an SSH authentication agent that runs in the background. You load your .ppk file into Pageant once at the start of your workday, and PuTTY will automatically query Pageant for the key whenever you connect to a server. This provides the security of an encrypted key with the convenience of a passwordless login.

\n\n

Limitations and Verification

\n

The primary limitation of this setup is the proprietary nature of .ppk files. If you need to move your keys to a Linux‑based SSH client, you must use the "Conversions" menu in PuTTYgen to export the key to OpenSSH format.

\n

To verify the authentication was successful and not falling back to a password, check the server's authentication logs. Run the following command on the remote server with sudo privileges:

\n

sudo grep "Accepted publickey" /var/log/auth.log

\n

If you see an entry matching your username and the timestamp of your login, the cryptographic handshake was successful.