Create and Verify an SSH Key Before You Install It

An SSH key pair has two unequal halves. The private key authenticates you and must remain private. The public key is the material a server may place in authorized_keys. A safe workflow verifies that relationship before anything is copied across the network.

Lab boundary: the verified portion creates and fingerprints a local key pair with OpenSSH 9.6p1. No SSH server, ssh-copy-id, or remote authentication was used in the lab. The installation section is operational guidance from the upstream manuals and must be tested against the reader’s own recovery path.

This tutorial uses Ed25519, supported by current OpenSSH. If policy, a hardware token, FIPS requirements, or an older target dictates another algorithm, follow that boundary instead of mechanically copying the command.

1. Check the tool and choose a destination

ssh -V
umask
install -d -m 700 "$HOME/.ssh"

ssh -V prints the client version. install -d creates the directory if needed and requests owner-only access. It does not change an existing directory’s mode on every implementation, so confirm it:

stat -c '%a %n' "$HOME/.ssh"

Do not overwrite an existing private key. List the intended filenames first:

ls -l "$HOME/.ssh/id_ed25519" "$HOME/.ssh/id_ed25519.pub" 2>/dev/null

If either exists, choose a descriptive new name such as id_ed25519_build.

2. Generate the pair

ssh-keygen -t ed25519 -a 64 \
  -C 'ros@workstation-2026' \
  -f "$HOME/.ssh/id_ed25519_work"

ssh-keygen prompts for a passphrase. A strong passphrase limits use of a stolen private-key file; an agent can keep the decrypted key available during a session. The -a 64 option increases key-derivation rounds for the private-key passphrase format. It does not change the strength of Ed25519 signatures 1.

The comment is an operator label, not authenticated identity. Use something that helps locate and revoke the key later without placing sensitive data in it.

Inspect modes and types:

stat -c '%a %n' "$HOME/.ssh/id_ed25519_work"*
head -n 1 "$HOME/.ssh/id_ed25519_work"
cut -d ' ' -f 1,3 "$HOME/.ssh/id_ed25519_work.pub"

Never print or paste the private-key body. Its first line identifies the file format without disclosing the secret.

3. Verify the public half twice

Fingerprint the saved public key:

ssh-keygen -lf "$HOME/.ssh/id_ed25519_work.pub"

Then derive a public key from the private file and fingerprint that stream:

ssh-keygen -y -f "$HOME/.ssh/id_ed25519_work" | ssh-keygen -lf -

The SHA256 fingerprints must match. This catches a public file paired with the wrong private key before the server is changed.

The 13 August lab used OpenSSH 9.6p1. A disposable Ed25519 pair produced the same fingerprint on both paths:

256 SHA256:oQu2F1HMmNLPCbhWWgBQYb94JpuGemhSQmrxAdfy/Gk … (ED25519)

The private file mode was 600; the public file was readable without exposing the private material. Fingerprints identify key material, so yours should be different from this lab value.

4. Install only the public key

If password login is currently permitted and the target is trusted:

Caution: ssh-copy-id changes the remote account’s authorization file. Confirm the hostname, username, host-key fingerprint, and recovery access; keep the existing session open until the new key succeeds in a second terminal.

ssh-copy-id -i "$HOME/.ssh/id_ed25519_work.pub" user@server.example

Or have an administrator add the single .pub line to the target account’s authorized-keys file. The format can attach restrictions such as source-address, command, agent-forwarding, or port-forwarding controls 4. Use those for automation accounts where the allowed action is narrower than an interactive shell.

Before accepting a new host key, verify its fingerprint over an independent trusted channel. The prompt protects against a machine-in-the-middle only when the fingerprint is actually checked 2.

Test the named identity explicitly while the old access route remains open:

ssh -o IdentitiesOnly=yes \
  -i "$HOME/.ssh/id_ed25519_work" \
  user@server.example

IdentitiesOnly=yes prevents a full agent keyring from obscuring which key succeeded 3. In another terminal, confirm login works. Only then consider tightening password authentication—and only with console or recovery access available.

5. Record and rotate

Keep the public fingerprint, purpose, owner, installation targets, and review date in an inventory. Revoke a lost or retired key by removing its public line from every target. Deleting the private file on one laptop does not remove the authorization already installed on servers.

Back up private keys only in an encrypted, access-controlled system that matches their risk. For high-value access, prefer a hardware-backed key so the private operation stays on the authenticator.

The key ceremony is complete only when the two fingerprints match, the server contains the public half, the client selects the intended identity, and a recovery path remains open.