Live data from Hacker News

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

news.ycombinator.com

81–90 of 114 posts

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

#81
post #26

Earlier quoted context omitted.

Indeed, I have FDE enabled and a passphrase, but I reckon that the passphrase is not buying me much. OTOH, it's defense in depth, and there are some vulnerabilities which could allow to exfiltrate keys without non-sandboxed-RCE https://blog.mozilla.org/security/2015/08/06/firefox-exploit... I reckon that a passphrase protected key would be safe from this attack (modulo offline brute-forcing)

> OTOH, it's defense in depth Yup. IMO not using a passphrase is nuts, considering there is practically no convenience loss (ssh-agent, OS X keychain, pageant) and fairly significant benefit. Protects against: - accidentally exposing the private key (it happens, accidental wildcard in the shell), and - attacks that aren't after your keys specifically, e.g. your home directory gets stolen.

In general I agree with you, with the caveat that there are a number of products that don't give a toss about security (lookin' at you, Hashicorp) that actually and unironically require you to have your keys unencrypted on disk.

I have since discarded these products (and others should too), but they do exist.

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

#82

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?

ED25519 keys are cryptographically more secure, and are more politically secure if you want to call it that due to the undermining of NIST the NSA was/is doing. (plus it comes from djb, all hail djb!) OpenSSH already has support built in, as does Mosh, and therefore, I do think it's worth it. I do sometimes disagree with using keys though, despite everyone pushing it so hard, there are cases where I think passwords a…

> I do sometimes disagree with using keys though

That sounds interesting, could you elaborate on that?

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

#83
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?

RSA requires two numbers which are big and random and prime. It is the primality that makes things tricky. Generating random primes is a lot harder than generating random numbers.

The other factor (no pun intended) that makes RSA keys large is that there are more efficient algorithms for factoring than there are for solving the elliptic curve discrete log problem, e.g. https://en.wikipedia.org/wiki/General_number_field_sieve If you crunch the numbers on this you will find that a 2000-bit RSA key has a security level of about 100 bits, i.e. it takes about 2^100 operations to factor a 2000-bit RSA key using GNFS.

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

#84
post #78

Earlier quoted context omitted.

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)…

Not bigger -- denser.

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

#85
From a pragmatic end-user perspective.

1) Disable passwords and only allow keys even for root with PermitRootLogin without-password

2) public-key authentication has somewhat unexpected side effect of preventing MITM per this security consulting firm http://www.gremwell.com/ssh-mitm-public-key-authentication

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

#86
post #10

I consider best practice to be using a hardware token. My favoured solution is to use a yubikey via gpg: with this method you use your gpg subkey as an ssh key. The yubikey 4 supports RSA 4096 bit keys, if you need NFC then the Yubikey Neo supports max RSA 2048 bit keys.

This. It's so cheap and easy to use a hardware token for your GPG and SSH keys nowadays (YubiKey 4! TPM! Smartcards!). If you're not using one, you should.

I have tried this for Windows and could not find the right magic to bring my yubico and ssh keys together (keepass otp stinks). What am I missing?

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

#87
post #37
post #23

Earlier quoted context omitted.

Use a GPG Card - much simpler than acquiring blank Java cards.

And what is hard exactly about acquiring blank Java cards? Not harder than ordering anything else over the Internet.

Well, finding a reliable seller in Europe seems to be hard.

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

#88
post #84
post #78

Earlier quoted context omitted.

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)…

Not bigger -- denser.

Great replies, I got it now, it makes sense. Thanks to both of you!

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

#89

Earlier quoted context omitted.

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 'ss…

keyegn + cp don't do everything. Unless the distribution and session killing is automated, you can't easily revoke access. Of course you could implement this fairly easily with {chef/puppet/salt/ansible/...} and ldap, but it requires time / bandwidth. This is what userify seems to give you.

I'm not saying it's a good solution though. I agree that it's giving someone full access to your whole environment and it's a bad idea.

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

#90

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.

Userify is available as on-premise too. (btw I strongly agree with you... we're offering 5 server enterprise license model and we're looking at an unlimited stripped-down free version.)

Also, you're probably running servers at a third party hypervisor already.. ;) they could be scanning your RAM and reading your disk and you'd never know.

Post reply on HN