Show HN: Drop SSH private keys in exchange for keygen via PRNG and Ed25519

by imcotton on 3/12/2024, 8:15:52 PM with 2 comments
(tldr; visit https://jsr.io/@key/gen-ssh-ed25519 for details)

I have a hot take: the ~/.ssh folder should NOT contain private keys.

A private key is generated on the first day of computer setup and remains there permanently. It will have mode 600 if not misconfigured, and may also have a passphrase for protection (you do ... do you?). So, what's the catch?

During its entire lifespan, which can be months or even years, those private keys can be compromised in just a matter of seconds. This could happen if someone types "curl -d" in the command line on your behalf during a coffee break, or if an NPM package with numerous intermediate dependencies' postinstall scripts to send it elsewhere, even if guarded by a passphrase, ask yourself how confident you are that phrase you have will survive offline brute-force attacks?

ssh-agent to the rescue.

If you've enabled AddKeysToAgent and UseKeychain in your ~/.ssh/config file, you can safely remove your private key from the disk after it's automatically added to the ssh-agent (verify by ssh-add -L). This protects against all kinds of attacks, however, if you reboot your system, you'll need to set everything up again.

Thus the reproducible keygen comes into play, in a nutshell, instead of relying on entropy taken from /dev/random and letting the end user hold on to it safely forever (how?), let's use well-configured PRNG (i.e. PBKDF2 - SHA512 - 400,000 rounds in 2024 from native webcrypto in this case) with better algos (Ed25519 instead of RSA), to generate the same private key on demand on-the-fly, once the private key added onto ssh-agent, then just delete it from the disk, this greatly reduced the attack surface of the private key, no private key left means nothing to leak at the first place.

The last piece of the puzzle is coming up with a manageable salt/passphrase for PRNG, this can vary depending on your threat modeling, I will provide a few examples for inspiration, but you should choose what works best for you:

- UUID generated from system entropy, put into ~/.ssh/config as a vague comment yet you can retrieve it later on

- a strong password generated by password managers and safely stored across multiple devices

- any git commit hash that is unrelated whatsoever, this can come from one of your side projects or even some opensource project, as long as you don't lose the trace from your mental memory

- Merkle tree root hash from any given height of the blockchain

- specific version of any pkg (i.e. npm or crates) tarball's checksum

- your favorite number multiplied by the year of choice and cubed, i.e. (42 * 2024) ^ 3

- chunk of pi digits

etc...

The program is released on JSR (https://jsr.io/@key/gen-ssh-ed25519) and designed to be executed by Deno which is secure by default, it reads from command args and emits to stdout, without any file, network, or environment access.

Credit to Paul Miller by his NPM package (https://www.npmjs.com/package/ed25519-keygen) for the heavy lifting.

What is your opinion? Do you have any other suggestions or did you notice any oversights?

  • by Dibby053 on 3/12/2024, 8:32:38 PM

    There used to be a website that provided an easy way to derive bitcoin addresses from passwords. Random people would routinely send bitcoin to wallets with passwords like "123456", "correct horse battery staple", digits of pi and so on only to see their coins stolen by bots in a matter of miliseconds.

    This is not as bad but people will inevitably use bad passwords if given the option so it's better not to make things too easy for them in my humble opinion.

  • by dave4420 on 3/12/2024, 8:23:18 PM

    I keep my private keys stored in my password manager.