11 ms·

I highly recommend to move off password-based SSH at all in favor of SSH keys or (even better, certificates). Here are some projects to help you roll out new i

by alexk 10y ago

I highly recommend to move off password-based SSH at all in favor of SSH keys or (even better, certificates). Here are some projects to help you roll out new infrastructure without SSH passwords: https://github.com/gravitational/teleport https://github.com/gravitational/teleport ( I work on this one with our team) and https://github.com/Netflix/bless https://github.com/Netflix/bless (heard great things about it, especially if you are using AWS)

userbinator 10y ago
I find this common "wisdom" or "best practice" questionable. Something to think about: If I use a password, a suitably designed client can have absolutely no trace of my credential after it has been used. If I use a key/certificate, that credential must be stored somewhere on the client, and even in encrypted form, it exists in persistent storage.
- deleted 10y ago
  [deleted]
- eli 10y ago
  If someone is able to steal my private key file, then they have probably compromised my computer and could just as well install a keylogger.
  - userbinator 10y ago
    Consider the scenario in which your computer is stolen (and might not ever be returned, so whether the attacker installs a keylogger is irrelevant): The fact that a private key file exists suggests that the user is very likely to be using SSH regularly. The fact that an SSH client exists is far less informational (there's one by default on most Linuxes and Mac OS). If I only ever use password authentication with SSH and don't save anything else, not even server keys, the attacker has far less information. That might be important in some scenarios, especially related to anonymity.
    - DasIch 10y ago
      If your computer is stolen and you don't have full disk encryption, a leaked private key is probably far from the only problem.
    - old-gregg 10y ago
      alexk already addressed your concern: your keys, preferably issued by your org's CA (instead of being generated by you) should be short-lived, oftentimes for the duration of your "work shift". The tools listed above support this.
    - lomnakkus 10y ago
      You are aware it's usually recommended to have passphrases for keys, yes? Plus, you really should have whole-disk encryption for laptops. (I get the feeling I'm missing something here, but...)
      - userbinator 10y ago
        Regardless of whether the keyfile has a passphrase, the point is that it exists. And FDE also suggests you may be hiding something. Sometimes the best way to make something secure, is to make it look like there is actually nothing to secure.
        tzs 10y ago
        > And FDE also suggests you may be hiding something. No one needs to bother trying to infer from FDE that I'm hiding something. I will tell them I am if they ask. Financial records, intimate correspondence, and employer trade secrets (I'm authorized to work at home on my personal computer) immediately come to mind and there is probably more. I'm sure I'm not unusual in this regard. Most people have things they are hiding.
        lomnakkus 10y ago
        If anyone's targeting your specific laptop for theft they already think that you're hiding something. If some rando steals your laptop they probably have no clue what SSH even stands for.
- electronvolt 10y ago
  Which can (and should) be stored in a way that requires a password to access (ssh supports this, as do most other certificate systems).
- deleted 10y ago
  [deleted]
- alexk 10y ago
  That's why short lived certs are better then just private keys - even if the key is stolen, the system can cut off the access by not issuing the renewed certificate. This makes private key itself to be irrelevant, in fact it can be generated as well once a day for example.
- ebbv 10y ago
  This objection is weak. Generate a unique key pair on the client. De-authorize it when you're done or just delete it. If your argument is that your client is untrusted, then typing in your password is a lot more risky than generating a fresh key pair.
- sfifs 10y ago
  Well you can always keep your keys in a removable drive rather than on persistent storage in your client device. If you can't trust your client device, you probably have bigger issues with either method - for instance, can you trust that the client is not logging all keystrokes?
- walrus01 10y ago
  Which is why you generate your private key with a passphrase (which is used exclusively client side in an ssh client) and only store it on HDD, flash or SSD that uses full disk encryption.
- elchief 10y ago
  smart cards cost like $15
  - mercora 10y ago
    i am somewhat scared to use smart cards because they might break at some point and i am loosing access... if i would use some kind of local ca to provision the keys i could just as well use them directly... so i would need some kind of secured (air gaped and what not) device to provision them. which will be unavailable when i am abroad... all in all it seems to me it doesn't solve more problems than it makes...
    - jvoorhis 10y ago
      The CA or smart card software is only needed for provisioning smart cards for clients, and is likely to be of little concern for setting up a new server. The card itself stores a non-phishable credential which you can physically secure.
    - deleted 10y ago
      [deleted]
    - deleted 10y ago
      [deleted]
- naner 10y ago
  Your private key should remain password protected, I don't think anyone here is recommending a passwordless login. Also usually with ssh you are more worried about the remote server being compromised than your local client machine.
- kleim 10y ago
  If someone has remote access to your computer then either way you are screwed. Using password or key file won't change anything. If your laptop get stolen, then just remove the corresponding line in your authorized_keys file.
- vbezhenar 10y ago
  If the key is encrypted, then it doesn't exist as long as the password is good enough to resist a bruteforce. But password requirements in this case are definitely higher. You can restrict login attempts in the remote ssh machine, but you can't restrict bruteforcing of stolen encrypted key.
  - icebraining 10y ago
    You can also use bcrypt and adjust the work factor; assuming use of ssh-agent and/or shared connections, you could add a delay of multiple minutes to each try.
- dfc 10y ago
  I think this "wisdom" or "best practice" is targeted at the overwhelming amount of the population that are concerned with using SSH on a computer they control and are therefore not concerned with leaving footprints behind. Do you frequently use a computer that you don't control?
- galdosdi 10y ago
  You must not be aware that you can set a password (which ssh-keygen calls a passphrase) on your private key file. The private key file will be encrypted and without the password will be useless, if your password is strong. Then you get the best of both. Setting a passphrase on your key file is also actually widely considered a "best practice" and "conventional wisdom" ... so maybe those old guys knew something after all...
  - userbinator 10y ago
    I'm perfectly aware that you can and almost always should encrypt the keyfile; the point I'm trying to make is that you still need a keyfile and the existence of that file can itself be a concern in some situations even it it can't be immediately used by an attacker.
umanwizard 10y ago
Why?
jimmaswell 10y ago
This would mean I'd have to either remember to carry around a flash drive to access my server from the computers at the college library, or keep a copy of my private key on my networking drive there, a network I don't have any reason to believe is perfectly secure.
- eterm 10y ago
  In either case generate different private keys to use there, so you can revoke the ones used from those computers easily without revoking your more tightly controlled keys. Private keys are like passwords, try not to re-use them.
- no_protocol 10y ago
  Protect it with a strong passphrase.
  - zatkin 10y ago
    https://www.xkcd.com/936/ https://www.xkcd.com/936/ I recommend reading this XKCD comic for how to come up with strong passphrases.
    - whatsdoom 10y ago
      https://pypi.python.org/pypi/xkcdpass/1.8.2 https://pypi.python.org/pypi/xkcdpass/1.8.2 Nice implementation of xkcd passwords.
      - eatbitseveryday 10y ago
        Or.. you can use the web with this one! https://xkpasswd.net/ https://xkpasswd.net/
        ibotty 10y ago
        Bright idea! Using someone elses Computer To generate your password!
zatkin 10y ago
Is it better to use certificates or keys? If certificates, how do you set those up? I have SSH keys setup right now.
- alexk 10y ago
  Certificates are better - you don't need to worry about distributing your public keys everywhere. Here's a nice article about setting up a CA for your OpenSSH servers: https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu https://www.digitalocean.com/community/tutorials/how-to-crea... It's better to generate short lived certificates and teleport does exactly that - you can use it with existing OpenSSH infrastructure: http://gravitational.com/teleport/docs/admin-guide/#using-teleport-with-openssh http://gravitational.com/teleport/docs/admin-guide/#using-te...
  - awqrre 10y ago
    keys are better, even though you need to distribute them, nobody else has them...
    - Daviey 10y ago
      Err, letting the world have your public keys is perfectly normal. Both GitHub and Launchpad provide a public registry for these: - https://github.com/USERNAMEE.keys - https://launchpad.net/~USERNAME/+sshkeys For example, mine are: - https://github.com/Daviey.keys - https://launchpad.net/~davewalker/+sshkeys Feel free to add them to your servers. :)
      - awqrre 10y ago
        If you use someone else's CA, wouldn't they have your private keys?
        ckwalsh 10y ago
        No, The CA only signs the public key, the private key never leaves your machine.
stephengillie 10y ago
As a cloud support engineer, if you break your networking, I don't want to type a 256-character SSH key into the console to recover your server. Please use certificate-based VPNs and use internal addresses to keep connections within your own networks.
- deleted 10y ago
  [deleted]
- beachstartup 10y ago
  there is absolutely no reason you would need to type an ssh key by hand. even at the very lowest level of server recovery (bare metal bios or uefi), crash carts are obsolete. you can cut and paste everywhere now through ethernetworked or emulated serial means.
  - vidarh 10y ago
    It'll take at least another decade to get rid of all equipment without IPMI or alternatives. No, I'm not kidding.
    - beachstartup 10y ago
      you're not getting what i'm saying. it doesn't matter how old the gear you're working on is. if you're typing in long strings by hand, you're not thinking hard enough about how to do your job.
      - vidarh 10y ago
        Or you have to deal with real world constraints, which can - and do - involve having equipment where e.g. attaching external KVMs etc. is not always an option that is made available to you (cost constraints; space constraints).
  - stephengillie 10y ago
    Please tell me how to paste into a VMWare VM console. To my knowledge, this is not possible.
voltagex_ 10y ago
What about for a home network with a laptop, desktops and many VMs? I'd like to have a better setup than manually scp'ing files around, but these systems seem like overkill. Is there a middle ground?
- kruczek 10y ago
  Why'd keys be an overkill? It's just two files which need to be put at proper places.
mSparks 10y ago
wow. im not sure i believe this... there is no need to send the password to the server to authenticate a password in this day and age. i thought ssh was one of the first protocols to not do this.
- X-Istence 10y ago
  What system are you thinking of? Which works with existing crypt(3) based system used on Unix?
  - amluto 10y ago
    If you are willing to tell anyone who connects your salt, you could, in principle, run a balanced PAKE using the crypt output. You could go one step further and have the server store an augmented PAKE authenticator derived from the crypt(3) output.
  - karlmdavis 10y ago
    Here's half an answer: Kerberos. Which SSH does support, btw.
- vbezhenar 10y ago
  The problem is, ssh daemon doesn't know anything about user password. It uses existing libraries to supply login and password in clear form (like Linux PAM) and they check if it's valid. How this check is done, is abstracted too: it could be /etc/shadow file lookup, it could be LDAP request or really anything. On the other side, it could be possible to create sshd implementation which will use its own user database. But it's probably not convenient.
  - justincormack 10y ago
    The ssh auth protocol is extensible, the client and server negotiate which methods they support, so it is possible to implement new methods.
  - mSparks 10y ago
    ->ssh daemon doesn't know anything about user password And neither should it. auth system creates a one time usable "ticket" which is a one way function of the user password and a nonce. The server gives the nonce to the user, who creates his own ticket based on the nonce and his password, gives his ticket to the server, which then checks if the two tickets match, if they do -> authenticated. -> at no point is the actual user password transmitted. Kerberos extends this further (allows authentication across multiple servers with a single login) But as far as I know the ticketing system is standard ssh protocol. Looking at the spec however: https://tools.ietf.org/html/rfc4252#page-10 https://tools.ietf.org/html/rfc4252#page-10 It appears I am not correct. might be SSHv2

by alexk 10y ago

userbinator 10y ago

I find this common "wisdom" or "best practice" questionable. Something to think about: If I use a password, a suitably designed client can have absolutely no trace of my credential after it has been used. If I use a key/certificate, that credential must be stored somewhere on the client, and even in encrypted form, it exists in persistent storage.

deleted 10y ago
[deleted]
eli 10y ago
If someone is able to steal my private key file, then they have probably compromised my computer and could just as well install a keylogger.
- userbinator 10y ago
  Consider the scenario in which your computer is stolen (and might not ever be returned, so whether the attacker installs a keylogger is irrelevant): The fact that a private key file exists suggests that the user is very likely to be using SSH regularly. The fact that an SSH client exists is far less informational (there's one by default on most Linuxes and Mac OS). If I only ever use password authentication with SSH and don't save anything else, not even server keys, the attacker has far less information. That might be important in some scenarios, especially related to anonymity.
  - DasIch 10y ago
    If your computer is stolen and you don't have full disk encryption, a leaked private key is probably far from the only problem.
  - old-gregg 10y ago
    alexk already addressed your concern: your keys, preferably issued by your org's CA (instead of being generated by you) should be short-lived, oftentimes for the duration of your "work shift". The tools listed above support this.
  - lomnakkus 10y ago
    You are aware it's usually recommended to have passphrases for keys, yes? Plus, you really should have whole-disk encryption for laptops. (I get the feeling I'm missing something here, but...)
    - userbinator 10y ago
      Regardless of whether the keyfile has a passphrase, the point is that it exists. And FDE also suggests you may be hiding something. Sometimes the best way to make something secure, is to make it look like there is actually nothing to secure.
      - tzs 10y ago
        > And FDE also suggests you may be hiding something. No one needs to bother trying to infer from FDE that I'm hiding something. I will tell them I am if they ask. Financial records, intimate correspondence, and employer trade secrets (I'm authorized to work at home on my personal computer) immediately come to mind and there is probably more. I'm sure I'm not unusual in this regard. Most people have things they are hiding.
      - lomnakkus 10y ago
        If anyone's targeting your specific laptop for theft they already think that you're hiding something. If some rando steals your laptop they probably have no clue what SSH even stands for.
electronvolt 10y ago
Which can (and should) be stored in a way that requires a password to access (ssh supports this, as do most other certificate systems).
deleted 10y ago
[deleted]
alexk 10y ago
That's why short lived certs are better then just private keys - even if the key is stolen, the system can cut off the access by not issuing the renewed certificate. This makes private key itself to be irrelevant, in fact it can be generated as well once a day for example.
ebbv 10y ago
This objection is weak. Generate a unique key pair on the client. De-authorize it when you're done or just delete it. If your argument is that your client is untrusted, then typing in your password is a lot more risky than generating a fresh key pair.
sfifs 10y ago
Well you can always keep your keys in a removable drive rather than on persistent storage in your client device. If you can't trust your client device, you probably have bigger issues with either method - for instance, can you trust that the client is not logging all keystrokes?
walrus01 10y ago
Which is why you generate your private key with a passphrase (which is used exclusively client side in an ssh client) and only store it on HDD, flash or SSD that uses full disk encryption.
elchief 10y ago
smart cards cost like $15
- mercora 10y ago
  i am somewhat scared to use smart cards because they might break at some point and i am loosing access... if i would use some kind of local ca to provision the keys i could just as well use them directly... so i would need some kind of secured (air gaped and what not) device to provision them. which will be unavailable when i am abroad... all in all it seems to me it doesn't solve more problems than it makes...
  - jvoorhis 10y ago
    The CA or smart card software is only needed for provisioning smart cards for clients, and is likely to be of little concern for setting up a new server. The card itself stores a non-phishable credential which you can physically secure.
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
naner 10y ago
Your private key should remain password protected, I don't think anyone here is recommending a passwordless login. Also usually with ssh you are more worried about the remote server being compromised than your local client machine.
kleim 10y ago
If someone has remote access to your computer then either way you are screwed. Using password or key file won't change anything. If your laptop get stolen, then just remove the corresponding line in your authorized_keys file.
vbezhenar 10y ago
If the key is encrypted, then it doesn't exist as long as the password is good enough to resist a bruteforce. But password requirements in this case are definitely higher. You can restrict login attempts in the remote ssh machine, but you can't restrict bruteforcing of stolen encrypted key.
- icebraining 10y ago
  You can also use bcrypt and adjust the work factor; assuming use of ssh-agent and/or shared connections, you could add a delay of multiple minutes to each try.
dfc 10y ago
I think this "wisdom" or "best practice" is targeted at the overwhelming amount of the population that are concerned with using SSH on a computer they control and are therefore not concerned with leaving footprints behind. Do you frequently use a computer that you don't control?
galdosdi 10y ago
You must not be aware that you can set a password (which ssh-keygen calls a passphrase) on your private key file. The private key file will be encrypted and without the password will be useless, if your password is strong. Then you get the best of both. Setting a passphrase on your key file is also actually widely considered a "best practice" and "conventional wisdom" ... so maybe those old guys knew something after all...
- userbinator 10y ago
  I'm perfectly aware that you can and almost always should encrypt the keyfile; the point I'm trying to make is that you still need a keyfile and the existence of that file can itself be a concern in some situations even it it can't be immediately used by an attacker.

umanwizard 10y ago

Why?

jimmaswell 10y ago

This would mean I'd have to either remember to carry around a flash drive to access my server from the computers at the college library, or keep a copy of my private key on my networking drive there, a network I don't have any reason to believe is perfectly secure.

eterm 10y ago
In either case generate different private keys to use there, so you can revoke the ones used from those computers easily without revoking your more tightly controlled keys. Private keys are like passwords, try not to re-use them.
no_protocol 10y ago
Protect it with a strong passphrase.
- zatkin 10y ago
  https://www.xkcd.com/936/ https://www.xkcd.com/936/ I recommend reading this XKCD comic for how to come up with strong passphrases.
  - whatsdoom 10y ago
    https://pypi.python.org/pypi/xkcdpass/1.8.2 https://pypi.python.org/pypi/xkcdpass/1.8.2 Nice implementation of xkcd passwords.
    - eatbitseveryday 10y ago
      Or.. you can use the web with this one! https://xkpasswd.net/ https://xkpasswd.net/
      - ibotty 10y ago
        Bright idea! Using someone elses Computer To generate your password!

zatkin 10y ago

Is it better to use certificates or keys? If certificates, how do you set those up? I have SSH keys setup right now.

alexk 10y ago
Certificates are better - you don't need to worry about distributing your public keys everywhere. Here's a nice article about setting up a CA for your OpenSSH servers: https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu https://www.digitalocean.com/community/tutorials/how-to-crea... It's better to generate short lived certificates and teleport does exactly that - you can use it with existing OpenSSH infrastructure: http://gravitational.com/teleport/docs/admin-guide/#using-teleport-with-openssh http://gravitational.com/teleport/docs/admin-guide/#using-te...
- awqrre 10y ago
  keys are better, even though you need to distribute them, nobody else has them...
  - Daviey 10y ago
    Err, letting the world have your public keys is perfectly normal. Both GitHub and Launchpad provide a public registry for these: - https://github.com/USERNAMEE.keys - https://launchpad.net/~USERNAME/+sshkeys For example, mine are: - https://github.com/Daviey.keys - https://launchpad.net/~davewalker/+sshkeys Feel free to add them to your servers. :)
    - awqrre 10y ago
      If you use someone else's CA, wouldn't they have your private keys?
      - ckwalsh 10y ago
        No, The CA only signs the public key, the private key never leaves your machine.

stephengillie 10y ago

As a cloud support engineer, if you break your networking, I don't want to type a 256-character SSH key into the console to recover your server. Please use certificate-based VPNs and use internal addresses to keep connections within your own networks.

deleted 10y ago
[deleted]
beachstartup 10y ago
there is absolutely no reason you would need to type an ssh key by hand. even at the very lowest level of server recovery (bare metal bios or uefi), crash carts are obsolete. you can cut and paste everywhere now through ethernetworked or emulated serial means.
- vidarh 10y ago
  It'll take at least another decade to get rid of all equipment without IPMI or alternatives. No, I'm not kidding.
  - beachstartup 10y ago
    you're not getting what i'm saying. it doesn't matter how old the gear you're working on is. if you're typing in long strings by hand, you're not thinking hard enough about how to do your job.
    - vidarh 10y ago
      Or you have to deal with real world constraints, which can - and do - involve having equipment where e.g. attaching external KVMs etc. is not always an option that is made available to you (cost constraints; space constraints).
- stephengillie 10y ago
  Please tell me how to paste into a VMWare VM console. To my knowledge, this is not possible.

voltagex_ 10y ago

What about for a home network with a laptop, desktops and many VMs? I'd like to have a better setup than manually scp'ing files around, but these systems seem like overkill. Is there a middle ground?

kruczek 10y ago
Why'd keys be an overkill? It's just two files which need to be put at proper places.

mSparks 10y ago

wow. im not sure i believe this... there is no need to send the password to the server to authenticate a password in this day and age. i thought ssh was one of the first protocols to not do this.

X-Istence 10y ago
What system are you thinking of? Which works with existing crypt(3) based system used on Unix?
- amluto 10y ago
  If you are willing to tell anyone who connects your salt, you could, in principle, run a balanced PAKE using the crypt output. You could go one step further and have the server store an augmented PAKE authenticator derived from the crypt(3) output.
- karlmdavis 10y ago
  Here's half an answer: Kerberos. Which SSH does support, btw.
vbezhenar 10y ago
The problem is, ssh daemon doesn't know anything about user password. It uses existing libraries to supply login and password in clear form (like Linux PAM) and they check if it's valid. How this check is done, is abstracted too: it could be /etc/shadow file lookup, it could be LDAP request or really anything. On the other side, it could be possible to create sshd implementation which will use its own user database. But it's probably not convenient.
- justincormack 10y ago
  The ssh auth protocol is extensible, the client and server negotiate which methods they support, so it is possible to implement new methods.
- mSparks 10y ago
  ->ssh daemon doesn't know anything about user password And neither should it. auth system creates a one time usable "ticket" which is a one way function of the user password and a nonce. The server gives the nonce to the user, who creates his own ticket based on the nonce and his password, gives his ticket to the server, which then checks if the two tickets match, if they do -> authenticated. -> at no point is the actual user password transmitted. Kerberos extends this further (allows authentication across multiple servers with a single login) But as far as I know the ticketing system is standard ssh protocol. Looking at the spec however: https://tools.ietf.org/html/rfc4252#page-10 https://tools.ietf.org/html/rfc4252#page-10 It appears I am not correct. might be SSHv2