Hacker News Reader

Comment by gitfan86 | Hacker News Reader

SSH keys are just long passwords.

An SSH password is sent to the server, the server will get the exact password. An SSH private key is not sent to the server.

Exactly, so even if the server is compromised you're not giving it the means to authenticate as you. I think this is a huge plus.

Maybe, but it conceptually it doesn't have to be like that. Often, the password is not sent directly, but its hash is sent (sometimes hashed multiple times), so that the same property is true.

If you send a hash, the hash itself effectively becomes the password. If the server is compromised or the hash is intercepted, the attacker has everything they need to authenticate as you.

With private/public key pairs, the same scenario would result in the attacker only obtaining your public key, which is useless without the private key.

You are correct and I was sloppy in explaining it properly.

In general however, I believe that there is no inherit advantage of certificates over passwords, except for the key-size obviously. Everything else is just convention/standards.

Please see the following page that explains better what I meant when I said that the password should be hashed: https://en.wikipedia.org/wiki/Hash_chain

Using such a mechanism (including salts / challenges) will prevent an attacker using the hash as the password.

> SSH keys are just long passwords.

They're really not, they are private/public key pairs.

Now, sure, if you have a public key, and a guess at a private key - you can check if said guessed private key can derive the public key - but unless you know something no one else does - there's no practical way to enumerate and guess the key space.

But a password may be arbitrarily short and eg a random password of 8 mixed-case letters, numbers and some symbol is "just" log2((26*2+10+10)^8) ~ 50 bits (rounded up). Now that's probably not feasible to brute force on-line (without anyone noticing) - but quite feasible off line (if you're patient - but you don't have to be immortal).

That is why I said "long password". Once it takes over 1000 years to brute force a password, you should have much bigger problems to worry about. On average someone will click on a link in a spam e-mail, or fall for another phishing attack much more frequently than once a 1000 years.

If you "click on a link" you won't type in your secret key (barring insecure ssh-agent set up) - but you might type in your password - for example sending it to a proxying ssh daemon despite a warning about changed host keys.

You "might" upload your private key as well.

He’s not talking about ssh keys, but ssh certs. As provided off the shelf by bless (Netflix), vault, step-ca, etc. they remove the burden of managing keys. For example you can give a single command a short-lived ssh cert that is only valid as long as the command takes to run and then expires.

For clarity, yes I did say certs. But even good old SSH keys are a million miles better than passwords.

I guess I should have said "Public Key Authentication" since that would be more reflective of a desirable baseline SSHD configuration.

SSH certificates can sign a key with an expiration, thats a bit different to a password.

Reply on news.ycombinator.com