Create and Protect SSH Keys

A user SSH key pair has a public half that can be installed on approved accounts and a private half that must remain under the owner’s control. Public-key login is safer and easier to revoke than shared passwords when each person, device, and purpose has a separate key. It does not remove the need to verify the server’s host key.

Choose an algorithm for the environment

For a current OpenSSH client and server, Ed25519 is a good default: it is compact, fast, and supported by current OpenSSH releases. Check the local build before relying on an algorithm:

ssh -V
ssh -Q key

On a client that lists ssh-ed25519, create a named key with a passphrase:

umask 077
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_work -C "admin-work-2026"

The command prompts for a passphrase and writes a private key and a .pub public key. The comment is an identifier, not a secret; use a useful non-sensitive label. Never put a password, token, or private material in the comment or on a command line. If the prompt says the target file exists, stop and inspect it rather than overwriting a key you may still need.

RSA remains useful for compatibility with older appliances, but it is not the first choice for a new deployment. If policy requires RSA and the installed OpenSSH supports it, use at least the size required by current organizational policy (commonly 3072 or 4096 bits):

umask 077
ssh-keygen -t rsa -b 3072 -f ~/.ssh/id_rsa_legacy -C "admin-legacy-2026"

Modern OpenSSH uses RSA keys with SHA-2 signatures when both sides support them. Very old servers may demand the legacy ssh-rsa SHA-1 signature scheme. Do not globally re-enable it or copy a compatibility snippet without a time-limited, host-specific exception approved by the security owner. Prefer upgrading the server or replacing the appliance; if an exception is unavoidable, document its scope, monitor it, and remove it after migration.

Protect the private key

A passphrase protects the private key if the file is copied. Choose a unique, long passphrase and keep it in an approved password manager. An agent can cache an unlocked key for a limited time, but it does not make a weak passphrase strong and it does not protect a compromised login session. Never email a private key, place it in source control, paste it into a ticket, or copy it to a server merely because the server needs the public key.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519_work
chmod 644 ~/.ssh/id_ed25519_work.pub
ssh-keygen -y -f ~/.ssh/id_ed25519_work > /tmp/id_ed25519_work.public
chmod 600 /tmp/id_ed25519_work.public
ssh-keygen -lf /tmp/id_ed25519_work.public
rm -f /tmp/id_ed25519_work.public

The ssh-keygen -y command derives a public key from the private key and may prompt for its passphrase; it does not transmit the private key. The temporary file is used only for inspection and is removed afterward. On systems where rm cannot reliably erase data from all storage, do not treat it as secure destruction; use the platform’s approved secret-handling procedure. Check ownership as well as mode, and never loosen permissions just to silence a client warning.

Install and authorize the public key

After verifying the host key, install only the public line on the intended account. A platform’s documented enrollment or configuration-management process is preferable. If an administrator performs a first enrollment interactively, display the public key locally and transfer that single public line through the approved, verified channel:

cat ~/.ssh/id_ed25519_work.pub

Do not paste the private key or put a password in a shell command or script. On the server, authorized_keys should normally be owned by the account and mode 600, with the home and .ssh directory not writable by other users. A key can be restricted with options such as a source address, forced command, or disabled forwarding when its purpose does not require a full shell; test a restriction in a separate session before removing recovery access.

Use one key per person or device and purpose. Record an owner, creation date, host scope, and retirement date. Remove a lost or retired public key from every authorization source, then verify that the corresponding private key is no longer accepted. Rotate keys on a documented schedule and immediately revoke or replace one suspected to be copied.

Test without weakening host verification

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_work admin@server.example

IdentitiesOnly=yes tells the client to use the specified identity instead of offering every key an agent might hold. It does not disable host-key checking. Test a new key in a second session while retaining a verified recovery path, then remove any temporary password or enrollment permission according to the server’s policy.

Continue through the sequence

Next, use ssh-agent and hardware-backed keys when a protected device can reduce private-key exposure. For host identity, revisit known_hosts verification.