Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Upgrade your SSH keys

blog.g3rt.nl

Post reply on HN
Print view View original

61–70 of 159 posts

Re: Upgrade your SSH keys

#61

Post by ultramancool »

mkj wrote: post #58
loeg wrote: post #10

RSA 2048 is still the openssh default, i.e., best current advice from the openssh authors. The fact that this article's author labels that as "yellow" is a red flag.

A ssh private key does not need to protect future secrets, it just signs an ephemeral challenge. So it doesn't really make sense to worry about future quantum crypto etc. I'd posit that even 1024 is probably still safe enough there (unless you have quite scary enemies targeting you in particular) That is a concern for the DH key establishment though, that might be decrypted in future.

> That is a concern for the DH key establishment though, that might be decrypted in future.

If you're paranoid, configure your SSH server to only accept Curve25519-based key exchanges, only use AES with authenticated modes or CTR+ETM or chacha/poly1305, and only take ed25519 or long RSA authentication keys.

Assuming your clients are up to date it should work without any major impact. I also strongly recommend rejecting NIST "random" curves in your hostkey verification, better RSA or ed25519 than the current default of the somewhat questionable ECDSA-based keys.

Re: Upgrade your SSH keys

#62

Post by sillysaurus3 »

mastazi wrote: post #26
fjarlq wrote: post #22

Earlier quoted context omitted.

It could have to do with the NSA's August 2015 plan for transitioning to quantum-resistant algorithms. In their new Commercial National Security Algorithm (CNSA) Suite, they advise a minimum 3072-bit RSA modulus: https://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.... (Doh... I don't know why I'm getting an invalid certificate authority error when trying to access that site, but Qualys SSL Labs confirms it's…

Also: with quantum computing still in its infancy, how do we actually know which types of keys would be adequate?

Not a direct answer to your question, but http://pqcrypto.org has a lot of great information on post-quantum crypto.

Re: Upgrade your SSH keys

#63

Post by fphilipe »

brandmeyer wrote: post #44

If you have servers too old to work with the latest keys, you can easily modify your ~/.ssh/config to automatically use a per-machine private key file: Host foo.example.com Keyfile ~/.ssh/my_obsolete_private_keyfile

That you should be doing anyways, shouldn't you?

Re: Upgrade your SSH keys

#65

Post by sillysaurus3 »

developer2 wrote: post #60

Seriously, the default options to ssh-keygen should be all anybody needs. If you need to pass arguments to increase the security of the generated key, then the software has completely failed its purpose. Passing arguments should only be for falling back on less secure options, if there is some limiting factor for a particular deployment. There is absolutely no reason to pass arguments to ssh-keygen. If it is actually…

By default, ssh-keygen leaks info about your computer (``user@host''). Passing -C "" takes care of this.

I just throw a script in my ~/bin folder called `keygen`:

  exec ssh-keygen -t rsa -b 4096 -C "" "$@"

Re: Upgrade your SSH keys

#66

Post by loeg »

Achshar wrote: post #41

Noob question here, why move just one step ahead. Why not 8192 or hell 16,384? I can see it can lead to higher CPU consumption on often used keys but for keys that are not accessed more than a couple of times a day, why is it such a bad idea to overdo it?

4096+ is noticeably slower.

Re: Upgrade your SSH keys

#67

Post by mkj »

ultramancool wrote: post #61
mkj wrote: post #58

Earlier quoted context omitted.

A ssh private key does not need to protect future secrets, it just signs an ephemeral challenge. So it doesn't really make sense to worry about future quantum crypto etc. I'd posit that even 1024 is probably still safe enough there (unless you have quite scary enemies targeting you in particular) That is a concern for the DH key establishment though, that might be decrypted in future.

> That is a concern for the DH key establishment though, that might be decrypted in future. If you're paranoid, configure your SSH server to only accept Curve25519-based key exchanges, only use AES with authenticated modes or CTR+ETM or chacha/poly1305, and only take ed25519 or long RSA authentication keys. Assuming your clients are up to date it should work without any major impact. I also strongly recommend rejecti…

Won't the quantum computer break the curve25519 key exchange?

Re: Upgrade your SSH keys

#68

Post by riffraff »

mastazi wrote: post #23
loeg wrote: post #10

RSA 2048 is still the openssh default, i.e., best current advice from the openssh authors. The fact that this article's author labels that as "yellow" is a red flag.

I agree. It would be nice if the line: > RSA 2048: yellow recommended to change was followed by at least some link that explains why is it unsafe. Could anyone elaborate further? UPDATE: there is now a link up in this thread, from the user fjarlq, which points to an NSA recommendation from 2015. The recommendation seems to be related to the need of having a "quantum computing resistant" key. But with quantum computin…

I think we don't know which one will be adequate but we do know that RSA won't be, hence the recommendation.

Re: Upgrade your SSH keys

#69

Post by Spydar007 »

developer2 wrote: post #60

Seriously, the default options to ssh-keygen should be all anybody needs. If you need to pass arguments to increase the security of the generated key, then the software has completely failed its purpose. Passing arguments should only be for falling back on less secure options, if there is some limiting factor for a particular deployment. There is absolutely no reason to pass arguments to ssh-keygen. If it is actually…

> Passing arguments should only be for falling back on less secure options

This is the case with the secure-delete package for srm and sfill. Each argument changes the writes to make them less secure.

Re: Upgrade your SSH keys

#70

Post by mook »

brandmeyer wrote: post #44

If you have servers too old to work with the latest keys, you can easily modify your ~/.ssh/config to automatically use a per-machine private key file: Host foo.example.com Keyfile ~/.ssh/my_obsolete_private_keyfile

Additionally, you can have substitutions in there:

  Host *
    IdentityFile ~/.ssh/%r@%h
This is indeed better, as a compromise means only the private keys on the affected host are affected. That of course works better with a keypair per source/destination combination.

Note that this _does_ cause issues sometimes, as it means your ssh-agent (you _are_ using one of those, right?) will have more keys than a typical auth attempt limit, and software that assumes trying all your keys before prompting for input is a sane thing to do will fail.

Post reply on HN