Live data from Hacker News

Ask HN: What are the best practises for using SSH keys?

news.ycombinator.com

71–80 of 114 posts

Re: Ask HN: What are the best practises for using SSH keys?

#71
post #54

Earlier quoted context omitted.

In your experience what difference does full disk encryption vs home encryption have in this context? We've been debating this a lot at work.

FDE leaves very few if any opportunities for accidentally spilling cleartext secrets onto the disk. If by home encryption, I assume you mean some encrypted container (or encrypted document). Consider what you "DO" with the decrypted contents.. often you are copying them out to perform some action (authentication, etc).. Are you certain the apps you use and your clipboard won't be paged to disk temporarily? If secrets…

The default encryption on Ubuntu, if you select 'Encrypt my home folder' during setup, uses ecryptfs on your home folder, and cryptswap for swap. For some reason, /tmp/ isn't encrypted by default as far as I can tell.

AFAIK the main benefit is: if you want to run a multi-user or headless system, you need the network stack brought up before a password is entered - which home directory encryption provides and FDE can't.

Re: Ask HN: What are the best practises for using SSH keys?

#72
post #54

Earlier quoted context omitted.

In your experience what difference does full disk encryption vs home encryption have in this context? We've been debating this a lot at work.

FDE leaves very few if any opportunities for accidentally spilling cleartext secrets onto the disk. If by home encryption, I assume you mean some encrypted container (or encrypted document). Consider what you "DO" with the decrypted contents.. often you are copying them out to perform some action (authentication, etc).. Are you certain the apps you use and your clipboard won't be paged to disk temporarily? If secrets…

I think in this case, "home" encryption is what I use. Most Linux systems when you install will offer to encrypt your home folder. When you login, your password unlocks a key which ecryptfs uses to virtually mount a directory filled with encrypted files to be your home directory. As long as you are logged in, the home directory contents are available (transparently). When you logout, the virtual mount is destroyed, leaving behind only the encrypted files.

To put it in perspective, if you were logged out completely and tried to login remotely, you would be forced to use a password login initially. If it was more like my desktop where I'm logged in and the screen in locked, the home folder is unlocked, so I can remotely ssh in using just my keys.

Re: Ask HN: What are the best practises for using SSH keys?

#73

This is probably the wrong forum, but I have a question or two that I see as related. I have setup a VPS, disabled passwords, and setup a key with a passphrase to gain access. At this point my greatest worry is losing this private key, as that means I can't access the server. What is a reasonable way to backup my private key? Encode it as something similar to a QR-code, print it, and store it in a hole in the wall? C…

It might be a good idea to think about a system that can update/rotate your keys across all of your servers on the fly in case one is compromised or assumed to be compromised. (disclosure: I work @ userify)

In addition, it might be a good idea to think about a system that can update/rotate your keys across all of your servers on the fly in case the third-party service you're using to manage the keys to the kingdom is compromised or assumed to be compromised.

Re: Ask HN: What are the best practises for using SSH keys?

#74
post #27
post #20

Earlier quoted context omitted.

Good advise. This happenned to me. By luck I had another account I could use to recover. I wish I could disable that feature. I use config now but the default should not be to try every key in ssh directory.

Agreed. That seems like a weakness in OpenSSH. One should have to turn on a "try all keys" option to get that behaviour ..

Yeah, it's on by default. See IdentitiesOnly to turn it off.

Re: Ask HN: What are the best practises for using SSH keys?

#76
post #40

Earlier quoted context omitted.

Nobody seemed to answer this question, and neither did the original blog post (besides "trust me and do it"), so maybe you can shed more light on the main point: Why are ED25519 keys better than RSA, how compatible are they with different systems, and are they worth the hassle and risk of generating and using a new one?

> Why are ED25519 keys better than RSA Two reasons: 1) they are a lot shorter for the same level of security and 2) any random number can be an Ed25519 key. To generate an RSA you have to generate two large random primes, and the code that does this is complicated an so can more easily be (and in the past has been) compromised to generate weak keys.

If I understood it correctly, you're saying that RSA requires the two numbers to be big AND random, otherwise the algorithm isn't strong? Therefore Ed25519 is better because it's strong regardless of the key?

What I don't get then is how can a short key be secure, that goes against what I was taught in college. Aren't shorter keys more prone to collisions and bruteforce attacks?

Re: Ask HN: What are the best practises for using SSH keys?

#77
post #70

Earlier quoted context omitted.

I disagree -- you really do need to; I tend to need to use ssh -A on my clients (jump boxes, etc) -- and the agent I will only have their key in it -- if one of the other staff with root on the bounce box, or an attacker, grabs my auth sock, then the keys only let them further into that one client, instead of pwning all my others... Or say, someone pwning a dev jenkins box doesn't get an agent connection which lets t…

Any other reasons for separate keys, if I don't use ssh -A?

Not really. Think of each key as, well, a key.. If you used the same key in every lock in your house, that might be ok... Sometimes, though, you need to be more careful -- the only motivation for using more than one is to limit the damage someone getting a copy of that key does, right?

Re: Ask HN: What are the best practises for using SSH keys?

#78
post #40

Earlier quoted context omitted.

> Why are ED25519 keys better than RSA Two reasons: 1) they are a lot shorter for the same level of security and 2) any random number can be an Ed25519 key. To generate an RSA you have to generate two large random primes, and the code that does this is complicated an so can more easily be (and in the past has been) compromised to generate weak keys.

If I understood it correctly, you're saying that RSA requires the two numbers to be big AND random, otherwise the algorithm isn't strong? Therefore Ed25519 is better because it's strong regardless of the key? What I don't get then is how can a short key be secure, that goes against what I was taught in college. Aren't shorter keys more prone to collisions and bruteforce attacks?

Aren't shorter keys more prone to collisions and bruteforce attacks?

Given the same cipher, more or less, yes. Between ciphers, though, key-lengths are less relevant, and the differences in those ciphers become more so.

EDIT: Think of it in terms of Shannon Entropy: because RSA requires a pair of primes, the keyspace is so much sparser — that is to say, more "predictable" (if, granted, at a mostly theoretical level) — so keys need to be that much larger to be secure.

Contrarily, with ED25519, keys can be smaller, because the keyspace is denser.

(Or am I just talking out my ass here?)

EDIT 2: s/smaller/sparser/, s/bigger/denser/, regarding keyspaces. Thanks, 'lisper!

Re: Ask HN: What are the best practises for using SSH keys?

#79

Earlier quoted context omitted.

It might be a good idea to think about a system that can update/rotate your keys across all of your servers on the fly in case one is compromised or assumed to be compromised. (disclosure: I work @ userify)

In addition, it might be a good idea to think about a system that can update/rotate your keys across all of your servers on the fly in case the third-party service you're using to manage the keys to the kingdom is compromised or assumed to be compromised.

Sorry to hijack this, but this is absurd.

I really must have missed the story here -- people pay for a third party service to manage their private keys?

... Err. That's so illogical it's making my brain hurt to even work out why I would need to explain how illogical it is...

I can't even come up with a good analogy for how wrong that whole idea is, fortunately I don't have to though since no one that has mastered 'ssh-keygen' and 'cp' would actually do so.....

2FA, okay; the service provider only has half the story. ssh-keys-as-a-service? WAT.

Edit:

Okay, I looked a bit more at userify and it seems to be an agent that runs on your systems which generates authorized_keys files....

From their docs:

"There are two parts of the Userify installation: creating the agent (readable only by root) in /opt/userify, and setting the agent to start at bootup. Setting the agent to start at bootup is a bit trickier, but the installation process attempts to detect the server type and set it up properly."

Am I reading this wrong? You hook up an agent, which runs as root, which farms out authorized_keys entries across the estate? One possible mech for deploying the agent is conf management?

What the actual fuck? Why would anyone do this? Do I even need to explain why this is blowing my mind so much?

Re: Ask HN: What are the best practises for using SSH keys?

#80
post #16

From my experince as an attacker -- - Is it better to use a different passphrase on each key, or does using the same one not matter much? - How much less secure is it to not use a passphrase on a key? - Should you use a different key per user account, per server, or per use-case (i.e. personal or work)? None of these things really matter that much. Make sure you use full disk encryption and never stand up from your m…

Nobody seemed to answer this question, and neither did the original blog post (besides "trust me and do it"), so maybe you can shed more light on the main point: Why are ED25519 keys better than RSA, how compatible are they with different systems, and are they worth the hassle and risk of generating and using a new one?

Note that ED25519 is more vulnerable to quantum computation than is RSA.
Post reply on HN