4 ms·

If you disable passwords, then you need to use password-less sudo. That's usually not a great idea. Users still need passwords, they just need to be secure. Fo

If you disable passwords, then you need to use password-less sudo. That's usually not a great idea. Users still need passwords, they just need to be secure. For SSH, yes, keys should always be used and the guide covers disabling password and root SSH logins. Here's section 4.5: > Remote access is always through SSH on Linux servers. In most cases, SSH is setup to allow access to user accounts via passwords. By allowing users to log in to your server using their passwords, you allow hackers to brute force attack your server from anywhere in the world. Instead, your servers should use RSA keys to allow users to login. This will only allow users to access the server from the computer that contains their private key. Since private keys will be password locked and never shared, this will ensure that only authorized users will be able to access the server.

mooreds 10y ago
How do you keep users from selecting easy passwords (or no password) for their private keys?
- brokenwren 10y ago
  The libpam-cracklib does it for you. It's a PAM module that is invoked whenever the user changes their password. You can configure it to enforce various password constraints and rules. Check out section 4.4 for a detailed overview of Cracklib.
  - jvoorhis 10y ago
    You're answering the wrong question. They're asking about passphrase for SSH key not OS user accounts. Adding a passphrase to your SSH private key is a best practice but not easily enforced without some manual process or command and control for sysadmin workstations. Hardware tokens containing private keys and used via PKCS#11 are another option for providing some assurance. The token itself can require a PIN.
    - brokenwren 10y ago
      You are correct. I missed read that question. If you select an easy passphrase for your key, it's similar to selecting a weak password for your bank account when your bank doesn't enforce password constraints. Buyer beware. An ideal solution would be a two-factor key encryption. That would require the two-factor key to unlock the private key. There might be something out there like that. I haven't looked though.
      - jvoorhis 10y ago
        Physical cryptographic tokens meet this requirement: something you have-possession of the token itself-and something you know-the PIN to operate it.
yoo1I 10y ago
> If you disable passwords, then you need to use password-less sudo. unfortunately that's true. But it shouldn't have to be. There is a libpam-ssh-agent-auth which makes use of a forwarded ssh-agent socket to authenticate to whenever sudo needs it, which means that you have to re-authenticate your ssh-key locally. It works, but it never really took of, and tbh I wouldn't trust it's security. But the authentication flow is something I would want. [0] https://sourceforge.net/projects/pamsshagentauth/ https://sourceforge.net/projects/pamsshagentauth/
- jvoorhis 10y ago
  Search for "ssh agent forwarding attack" or similar.
  - yoo1I 10y ago
    I am glad you specified "or similar" http://imgur.com/768xaL3 http://imgur.com/768xaL3 But you're correct, an attacker on the remote system with access to the socket (i.e. usually root) can steal your identity.
jbronn 10y ago
It's also possible to craft a fine-grained sudo policy instead of allowing carte blanche access.

mooreds 10y ago

How do you keep users from selecting easy passwords (or no password) for their private keys?

brokenwren 10y ago
The libpam-cracklib does it for you. It's a PAM module that is invoked whenever the user changes their password. You can configure it to enforce various password constraints and rules. Check out section 4.4 for a detailed overview of Cracklib.
- jvoorhis 10y ago
  You're answering the wrong question. They're asking about passphrase for SSH key not OS user accounts. Adding a passphrase to your SSH private key is a best practice but not easily enforced without some manual process or command and control for sysadmin workstations. Hardware tokens containing private keys and used via PKCS#11 are another option for providing some assurance. The token itself can require a PIN.
  - brokenwren 10y ago
    You are correct. I missed read that question. If you select an easy passphrase for your key, it's similar to selecting a weak password for your bank account when your bank doesn't enforce password constraints. Buyer beware. An ideal solution would be a two-factor key encryption. That would require the two-factor key to unlock the private key. There might be something out there like that. I haven't looked though.
    - jvoorhis 10y ago
      Physical cryptographic tokens meet this requirement: something you have-possession of the token itself-and something you know-the PIN to operate it.

yoo1I 10y ago

> If you disable passwords, then you need to use password-less sudo. unfortunately that's true. But it shouldn't have to be. There is a libpam-ssh-agent-auth which makes use of a forwarded ssh-agent socket to authenticate to whenever sudo needs it, which means that you have to re-authenticate your ssh-key locally. It works, but it never really took of, and tbh I wouldn't trust it's security. But the authentication flow is something I would want. [0] https://sourceforge.net/projects/pamsshagentauth/ https://sourceforge.net/projects/pamsshagentauth/

jvoorhis 10y ago
Search for "ssh agent forwarding attack" or similar.
- yoo1I 10y ago
  I am glad you specified "or similar" http://imgur.com/768xaL3 http://imgur.com/768xaL3 But you're correct, an attacker on the remote system with access to the socket (i.e. usually root) can steal your identity.

jbronn 10y ago

It's also possible to craft a fine-grained sudo policy instead of allowing carte blanche access.