SSH Keys: Generating Your Cryptographic Identity

Passwords are guessable. Cryptographic keys are not. Moving from password-based SSH to key-based authentication is the single highest-impact security upgrade you can make to any remote server — and it starts entirely on your own machine, before the server ever enters the picture.

Why Passwords Are Not Enough

Password authentication has a structural weakness: there is a secret traveling toward the server, and a human chose it. That combination is exactly what automated attackers exploit. Any machine listening on port 22 of the public internet is probed continuously by bots running through dictionaries of common passwords, lists of default credentials, and username-password pairs harvested from old data breaches. The scale is not subtle — independent honeypot studies regularly report hundreds of millions of login attempts against exposed SSH services, and freshly provisioned servers with weak passwords are often compromised within hours of going online.

Key-based authentication makes the entire category of attack pointless. Instead of sending a secret toward the server, your client signs a cryptographic challenge that only your private key can produce. The private key never travels across the network. There is nothing for a bot to guess, no matter how many attempts it makes.

That is the prize. The rest of this article is about claiming it: generating the key pair on your own machine, understanding what gets created, and protecting those files correctly. Everything in this article happens locally — the server does not enter the picture yet.

Two Algorithms Worth Knowing

An SSH key is a pair of mathematically linked keys: a private key you guard and a public key you hand out freely. The algorithm that produces them determines their size, their speed, and how much you can trust them in the long term. OpenSSH supports several; in practice the choice is between two.

Ed25519 is the modern default. It is built on elliptic-curve cryptography, which delivers strong security with tiny keys — an Ed25519 public key is a famously compact 68 characters or so, compared to the long block of an RSA key. It generates fast, signs fast, and verifies fast. Modern OpenSSH (version 6.5 and later, released January 2014) supports it out of the box. As of OpenSSH 9.5, released in October 2023, ssh-keygen generates Ed25519 keys by default. Unless you have a specific reason not to, this is what you want.

RSA is the older workhorse. Its security relies on the difficulty of factoring very large numbers — a problem that has gotten easier over time, which is why RSA keys must keep growing to stay safe. 1024-bit RSA is broken and blocked by modern clients. 2048-bit is legacy. 3072-bit (today's ssh-keygen default for RSA) or 4096-bit are the recommended sizes. RSA's one real advantage is ubiquity: if you must connect to an old server, network appliance, or embedded device that predates 2014, RSA is your fallback.

You may also see ECDSA and DSA mentioned. Avoid both for new keys. ECDSA is elliptic-curve based like Ed25519 but offers no advantage and carries concerns about its NIST-defined curves. DSA is obsolete, limited to weak key sizes, and has been removed from modern OpenSSH entirely.

Running ssh-keygen

The tool that creates keys is ssh-keygen, included with every OpenSSH installation. The command to generate a modern key is one line:

Two flags are worth understanding before you run it:

-t ed25519 specifies the key type. On current OpenSSH this is the default, so technically -t is optional — but stating it explicitly makes your intent unambiguous and protects you from older systems where the default might still be RSA.

-C "alice@laptop-2026" sets a comment that gets appended to the end of the public key. It does not affect security or function — it is a human-readable label to help you identify the key later. If you omit it, ssh-keygen defaults to user@hostname, which is often unhelpful. A meaningful comment such as your email or a device identifier makes keys easy to recognize when several appear on a server. You can change the comment later without invalidating the key.

Running the command opens an interactive session that asks you two questions:

The first question — where to save the key — should almost always be answered by just pressing Enter. The default location, ~/.ssh/id_ed25519, is where SSH automatically looks when you try to authenticate. Saving the file anywhere else means you will have to point to it explicitly every time you connect. The only reason to choose a different name is if you already have a key there and want to keep both.

The second question — the passphrase — is more important than it looks.

The Files You Just Created

Two new files now sit inside the ~/.ssh/ directory on your machine:

If you open the public-key file, you will see something unexpectedly simple: a single line of text. Despite being the foundation of secure access to a server, it is just three space-separated fields.

Because it is just text, you can email a public key to someone, paste it into a web form, or print it on a piece of paper without any loss of security. The private key is the one that demands real care.

Why Permissions Matter

SSH is deliberately strict about the permissions on these files. If the private key is readable by other users on your machine, the SSH client will refuse to use it and abort the connection — better to fail loudly than to use a key that may have been exposed. The same logic applies to the .ssh directory itself.

The rules are simple:

When ssh-keygen creates the files itself, it sets these permissions correctly. The time you need to fix them by hand is when you copy a key from one machine to another, or restore it from a backup, and the permissions arrive too open. The commands to repair them are short:

If SSH ever complains with a message like Permissions 0644 for '/home/alice/.ssh/id_ed25519' are too open, this is what it wants you to fix. The error is annoying the first time you see it, but it exists to protect you from your own filesystem.

At this point you have a working key pair sitting in ~/.ssh/: a private key that proves your identity and a public key safe to share. The server still knows nothing about you — placing the public key onto a remote machine, testing the login, and hardening the server are the steps that come next.