Skip to content

SSH keys

ED25519 added in 1.3.0. RSA unchanged.

New keys are ED25519 by default. Generate one, deploy it to a host, and connect with it. RSA is still there and still works — it is now labelled as the compatibility choice rather than the default.

Generating a key

  • ED25519 is the default. Short, fast, and what current OpenSSH prefers. There is no key size to choose — the algorithm has one.
  • RSA for older equipment that has not caught up. The key-size box only appears when RSA is selected, because it never meant anything for ED25519 and offering it implied otherwise.
  • A passphrase is optional and works throughout for both types — generation, import, deployment and authentication. It is held in your operating system's vault, never in a config file.
  • Adding a key under a name you are already using is refused rather than accepted. Two entries with the same name and different key material is not a situation worth being polite about.

Importing a key you already have

Both formats the dialog offers actually work now. A file beginning -----BEGIN OPENSSH PRIVATE KEY----- imports, as does a traditional PEM one.

Before 1.3.0, importing an OpenSSH-format key failed with an OpenSSL error while the dialog promised "PEM or OpenSSH" — which is nearly every ED25519 key in existence, since that is what ssh-keygen writes. Parsing now goes through ssh2, the same parser that later authenticates with the key, so a key that imports is a key that connects.

That was issue #1, reported by CrustyB, who worked out the cause correctly and proposed the fix that was used.

Why it took until 1.3.0

Not an oversight so much as a format problem. Node exports ED25519 private keys as PKCS#8, and OpenSSH rejects that outright — so a key generated that way was written, looked plausible, and then would not authenticate anywhere. Rather than ship that, earlier releases generated RSA only.

1.3.0 writes OpenSSH's own container directly. The result is an ordinary -----BEGIN OPENSSH PRIVATE KEY----- file that any other tool will read.

Deploying a key to a host

The ssh-copy-id-style workflow is built in: pick the key, pick the connection, authenticate once with a password, and the public key is appended to that account's authorised keys. After that the connection uses the key.

How this was tested

Worth stating plainly, because "we generate keys now" is easy to claim and unpleasant to get wrong:

  • Every generated key is handed to the real ssh-keygen -y binary, which must derive the same public key from it — encrypted and unencrypted alike. If the two disagree the build fails.
  • Against OpenSSH 9.6p1, a key is generated, deployed and used to authenticate, end to end.

Upgrading

Nothing to do. Existing RSA keys and the connections that use them keep working untouched — generation, storage and authentication for RSA are all unchanged. ED25519 is an addition, not a replacement.