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

91–100 of 159 posts

Re: Upgrade your SSH keys

#91

Post by roblabla »

mSparks wrote: post #71
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…

Well. OP says ->Generate your new sexy Ed25519 key I too, say, No f'ing thanks https://en.wikipedia.org/wiki/Curve25519 In cryptography, Curve25519 is an elliptic curve offering 128 bits of security - The curve is birationally equivalent to Ed25519, a Twisted Edwards curve. Ecrypt II - the EU project into encryption security says: https://www.keylength.com/en/3/ That gives you Very short-term protection against small…

If it really was equivalent to 816bit rsa, messages encrypted with it would be cracked within hours, and nobody would use ecc... I'd like to see proof that a 256bit Curve25519 is really that weak.

Re: Upgrade your SSH keys

#92

Post by pfg »

mSparks wrote: post #80
rockdoe wrote: post #76

Earlier quoted context omitted.

You are misunderstanding. Curve25519 offers 128 bits of symmetric security, or the equivalent of a 256 bit elliptic curve key.

even if that is true. its still not enough to protect anything of value.

That's not what your own source says about 128-bit symmetric keys:

> Long-term protection

> Generic application-independent recommendation, protection from 2016 to 2040

Re: Upgrade your SSH keys

#94

Post by glandium »

sillysaurus3 wrote: post #88
Godel_unicode wrote: post #87

Earlier quoted context omitted.

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. Admitted…

If you're trying to maintain anonymity, why is your username your real name?

Re: Upgrade your SSH keys

#95

Post by pbowyer »

tw04 wrote: post #43

This is my standard on new server setup (which is admittedly overkill but I'd rather have it slightly slower and safer): http://www.catb.org/esr/sshexport/ https://stribika.github.io/2015/01/04/secure-secure-shell.ht... SERVER SIDE: sources.list (if you're on an older version of debian) deb http://http.debian.net/debian wheezy-backports main apt-get -t wheezy-backports install --reinstall ssh ==== cd /etc/ssh rm ssh_…

For people like me who create a new server and put our public SSH keys in ~/.ssh/authorized_keys, can you explain what doing this does, and why it's good?

I can see you're limiting it to particular algorithms/cyphers, but the rest?

Re: Upgrade your SSH keys

#96

Post by Nullabillity »

Godel_unicode wrote: post #83
fphilipe wrote: post #63

Earlier quoted context omitted.

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.

Adding to this: GitHub publishes the public SSH keys of all of their users, for example: https://github.com/teozkr.keys

Re: Upgrade your SSH keys

#97

Post by sillysaurus3 »

glandium wrote: post #94
sillysaurus3 wrote: post #88

Earlier quoted context omitted.

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. Admitted…

If you're trying to maintain anonymity, why is your username your real name?

Even if it's not, your default hostname when using a MacBook Pro is typically "s-MacBook-Pro.local" which reveals you're using a MacBook Pro. That info leak probably doesn't matter, but generally you want to reveal as little information as possible.

Re: Upgrade your SSH keys

#98

Post by hk__2 »

_swa8 wrote: post #82
hk__2 wrote: post #78

Earlier quoted context omitted.

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.

I agree, but for something as simple as that I’d prefer a script to use `ssh-keygen` instead of relying on the presence of a one-line script in the PATH.

Re: Upgrade your SSH keys

#99

Post by makomk »

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…

Not all systems that you might want to use your keys on support Ed25519, and this was especially true when it was first introduced to OpenSSH. Similarly not everything can handle the new key format. (Interestingly, there's another way to increase the resistance of SSH private keys to password brute-forcing that uses PBKDF2 and is more widely supported, but there's no way to create keys that use it using OpenSSH itself.)

Re: Upgrade your SSH keys

#100

Post by nitrogen »

sillysaurus3 wrote: post #97
glandium wrote: post #94

Earlier quoted context omitted.

If you're trying to maintain anonymity, why is your username your real name?

Even if it's not, your default hostname when using a MacBook Pro is typically " s-MacBook-Pro.local" which reveals you're using a MacBook Pro. That info leak probably doesn't matter, but generally you want to reveal as little information as possible.

As one example, a hostname leak might hypothetically be useful for a spearfishing+XSS attack.
Post reply on HN