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

141–150 of 159 posts

Re: Upgrade your SSH keys

#141

Post by tw04 »

johnhenry wrote: post #51
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_…

Do you have a link to a gist and/or your other work?

To be clear, the links at the top aren't mine (sorry if it seemed that way). Just sources I've used to create what I've got.

Re: Upgrade your SSH keys

#142

Post by tw04 »

pbowyer wrote: post #95
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?

The stuff towards the top eliminates the insecure keys your server will try to default to. No reason to keep them on the server (IMO) - they're primarily there for backwards compatibility. I prefer to remove them entirely so I know my client/server won't ever negotiate an insecure connection.

Re: Upgrade your SSH keys

#143

Post by tw04 »

sandGorgon wrote: post #55
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_…

why do you need to do client-side ? The server side will enforce the algorithms that are allowed.

That's because I don't always control the servers I'm connecting to. Setting that client-side will prevent me from ever connecting to something that's completely insecure unknowingly.

Re: Upgrade your SSH keys

#144

Post by FullyFunctional »

morecoffee wrote: post #53

Ed25519 is fast, but I don't think the speed is significantly faster to be an argument for using it. Running the borgingssl speed tool on a skylake mobile processor: Did 1083 RSA 2048 signing operations in 1017532us (1064.3 ops/sec) Did 29000 RSA 2048 verify operations in 1016092us (28540.7 ops/sec) Did 1440 RSA 2048 (3 prime, e=3) signing operations in 1016334us (1416.9 ops/sec) Did 50000 RSA 2048 (3 prime, e=3) ver…

Not everyone is using Skylakes. My gateway is a Raspberry Pi (for historical and power reasons) and my most often used client is ARM based.

Re: Upgrade your SSH keys

#145

Post by FullyFunctional »

perlgeek wrote: post #106

So I once read somewhere that RSA is simpler to implement than most other algorithms, and hence it's a safer choice than other algorithms, because weaknesses typically come from suboptimal implementation less than from the cryptographic algorithm. (Unless you use known-broken things like md5 or 3DES). And I think that was in the context of some DSA or ECDSA weakness, possibly a side channel attack or something simila…

Actually, if you ready DJB's fine papers he very much touches on this. Curve 25519 (now X25519) is specifically designed to avoid the pitfalls. The reference implementation is not too hard to understand, but granted the optimized versions are a little more delicate. Still, I imagine the optimized RSA implementations are no better.

Re: Upgrade your SSH keys

#146

Post by mSparks »

pfg wrote: post #92
mSparks wrote: post #80

Earlier quoted context omitted.

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

total nonsense.

25519 is an asymetric key using eliptic curves

Re: Upgrade your SSH keys

#147

Post by pfg »

mSparks wrote: post #146
pfg wrote: post #92

Earlier quoted context omitted.

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

total nonsense. 25519 is an asymetric key using eliptic curves

As both rockdoe and hannob have mentioned, ed25519 provides the same attack resistance as a 128-bit symmetric cipher. This is even mentioned in the original DJB ed25519 paper:

> High security level. This system has a 2^128 security target; breaking it has similar difficulty to breaking NIST P-256, RSA with ≈ 3000-bit keys, strong 128-bit block ciphers, etc. (The same techniques would also produce speed improvements at other security levels.) The best attacks known actually cost more than 2^140 bit operations on average, and degrade quadratically in success probability as the number of bit operations drops.

Re: Upgrade your SSH keys

#148

Post by JshWright »

dasil003 wrote: post #37
paulddraper wrote: post #20

Earlier quoted context omitted.

"battle tested" and "resistant to quantum computing" are complete opposites

Orthogonal?

Well, at the moment, they are "opposite" as well.

No battle tested crypto schemes are post-quantum safe, and no post-quantum crypto schemes are battle tested.

Re: Upgrade your SSH keys

#149

Post by andai »

makomk wrote: post #99
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 itsel…

Are you referring to something like this? http://blog.patshead.com/2013/09/generating-new-more-secure-...

Re: Upgrade your SSH keys

#150

Post by mSparks »

pfg wrote: post #147
mSparks wrote: post #146

Earlier quoted context omitted.

total nonsense. 25519 is an asymetric key using eliptic curves

As both rockdoe and hannob have mentioned, ed25519 provides the same attack resistance as a 128-bit symmetric cipher. This is even mentioned in the original DJB ed25519 paper: > High security level. This system has a 2^128 security target; breaking it has similar difficulty to breaking NIST P-256, RSA with ≈ 3000-bit keys, strong 128-bit block ciphers, etc. (The same techniques would also produce speed improvements a…

->similar difficulty to breaking NIST P-256

which takes our comp sci lab 35 seconds on a cluster of 8 machines.

so still no.

Post reply on HN