5 ms·

SSH keys are just long passwords.

andrewchambers 5y ago
SSH certificates can sign a key with an expiration, thats a bit different to a password.
matja 5y ago
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.
- GekkePrutser 5y ago
  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.
- valenterry 5y ago
  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.
  - hnaccount141 5y ago
    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.
    - valenterry 5y ago
      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 https://en.wikipedia.org/wiki/Hash_chain Using such a mechanism (including salts / challenges) will prevent an attacker using the hash as the password.
sjtindell 5y ago
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.
- traceroute66 5y ago
  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.
e12e 5y ago
> 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).
- gitfan86 5y ago
  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.
  - e12e 5y ago
    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.
    - gitfan86 5y ago
      You "might" upload your private key as well.

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

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.

GekkePrutser 5y ago
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.
valenterry 5y ago
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.
- hnaccount141 5y ago
  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.
  - valenterry 5y ago
    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 https://en.wikipedia.org/wiki/Hash_chain Using such a mechanism (including salts / challenges) will prevent an attacker using the hash as the password.

sjtindell 5y ago

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.

traceroute66 5y ago
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.

e12e 5y ago

> 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).

gitfan86 5y ago
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.
- e12e 5y ago
  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.
  - gitfan86 5y ago
    You "might" upload your private key as well.