Upgrade your SSH keys • Hacker News Board

Re: Upgrade your SSH keys

#81

Post by andromeduck » Sat, Sep 24, 2016, 7:31 AM UTC

Steltek wrote: post #56

deathanatos wrote: post #49

Earlier quoted context omitted.

For those who have never heard of ControlMasters, I highly recommend them. SSH can multiplex multiple sessions (you invoking ssh at the terminal) over a single TCP socket — this feature is called ControlMaster. The first ssh command takes the normal amount of time, but every command after that is just ~a round-trip. No slow asymmetric key exchange. If you close all your connections, there a (configurable) timeout unt…

> You can combine this fact with zsh's autocomplete powers, I found that recent versions of SSH have begun hashing `~/.ssh/known_hosts` which nerfed zsh autocomplete pretty badly. You need to set "HashKnownHosts no" in `~/.ssh/config`. The SSH change was made to prevent a key compromise from giving an attacker a ready-made list of vulnerable next targets.

But can't they also just find the hosts by looking at your bash history?

Re: Upgrade your SSH keys

#82

Post by _swa8 » Sat, Sep 24, 2016, 7:31 AM UTC

hk__2 wrote: post #78

sillysaurus3 wrote: post #65

Earlier quoted context omitted.

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 "" "$@"

Why not just use an alias? alias keygen="ssh-keygen -t rsa -b 4096 -C ''"

Aliases are per shell process. You need to reload your .bashrc (or whatever file you define aliases in) in every shell. Shell scripts are instantly available in all shell instances. Also, shell scripts can be invoked by shell scripts, which aliases can't.

Re: Upgrade your SSH keys

#83

Post by Godel_unicode » Sat, Sep 24, 2016, 7:37 AM UTC

fphilipe wrote: post #63

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?

You certainly can, it's almost certainly unnecessary though. SSH keys are not like passwords, compromise of a server with your pubkey in no way effects the security of your private key. Many people will post pubkeys online so they're easy to add to new servers.

Re: Upgrade your SSH keys

#84

Post by acqq » Sat, Sep 24, 2016, 7:40 AM UTC

mSparks wrote: post #79

hannob wrote: post #74

Earlier quoted context omitted.

First of all the Ecrypt project is is really outdated. Second you're reading the table wrong. Curve25519 gives you 128 bit of symmetric security, but the curve is 255 bit long. So from your table this compares to 3248 RSA. Third I'm no fan of such key number tables, it's a bit arbitrary and doesn't really reflect the complexities of modern cryptography.

so we should just take yours, and a random blogs word for it over a group of eu cryptologists paid by the eu to keep our data safe from the us and russian state hackers. again. no thanks. you want to join all the american idiots listening to such nonesense disinformation and give all your data to the ruskies. be my guest.

The paper of the designers of ed25519 specifies the design of the curve: the modulo is 2 to the 255th power - 19 (note that it's how the curve got its name), in the table you quote it's equvalent to (roughly) 3000 RSA bits:

https://ed25519.cr.yp.to/ed25519-20110926.pdf

Re: Upgrade your SSH keys

#85

Post by Godel_unicode » Sat, Sep 24, 2016, 7:41 AM UTC

cmrx64 wrote: post #33

LeoPanthera wrote: post #9

Can someone explain to me why RSA 2048 is "recommended to change"? It's still the default for gpg keys and as far as I know is widely thought to be secure for at least few hundred years!

No, not even close to a few hundred years. No more than ~20 years at this point. https://www.keylength.com/en/4/

Read: you are safe using 2048 now.

The arguments for using a longer modulus all reduce down to "you'll have to eventually, why not now?" rather than any new threat against 2048-bit modulus keys.

Re: Upgrade your SSH keys

#86

Post by Godel_unicode » Sat, Sep 24, 2016, 7:45 AM UTC

mkj wrote: post #67

ultramancool wrote: post #61

Earlier quoted context omitted.

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

Yes. This advice is incorrect with regards to quantum computers.

Re: Upgrade your SSH keys

#87

Post by Godel_unicode » Sat, Sep 24, 2016, 7:50 AM UTC

sillysaurus3 wrote: post #65

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 "" "$@"

If you're concerned about hostname leakage in your pubkeys, you're almost certainly doing something wrong.

Re: Upgrade your SSH keys

#88

Post by sillysaurus3 » Sat, Sep 24, 2016, 7:52 AM UTC

Godel_unicode wrote: post #87

sillysaurus3 wrote: post #65

Earlier quoted context omitted.

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 "" "$@"

If you're concerned about hostname leakage in your pubkeys, you're almost certainly doing something wrong.

If you want SSH access to Github or Gitlab, you'll need to paste your pubkey there. Leaking your user@host can be a concern if you're trying to maintain anonymity, e.g. Gwern, particularly if your username is your real name. You can strip out the user@host part from the paste, but it's safer to just get rid of it. It's easy to accidentally paste the whole thing into an .ssh/authorized_keys file, for example.

Admittedly this isn't an issue for most people.

Re: Upgrade your SSH keys

#89

Post by otabdeveloper » Sat, Sep 24, 2016, 7:58 AM UTC

Nobody is going to brute-force my git keys, especially when it's so trivial to gain access to the repos via social engineering.

Re: Upgrade your SSH keys

#90

Post by toyg » Sat, Sep 24, 2016, 8:03 AM UTC

andromeduck wrote: post #81

Steltek wrote: post #56

Earlier quoted context omitted.

> You can combine this fact with zsh's autocomplete powers, I found that recent versions of SSH have begun hashing `~/.ssh/known_hosts` which nerfed zsh autocomplete pretty badly. You need to set "HashKnownHosts no" in `~/.ssh/config`. The SSH change was made to prevent a key compromise from giving an attacker a ready-made list of vulnerable next targets.

But can't they also just find the hosts by looking at your bash history?

Bash history rotates (or can be managed, which a lot of people do), whereas known_hosts will have every server you ever accessed and is rarely ever touched.