Authenticating by Public Key (OpenSSH)

Securing Remote Access with OpenSSH Public‑Key Authentication

When you log into a remote machine with SSH, you’re usually asked for a password. That simple step, while convenient, exposes your credentials to a range of threats. Anyone who can sniff traffic or crack the password with brute force can get in. Public‑key authentication flips the script. Instead of sending a password over the network, you prove you own a private key that matches a public key the server already knows. The private key never leaves your machine, so eavesdroppers never see it, and an attacker who steals the file on your laptop still needs the passphrase you set to make use of it. That small extra layer turns a fragile login method into a robust, cryptographically secure one.

The OpenSSH suite, bundled with nearly every Linux distribution, is the de‑facto standard for SSH. It handles the heavy lifting of key negotiation, encryption, and session management, allowing you to focus on the higher‑level tasks of generating, deploying, and managing keys. Because SSH is stateless, a key pair can be reused across many hosts, making it a scalable solution for administrators who manage dozens or hundreds of servers.

Public‑key authentication works through a simple workflow: you generate a key pair on your client, keep the private part secret, and copy the public part to the server. When you connect, your client signs a challenge with its private key; the server verifies the signature against the stored public key. If the verification succeeds, the server grants you access. The process is fast and does not require any data to travel in plain text. As long as you protect your private key file with a strong passphrase, even if someone obtains the file from a compromised laptop, they cannot log in without the passphrase.

Before you begin, ensure that the SSH server you’re targeting is configured to accept key authentication. OpenSSH’s default settings already allow it, but if you’re working with a custom configuration, you may need to set “PubkeyAuthentication yes” in /etc/ssh/sshd_config and reload the daemon. On the client side, the ssh binary will look for keys in ~/.ssh unless you override that with the -i flag. All modern OpenSSH installations support RSA, ECDSA, Ed25519, and older DSA keys, but RSA and Ed25519 are the most common choices today.

One thing to remember is that older versions of OpenSSH used a separate authorized_keys2 file for SSH‑2 protocol keys. That distinction has been removed in current releases; all public keys now belong in authorized_keys. If you encounter an old server, simply copy the key to the older file or upgrade the server to a newer OpenSSH version.

Below you’ll find a step‑by‑step guide to setting up key authentication, from key generation to troubleshooting. The commands are written for a typical Linux or macOS environment, but the same principles apply to other operating systems that support OpenSSH. Use this as a reference whenever you need to secure a new host or audit an existing setup.

Generating a Secure Key Pair

Begin by ensuring you have an ~/.ssh directory with the right permissions. On most systems, the default user account already has a home directory, but you may need to create the subdirectory if it’s missing:

The ssh-keygen utility creates the pair. If you want the strongest security, choose Ed25519, which provides 256‑bit security with smaller keys and faster operations:

The -a 100 flag tells the tool to apply the key derivation function 100 times, which slows down brute‑force attempts against the passphrase. You’ll be prompted for a file name; pressing Enter will accept the default. Then you’ll set a passphrase. Pick something strong - long, random, and a mix of characters - because this is the last line of defense if the private key file is ever exposed.

After you run the command, you’ll see two files: id_ed25519 (the private key) and id_ed25519.pub (the public key). The private key should stay on your client and never leave your machine, so keep it secure. The public key is what you’ll send to the server. You can inspect it with cat ~/.ssh/id_ed25519.pub; it should look like a long string beginning with ssh-ed25519 followed by a base64 block and your comment string, often the user’s email or hostname.