Spoiler: the default SSH RSA key format uses straight MD5 to derive the AES key used to encrypt your RSA private key, which means it's lightning fast to crack (it's "salted", if you want to use that term, with a random IV).<p>The argument LVH makes here ("worse than plaintext") is that because you have to type that password regularly, it's apt to be one of those important passwords you keep in your brain's resident set and derive variants of for different applications. And SSH is basically doing something close to storing it in plaintext. His argument is that the password is probably <i>more important</i> than what it protects. Maybe that's not the case for you.<p>I just think it's batshit that OpenSSH's default is so bad. At the very least: you might as well just not use passwords if you're going to accept that default. If you use curve keys, you get a better (bcrypt) format.<p><i>While I have you here...</i><p>Before you contemplate any elaborate new plan to improve the protection of your SSH keys, consider that long-lived SSH credentials are an anti-pattern. If you set up an SSH CA, you can issue time-limited short-term credentials that won't sit on your filesystems and backups for all time waiting to leak access to your servers.
A rogue npm package is my nightmare scenario, those packages are like the only (or I wish..) untrusted code my OS is running.<p>That's why I came up with a small script/service waiting for an "inotify" event on a honey-pot SSH key (and some other files like ~/passwords.doc) which will immediately shutdown the computer on any kind of access of those files.<p><pre><code> #!/bin/sh
inotifywait -e open --fromfile ~/.config/killer/killer.cfg --outfile ~/.config/killer/killer.log
if [ $? -eq 0 ]; then
poweroff
fi</code></pre>
Okay. Sure. We should move behind the kindergarten stage of KDF selection. Still, look at the threat model. We're talking about the encryption of the private key at rest. In ~/.ssh, 0700. If an attacker can even <i>read</i> your private key file, you've probably already lost, encryption or not. That attacker can probably change your .profile to include a keylogger. You lose.<p>I mean, sure. Change the KDF default to something modern. But the threat we're discussing is marginal, and it's not as if the security of the SSH <i>network protocol</i>, which is paramount, is under threat.<p>If you care about this class of attack, you probably care about it enough to use an SSH CA anyway.
This argument seems to hinge on the following statement that I don't understand:<p>> an SSH key password is unlikely to be managed by a password manager: instead it’s something you remember.<p>Why is that the case? I've always been just as likely to use a password manager for my SSH key password—after all, I'm usually prompted for my SSH key password from my terminal, which accepts pasted passwords just fine.<p>Am I missing something?
>You might ask yourself how OpenSSH ended up with this. The sad answer is the OpenSSL command line tool had it as a default, and now we’re stuck with it.<p>Given that (as far as I know) the decryption is handled only on the client side, why does an old default matter? Does it break any kind of compatibility to change that? Why only use the better algorithm for EC keys?<p>And even if it did break compatibility it's not like it usually stops the OpenSSH folks, old ciphers and hash functions are deprecated regularly (I have to whitelist a bunch of ciphers at work to connect to legacy systems running an old dropbear).
I'm assuming that practically everybody who is a developer on ssh-keygen knows about this. This is not a bug, right?<p>It's basically bad usability, where the default is unsafe, and in order to make it safe, you have to know what you're doing. Or is it like the author writes in 'TFA' that "we're stuck with it", because it used to be a default in OpenSSL?<p>Some people will say, "if you're using ssh-keygen we can expect that you know what you're doing". But this is a wrong assumption that gets people into trouble. I'd even say a minority of people who invoke ssh-keygen really know what's going on in detail and what providing a flag like "-t ed25519" actually does. I certainly don't, and I've had to generate quite a few ssh keys so far.
This is a decent article with a click-batey title.<p>The argument that it's <i>worse</i> than paintext hinges on you both using a weak password and using the same password for something else. If you don't do either of those things then it's much better than plaintext, although technically if you use the same strong password for something else then you may have weakened the password by using it for old-format ssh ... but it still has to be brute forced.
I'd suggest following the excellent guide at <a href="https://github.com/drduh/YubiKey-Guide" rel="nofollow">https://github.com/drduh/YubiKey-Guide</a> and using one of your GPG subkeys (kept on a hardware device like a YubiKey) for SSH authentication.
How about using macOS's Keychain to store keys?<p>On recent versions, need this in your ~/.ssh/config:<p><pre><code> # for Keychain (acting as agent) to load the ssh keyfile
AddKeysToAgent yes
# For ssh to then use Keychain as an agent
UseKeychain yes</code></pre>
If you have a recent MacBook, use <a href="https://github.com/ntrippar/sekey" rel="nofollow">https://github.com/ntrippar/sekey</a> for SSH keys. Private key is stored in the built-in HSM (Secure Enclave) and access is controlled by biometrics (TouchID). You can do the same with a Yubikey, but it’s not quite as good because a) you can lose your Yubikey easily and b) there’s no biometrics.<p>Private keys stored on filesystems is an antipattern.
If you have really old clients you may apparently be able to do this instead:<p><a href="https://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html" rel="nofollow">https://martin.kleppmann.com/2013/05/24/improving-security-o...</a>
>"You might ask yourself how OpenSSH ended up with this. The sad answer is the OpenSSL command line tool had it as a default, and now we’re stuck with it."<p>Could someone elaborate on this? Is this saying that the ssh-keygen utility shells out to the openssl-command line tool which at one point defaulted to md5 for encryption? If this is the case why would be stuck with it?
It's best to assume all passwords need to have sufficient entropy to withstand a brute-force attack on some super fast hash until proven otherwise.<p>I didn't change my macOS password to 8-characters (to save myself 20 seconds a day) until I thoroughly researched what key-stretching was being used under the hood.
The author states:<p>>"Finally, most startups should consider not having long-held SSH keys, instead using temporary credentials issued by an SSH CA, ideally gated on SSO."<p>Can someone explain what "gating" SSH CA issued key with SSO means? How would SSO "gate" the keys?
Use SSH keys generated and stored on some sort of PKCS11/PIV hardware device. It’s relatively easy to do now. Don’t trust a general purpose computer to keep your keys secure.<p>Better yet, use U2F where you have control of how you are authenticated.
<p><pre><code> It’s tricky to find out what this DEK-Info stuff means
</code></pre>
This is really where the modern crypto protocols and libraries are doing well imo. Even if something that opaque is implemented perfectly, it presents a risk.
tl;dr to move to the newer more secure format use<p><pre><code> ssh-keygen -o -p -f file_name
</code></pre>
such as:<p><pre><code> ssh-keygen -o -p -f ~/.ssh/id_rsa
</code></pre>
not necessary for ed25519 as it can only be stored in the new format.
Filed <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905407" rel="nofollow">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905407</a> to change the Debian default.
Is anyone aware of a successful infiltration of a system that occurred by stealing an encrypted SSH key with a reasonably good password and successfully decrypting it?
Use key AND interactive password. This way attacker will have limited rate of password guessing and you will now from logs that your key is compromised. Your key will be used only for first step of authorization. You can slap additional password for that key but it is not even needed. Additionally from what I remember Ed25519 keys are stored by default in the new format.