A rogue npm package is my nightmare scenario, those packages are like the only (or I wish..) untrusted code my OS is running.
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.
#!/bin/sh
inotifywait -e open --fromfile ~/.config/killer/killer.cfg --outfile ~/.config/killer/killer.log
if [ $? -eq 0 ]; then
poweroff
fiOkay. 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 read 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.
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 network protocol, which is paramount, is under threat.
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:
> an SSH key password is unlikely to be managed by a password manager: instead it’s something you remember.
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.
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.
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?
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?
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?
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.
The argument that it's worse 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 https://github.com/drduh/YubiKey-Guide and using one of your GPG subkeys (kept on a hardware device like a YubiKey) for SSH authentication.
I wrote this; happy to answer questions.
How about using macOS's Keychain to store keys?
On recent versions, need this in your ~/.ssh/config:
# for Keychain (acting as agent) to load the ssh keyfile
AddKeysToAgent yes
# For ssh to then use Keychain as an agent
UseKeychain yesIf you have a recent MacBook, use https://github.com/ntrippar/sekey 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.
Private keys stored on filesystems is an antipattern.
My ssh key is stored in a yubikey. Haven’t had to type a password for ssh purpose in a long time!
If you have really old clients you may apparently be able to do this instead:
https://martin.kleppmann.com/2013/05/24/improving-security-o...
>"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."
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.
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:
>"Finally, most startups should consider not having long-held SSH keys, instead using temporary credentials issued by an SSH CA, ideally gated on SSO."
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.
Better yet, use U2F where you have control of how you are authenticated.
It’s tricky to find out what this DEK-Info stuff means
tl;dr to move to the newer more secure format use
ssh-keygen -o -p -f file_name
ssh-keygen -o -p -f ~/.ssh/id_rsa
Filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905407 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?
What are you thoughts on using Krypton? https://krypt.co
All my ssh key passwords are generated from password managers. They are random and strong.
What if you generate the public and private keys without a password but keep it blank?
I'm finally vindicated for not using a password on my key :P
Does this affect non-RSA key types too? I use ecsda25519.
So is that what happened? Somebody got a hold of one of the developers' private SSH keys, and cracked the encryption?
Seems like gpg auth would be a much better choice the ssh keys
Get paid weekly by PayPal free to join click below for more information when you become a free member watch all the tutorial videos join the amazing facebook group learn step by step training from the best of the best free to start earning commission make money online Internet marketing opportunity try our marketing courses learn how to run a business from the ground up plus make money online real legitimate company Internet marketing opportunity for more information click below to join https://internetmarketingsolution.club
Nice deflection of the real madness here that a compromised npm package gets to read stuff in your user directory.
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.
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).
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 more important than what it protects. Maybe that's not the case for you.
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.
While I have you here...
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.