19 ms·
The default OpenSSH key encryption is worse than plaintext
- tptacek 8y agoSpoiler: 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.
- X-Istence 8y agoIs there an openssl command to translate the old key format to the new key format while keeping the same RSA key which works with OpenSSH?
- tptacek 8y agoI think ssh-keygen -p -o -f (oldfile) should do the trick.
- lima 8y agoAnd/or use a smartcard to store your SSH keys. With YubiKey 4 being as cheap as they are, there's little excuses :-)
- tptacek 8y agoThis is what I meant by "elaborate new plans". I like Y4's as much as the next nerd, but if you're going to put that kind of energy in, spend the energy on setting up an SSH CA.
- knorker 8y agoOne does not exclude the other. If it did then a hardware token like Yubikey easily beats a CA.
- deleted 8y ago[deleted]
- lvh 8y agoHow does it "easily beat" a CA? It's still a long-held credential that you now have to manage across a fleet instead of a single SSH CA. You can get that short-term credential via a long-held key; that long-held key can even live on a Yubikey if you use U2F/WebAuthn. You get all of the security and usability benefits of U2F/WebAuthn as well as the off-boarding/on-boarding/compliance benefits of tying everything to SSO as well as the audit benefits of an SSH CA.
- knorker 8y agoYou can work around not having a CA, by distributing keys. I'm exaggerating when I say "just write a script", but it's not hard. You cannot work around not having hardware keys. SSH CAs improve efficiency and convenience. A hardware key that requires touch per login is a game-changer. When you go do lunch you know that your key did nothing, no matter how compromised your workstation is. When your machine is turned off you know that there's no copy of the key somewhere. That key cannot be used. A software cert-based key may be valid for only hours (if you set it up that way), but that means that there are 7 billion possible attackers who could use your key. They could break into your workstation and wait for the screensaver to kick in, and then log in to every single host you have access to, and do their naughty business. For a hardware key someone has to take a plane from China and break into your house to use your key. > It's still a long-held credential Doesn't have to be. But if it is, so what? Given physical locks that are unpickable and keys uncopyable, would you rather instead change locks every day, where the keys are copyable? (even if cost of changing locks scales O(1) with price) > that long-held key can even live on a Yubikey if you use U2F/WebAuthn Like I said, one does not exclude the other. You can't prove that A is better than B by saying A+B is better than B. There's also devices that don't support SSH certificates (e.g. embedded devices), but supporting pubkeys is vastly more common.
- cperciva 8y agoSpoiler: 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). Indeed, I pointed this out in my May 2009 talk about scrypt (http://www.daemonology.net/papers/scrypt-slides.pdf http://www.daemonology.net/papers/scrypt-slides.pdf). There were even OpenSSH developers in the room!
- lvh 8y agoAnd a mere four years later they added a format that uses bcrypt... in a PBKDF2 construction? (I haven't found a motivation why, though Ted Unangst's post on it just says "I know about scrypt".)
- tedunangst 8y agoScrypt is "excessively parameterized." ;)
- dijit 8y agoI don't mean to sound stupid; but I am, so it comes out that way. What does this mean? Does it mean it's hard to use, or easy to mess up or something else?
- aw1621107 8y agoMy first guess would be that it has "too many parameters/knobs". I guess that could implicitly mean it's hard to use/easy to mess up if you don't know what each parameter means and what different values have.
- user5994461 8y agoI guess the same. Not sure why the downvote. The latest crypto functions expect the developer to pick parameters for the memory usage, the time to run and god knows what. Too low and it's worse than MD5, too high and your login prompt takes a whole minute to check the password.
- tedunangst 8y agoI think the explanation for most bad defaults in ssh is "redhat" which is kinda insane but I very much stay out of that sandbox. The default can't be changed until existing systems can read the new keys. So like 2028 or something.
- irrational 8y agoWhy can't it be fixed and then just break for Redhat (until Redhat rolls out fixes/patches)?
- detaro 8y agoFor the key storage format, not the key type, wouldn't that only be a problem where you copied a key to a redhat system? Requiring conversion there doesn't sound too bad?
- cbhl 8y agoYou're basically asking a "you broke my workflow" kind of question. https://xkcd.com/1172/ https://xkcd.com/1172/ In high school, I definitely kept password-protected private keys on a USB key that got plugged into whatever machine happened to be available. (Now I am affluent enough to carry around a real Security Key and a trusted laptop.) If you were the maintainer, would you really want to change the defaults and deal with the backlash of complaints from users who do copy keys around?
- jessaustin 8y agoEven the OpenSSH people will tell you not to copy private keys around. Non-ephemeral private keys should be generated where they will be used. You can copy the public key...
- Dylan16807 8y agoOkay I generated a key on a computer that I will only be using for the next 3 hours, and may never see again. How do I install it? Is that method actually more secure than carrying around an encrypted key?
- sneak 8y agoThe KDF used for password-based symmetric encryption (gpg -c, private keys on disk) in GnuPG is also terrible - but at least it is an iterated KDF of a fast function, as opposed to one-shot. I would happily put up funds for a bounty to fix the default in GnuPG but I don’t know where to post/fund such a thing.
- mrrandomguy11 8y agoYou would have to change the OpenPGP standard - other implementations would have to follow that.
- sneak 8y agoThe iteration count is serialized into the message.
- old-gregg 8y ago> consider that long-lived SSH credentials are an anti-pattern. Exactly. Consider switching to auto-expiring SSH certificates. You can build your own certificate management using a few open tools or switch to Teleport [1] which is 100% certificate based and doesn't even support keys. Disclaimer: I am one of the contributors. [1] https://github.com/gravitational/teleport https://github.com/gravitational/teleport
- nerdponx 8y agoThanks for this. I will happily check out your tool, but what are some of the other solutions in this area?
- lvh 8y agoThere’s also BLESS and Hashicorp Vault. I have a penchant for Teleport.
- pvg 8y agoOh! Teleport does look pretty decent now that I've forced myself to look at it after going through this thread. I mention this mostly for the sort of people like me who read 'SSH CA' and their eyes roll into the backs of their heads and they start rocking and making saliva bubbles at thought of PAM modules and LDAP servers and so on. But this doesn't look nearly as bad. Go ssh implementation sounds like a nice ancillary bonus.
- thenewwazoo 8y agoIt’s probably pretty rotted by now but I wrote a version of this while I worked at Microsoft called ALTAR that’s backed by Azure services.
- peterwwillis 8y agoI just went to the top 20 search results for "how do I generate ssh keys". Almost none of them use the defaults. Almost all of them suggest to use "-t rsa", and some with "-b 4096". The ones using defaults are from Joyent, SSH.Com, and git-scm.com. Since probably nobody is creating SSH keys without using a guide first, we should be able to get websites to update their guides with better default arguments, which will improve things going forward. Almost all the Windows guides suggest using PuTTYgen with defaults, which gives you a 1024 bit RSA key, and that might be worse in the long run than these password shenanigans.
- tptacek 8y ago"-t rsa" uses the same terrible format as the default.
- peterwwillis 8y agoI'm saying that since they mostly don't use defaults, it should be trivial to argue for a few extra arguments.
- bigfudge 8y agoWhat would that look like?
- wvh 8y ago-o, for the newer key format. Or use -t ed25519 to generate ed25519 (elliptic curve) keys. I do recollect that using RSA keys of 4096 bits slows down SSH more than the gain in security might be worth.
- lvh 8y agoLook, 2048 is fine. Assuming no algorithmic speeduos you get 112 bits of security and that’s plenty. But SSH keys are only used to sign: they don’t affect bulk encryption. 4096’s performance is not what’s holding you back.
- mmcclellan 8y agomonitoring thread for mentions of tooling. Seen teleport and vault - no mention yet of bless/blessclient yet.
- throwawaymath 8y agoWhy hasn't anyone done for OpenSSH what Jason Donenfeld did with Wireguard?
- pgeorgi 8y agouse wireguard with telnet/ftp bound to it
- e12e 8y agoI guess that should be wireguard with rsh.
- lvh 8y agoOxy is trying: https://github.com/oxy-secure/oxy https://github.com/oxy-secure/oxy But it’s important to remember that SSH is a lot less fucked overall than the VPN situation was. People mostly grok SSH. SSH mostly doesn’t negotiate BF-CBC.
- tptacek 8y agoI disagree! SSH is not great! Because it doesn't need to support every browser on the Internet, new crypto percolates through the ecosystem much faster than it does in TLS. But it's still a janky protocol with dumb options, and a Noise-based no-negotiation alternative that fulfilled the same interface would indeed be super useful.
- lvh 8y agoI don’t think we actually disagree; I said “a lot less fucked” not “great” :) you can get real AEADs with Ed25529 in SSH easily; and some of the dumb options problems may still apply with Oxy, depending on what you’re taking about.
- textmode 8y agoI have been using tinysshd for a number of years and I am hooked. Keen to experiment, I have also been using ed25519 keys instead of rsa since this option was added to openssh. No one told me to use tinysshd or ed25519 keys. As someone else pointed out, it seems like most "guides" on ssh, even ones written after ed25519 was added, still advocate rsa keys.
- baby 8y agoWould you say the "you don't need to migrate to Argon2" culture is actually a bad thing?
- lvh 8y agoI think I’m missing context. You don’t need to migrate from what? If you have reasonable scrypt or bcrypt I’m not gonna tell you to move.
- TheAceOfHearts 8y agoDo you have a guide for home users you could point to that provides clear guidelines for managing your SSH keys? I have a few home servers, but if one of my devices were compromised I don't think it would take much longer for the whole network to fall. I'd love an end-to-end example that shows how you're storing everything, in both meatspace and your devices. Do you use hardware authentication devices? How do you handle backups?
- lvh 8y agoIf you can put up with GPG cards, gpg-agent knows how to pretend to be an SSH auth socket meaning it can do your signing for you. At key generation time you can dump the key (once!) and then feed it to paperkey as a backup.
- chx 8y ago> consider that long-lived SSH credentials are an anti-pattern With due respect: have you considered the myriad systems where you need to upload your SSH key to an UI? If my key is short term then I need to do that all the time. I can't set up an SSH CA on github for example.
- alxlaz 8y agoThe fact that GitHub does it, too, doesn't make it any less of an anti-pattern.
- kalalala024 8y agohttp://www.prfree.org/news-watch-ufc-227-live-fight-569216.html http://www.prfree.org/news-watch-ufc-227-live-fight-569216.h... https://www.youtube.com/watch?v=MoNMIkUpXBw https://www.youtube.com/watch?v=MoNMIkUpXBw
- laumars 8y agoGitHub has APIs for automation (eg via Terraform). Granted not ever web-based service does, but if you were sufficiently determined to use SSH CA then I'm sure you'd find a way (or an alternative service that did support your workflow).
- lvh 8y agoYes, we mentioned GitHub repeaatedly in these threads.
- joelthelion 8y ago> consider that long-lived SSH credentials are an anti-pattern. I don't think that's necessarily true, provided that your keys are: - Properly encrypted - Protected by a decent password - You use ssh agent to avoid 1) copying the key everywhere, and 2) typing your password all the time. Of course it depends how critical security is. Access to a few dev servers inside the company firewall is not the same as managing your client-facing production infrastructure.
- otterley 8y agoOut of curiosity, how can you have individual user logins on a host while delegating authn/authz to a CA? All the examples I've seen thus far involve a shared login, whereas I find it's a lot easier to audit hosts when a unique user ID is in the logs, last/w/who output, etc.
- gdamjan1 8y agobless allows to specify the remote user in the certificate. you'll need to customize the certificate issuing program (a small python lambda program)
- otterley 8y agoI think I need some more information. What I'd like to do is to have a signed certificate that only lets me into the "otterley" account on the remote host, while not letting "jsmith" into my account (only hers) or vice versa. My understanding of CA principals is that they identify the user or role that requested the signing, but not necessarily the login ID on the server that is allowed to be logged into. Ideally there'd be a 1:1 mapping between the principal and the login ID on the server. I think there's some sshd configuration that needs to be done, but I haven't seen any clear instructions for doing so. Do you know how to accomplish this?
- e12e 8y agoHave a look at eg: https://linux-audit.com/granting-temporary-access-to-servers-using-signed-ssh-keys/ https://linux-audit.com/granting-temporary-access-to-servers... And re-read the (imnho rather obtuse) ssh-keygen man pages. [ed: and maybe this too: https://framkant.org/2017/07/scalable-access-control-using-openssh-certificates/ https://framkant.org/2017/07/scalable-access-control-using-o... ]
- otterley 8y agoThanks! So it looks like AuthorizedPrincipalsFile/AuthorizedPrincipalsCommand gives us a method for doing this. This would have to be combined with some sort of user ID management system still, like distribution of /etc/{passwd,group} files, LDAP/AD, etc.
- zaarn 8y agoI put my SSH keys inside KeepassXC (regular Keepass supports this via plugin). Way better encryption and it automatically manages the adding of keys to the ssh-agent. All my other SSH keys I don't have in there are plaintext on the disk. The ssh askpass is in userspace and easily spoofed, any local attacker could easily fish it out anyway. Full disk encryption at rest ought to be enough for most people.
- lvh 8y agoI wrote this; happy to answer questions.
- pvg 8y agoBeside compatibility, is there any reason not to use Ed25519 keys for everything?
- tptacek 8y agoNo, you should use Ed25519 keys wherever you can.
- lvh 8y agoNope! Ed25519 is great and honestly I think the compatibility concerns are overblown. It was introduced in 2014. If you are running four year old SSH you have other problems, like probably RHEL or some nonsense. That said: Ed25519 is a local optimum: the bigger win is to not have long-held credentials at all, and instead use an SSH CA or something like Gravitational Teleport. Doesn't work for GitHub though.
- jakobdabo 8y agoRHEL 7 (and derivatives) do support Ed25519 keys.
- glenjamin 8y agoIn a world where you don’t have long held credentials - how do you get the short term credentials?
- guelo 8y agoYou could have a key rotation process where you use the old key to install the new key and delete the old key. But it seems sketchy because if you don't rotate in time the old key expires and you're locked out. I think in practice you'll always end up with a super-duper secret, rarely used, long term key. Or have some other backdoor like root password, LDAP/Kerberos, ADFS, etc.
- jwildeboer 8y agoNice deflection of the real madness here that a compromised npm package gets to read stuff in your user directory.
- tptacek 8y agoYes, that's what this was. An elaborate attempt to shield npm from scrutiny. We know where our bread is buttered.
- annabellish 8y agoI mean, of course it does. Most people run their development environments as their own user, and most package management systems have post-install script support. Installing random software from the internet is problematic.
- vemv 8y agoI'd be interested in running my dev environment with a dedicated user account -with no access to the main account's personal files, credentials, etc-, do you know of any guides for doing so? (I could just give it a shot, but I reckon there will be gotchas)
- andreareina 8y agoWhat I do is use a VM as my development environment, managed by Vagrant. Any dependencies stay on the VM image.
- angry_octet 8y agoWhat platform? GUI or shell? Docker/LXD or a dev VM lets you access both simultaneously. Or create a separate user, but not as secure or convenient.
- vemv 8y agomacOS. Not much interested in VMs, for efficiency. Yeah I was playing with a separate user account, could get some basics working but I wonder how far could I get with that. What are the bigger security risks for that approach? Assuming constrained file permissions, and that no secrets are in ENV (https://gist.github.com/telent/9742059 https://gist.github.com/telent/9742059 )
- amenghra 8y agoMy ssh key is stored in a yubikey. Haven’t had to type a password for ssh purpose in a long time!
- anilakar 8y agoA TPM chip is also easy to use with libsimple-tpm-pk11. Not a perfect solution but at least the private key cannot be stolen and misused without direct access to the computer.
- knorker 8y agoIf you have really old clients you may apparently be able to do this instead: https://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html https://martin.kleppmann.com/2013/05/24/improving-security-o...
- jakobdabo 8y agoA 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 fi
- btgeekboy 8y agoThis is a neat idea. Though in my case an accidental grep through my homedir would be incredibly annoying.
- pas 8y agoRun untrusted stuff in a VM/container.
- gcb0 8y agomac "containers" run in virtual box with exposed paths, which is vulnerable to symlinks attacks and others
- petee 8y agoHow does that solve an accidental grep that touches a file being monitored? Grep and your key are both trusted, and there are numerous ways someone can try to read the key despite only running specific things in a vm (and forgetting that VMs aren't bulletproof)
- chrisper 8y agoAnd how can you tell if that was the source of your power off?
- jakobdabo 8y agoBy examining the timestamp on the log file (defined by the --outfile parameter).
- mrrandomguy11 8y agoUse 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.
- lvh 8y agoDon't do this. Get an SSH CA and temporary credentials, and make your authentication to that SSH CA actually good (e.g. SAML with mandatory U2F).
- Boulth 8y agoWhat's the difference between SAML+U2F vs smartcard stored SSH key? Both cannot be easily stolen or abused. Additionally Yubikey have touch-to-use policy that further protects the key usage.
- tcmb 8y agoI'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.
- lvh 8y agoThe new format has been around for a pretty long while (2013). I think it makes sense to upgrade to -o. While it's obvious to developers (I hope!) it's not obvious to most end users I think :)
- claytonjy 8y agonot only does it seem like this is a better default, this option is awfully well-hidden on my system; doesn't show up in the short help or the example usage in the man page; gotta scroll down to find it in the exhaustive list of flags
- Avamander 8y agoThe utility also does not warn about insecure defaults.
- jniedrauer 8y agoIt's worth noting that some large cloud providers (for example, AWS) still do not support ed25519 keys.
- exegete 8y agoI believe you can change to the new format (still not ed25519 though). After generating your keypair in the AWS console, do "ssh-keygen -p -o -f aws.pem" and add a strong passphrase generated from a password manager.
- simias 8y ago>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).
- tialaramex 8y agoSome people move private keys. You shouldn't, but people do. And so they expect that an encrypted private key file from their brand new Mac will work when pasted into a five year old CentOS install.
- simias 8y agoSeems like simply issuing a warning on key creation "this key uses a newer, safer encryption scheme but as a result might not be directly portable to older versions of openssh, if that's an issue use <someflag> to use the older, weaker scheme instead" would probably solve the problem in 99% of the cases. After a few years you might remove the warning and move on. For this type of applications security should trump backward compatibility, especially when in this case the breakage is fairly limited and easy to work around.
- AceJohnny2 8y agoHow 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 yes
- ansible 8y agoYou can use the keychain to store keys, but if the key is ever saved in the old (broken) format, you've got a problem.
- supernovae 8y agoMac keychain shits the bed on my randomly... never know why, but it happens and i hear people at work grumbling about it too so i don't put much faith into it.
- codesections 8y agoThis 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?
- CBLT 8y agoHere's my anecdata: I didn't know much about ssh keys when creating, so I followed directions online. The directions I followed created my key with no password. Soon my Mac encrypted the ssh key by itself, without my intervention (!), to use my Mac logon password. The encryption format was the old ssh format the article complains about, even though my openssh supported the new one. The password I use to sign into my computer is not grabbed from a password manager.
- angry_octet 8y agoWhat? Are you saying macos changed the key to be encrypted SSH format? That doesn't sound right. In fact, implausible.
- nebulous1 8y agotl;dr to move to the newer more secure format use ssh-keygen -o -p -f file_name such as: ssh-keygen -o -p -f ~/.ssh/id_rsa not necessary for ed25519 as it can only be stored in the new format.
- nebulous1 8y agoThis 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.
- lvh 8y agoIf you select from a 10k word list, you get 13.3 bits of entropy per word. 4 of those get you 53 bits of entropy. One p3.16xlarge does 450GH/s. So, as a first order approximation: 253 / (450E9) = 2E4 or about 6 hours. Sure: you don’t get to keep that performance, but we’re talking a day. What kind of passwords do you have that make it “much better”? Or are you saying that already counts?
- nebulous1 8y agoIf you're asking what I'm using myself, I use 5 random words from the COED (240,000 words). If you want to stick to a 10,000 word list you can just up the word count. Every word you add makes it 10,000 times stronger.
- lvh 8y agoGood for you -- but I hope you'll agree that even 4*rand(10k) is a pretty gracious assumption for password quality. The argument is not "under literally all circumstances is it worse", but just rather, "it's worse". For that argument to hold, it just has to be plausible worse at least on average. All empirical data we have on password quality points in that direction.
- nebulous1 8y ago> but I hope you'll agree that even 4*rand(10k) is a pretty gracious assumption for password quality I do. However, for it to be "worse" than plaintext you still need to be using it somewhere else, and (previously unmentioned) for the attacker to have a feasible way of attacking the other use. For instance if it's your desktop password, an attacker may have no way of leveraging that (not that I'm saying this overlap is a good thing security-wise). Whereas if they have your unencrypted ssh key then they 100% have your ssh key, no work required, no AWS instance, no cost. I don't want to get too bogged down in this. I was using the old format, and I've now changed, so thank you!
- dionna767675 8y agoGet 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 https://internetmarketingsolution.club
- jwr 8y agoI'd suggest following the excellent guide at https://github.com/drduh/YubiKey-Guide https://github.com/drduh/YubiKey-Guide and using one of your GPG subkeys (kept on a hardware device like a YubiKey) for SSH authentication.
- bogomipz 8y agoThe 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?
- lvh 8y agoYou use SSO with strong authentication to sign a temporary credential for SSH.
- bogomipz 8y agoThanks, might you know which SSO implementations support this?
- lvh 8y agoI like Teleport. It's not an SSO implementation but if you pay Gravitational you get SAML. BLESS, the Netflix solution, relies on you being able to call a Lambda. You can SSO that as well via STS' AssumeRoleWithSAML. (But be careful, AWS SSO should be like the last SSO you implement, generally hardening IAM is super complicated, talk to me for more details. We owe y'all a bunch of dinky "here's how you do IAM" blog posts.) EDIT: I previously incorrectly claimed that you need to pay Gravitational for Teleport SSO. That is incorrect: you only need to pay for _SAML_, specifically -- I forgot that you can GitHub auth into it, which is a form of SSO. (Though for most of our customers I think that single trust store is a core part of SSO, and GitHub isn't a good SSO by that metric, by vritue of account reuse and the fairly tenuous links between users and organizations. GitHub does a great job of modeling open source interactions, but that model falls over a bit when translated to commercial software engineering orgs.)
- old-gregg 8y agoThe open source edition of Teleport has SSO support for logging via Github [1]. The enterprise version adds enterprise SAML implementations like Okta, Auth0 and things like ADFS. [1] https://gravitational.com/blog/replace-static-ssh-keys-with-github-oauth/ https://gravitational.com/blog/replace-static-ssh-keys-with-...
- bogomipz 8y ago>"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?
- lvh 8y agoBackwards compatibility. I don’t think it shelled out, but close enough.
- nerdponx 8y agoSo is that what happened? Somebody got a hold of one of the developers' private SSH keys, and cracked the encryption?
- drb91 8y agoDoes this affect non-RSA key types too? I use ecsda25519.
- progval 8y ago> How do you fix this? OpenSSH has a new key format that you should use. “New” means 2013. This format uses bcrypt_pbkdf, which is essentially bcrypt with fixed difficulty, operated in a PBKDF2 construction. Conveniently, you always get the new format when generating Ed25519 keys, because the old SSH key format doesn’t support newer key types.
- w8rbt 8y agoAll my ssh key passwords are generated from password managers. They are random and strong.
- exabrial 8y agoSeems like gpg auth would be a much better choice the ssh keys
- spiznnx 8y agoIt'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.
- valenciarose 8y agoUse 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.
- quotemstr 8y agoOkay. 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.
- lvh 8y agoThe blog post explicitly addresses this, but you don’t seem to interact with its point. We have evidence that smash and grab attacks exist, and since they affect more people, you’re more likely to get screwed by something like the recent eslint-scope thing than a targeted attack where the attacker does shit to your .profile. That said; yes: you should have long-held auth on a hardware token and then use an SSH CA for temporary auth.
- technion 8y agoIt’s tricky to find out what this DEK-Info stuff means 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.
- gigatexal 8y agoWhat if you generate the public and private keys without a password but keep it blank?
- lwf 8y agoFiled https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905407 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905407 to change the Debian default.
- ejholmes 8y agoIf you have a recent MacBook, use https://github.com/ntrippar/sekey 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.
- Whitestrake 8y agoAhh, if only Apple released a non-touchbar MBP with Touch ID! I'd have used this in a heartbeat.
- digitalnalogika 8y agoWhat are you thoughts on using Krypton? https://krypt.co https://krypt.co
- otterley 8y agoIs 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?
- pferde 8y agoIf such an infiltration is successful enough, nobody (besides the attacker) would be aware of it. :)
- otterley 8y agoIt's the damage we'd notice -- exfiltration of data, malicious destruction, etc. The intrusion is but a step towards the real goal.
- pferde 8y agoThe damage wouldn't necessarily be noticed for what it is. What if such exploit was/is used to get more compromised zombie boxes into botnets for hire (such as the one currently spamming Freenode and other IRC networks for the past week or so) ?
- adultSwim 8y agoI'm finally vindicated for not using a password on my key :P