4 ms·

Can somebody please explain to me why exactly using good passwords and allowing root login is bad security? Every SSH security tutorial mentions those but they

Can somebody please explain to me why exactly using good passwords and allowing root login is bad security? Every SSH security tutorial mentions those but they never mention the reasons. If somebody hacked into my password manager and managed to steal the root user's password then they could do the same with my private key. Where is the difference? Also, if somebody hacked into a non-root administrative account, they can just use sudo to elevate. What makes disabling root login more secure?

Borealid 8y ago
1. A "good" key safe for the forseeable future would have around 256 effective security bits. To get a key that strong, your password would have to be (speaking VERY generously here) 40 characters long and truly random. 2. When using real password authentication, connecting to a compromised server results in a disclosure of your password. When using challenge-response authentication, it does not. Note that correctly-configured OpenSSH uses challenge-response even for password-based methods. Incorrectly configured SSH will send passwords over the wire.
- jwilk 8y ago
  > Incorrectly configured SSH will send passwords over the wire. What do you mean?
  - pests 8y ago
    Real password based vs challenge response. With real password when you type your password into the ssh password prompt it then sends that password to the server. Challenge response is a method in which you usually encrypt or hash random server provided data. You send the hash. The server knows your password and can hash the data with it too. The hashes are compared not the password. In this method the password never leaves your machine. Replay attacks are prevented due to the server sending different data for you to hash on different login attempts.
    - e12e 8y ago
      Note also that requiring a password for sudo might have some issues, as the password is sent over the ssh connection as you type. I'm not sure what the state of the art is wrt counting and guessing characters - or if mossh makes the problem worse - or helps. For the general idea, see: http://www.securiteam.com/securitynews/5KP0O0A3PU.html http://www.securiteam.com/securitynews/5KP0O0A3PU.html Does anyone know of recent work on passively attacking interactive ssh in order to guess what's being typed? I could see machine learning helping here, given the ability to observe enough sessions to form a training set...
      - e12e 8y ago
        Of course, with Pam for sudo authentication you could use otp, u2f with or in place of a password.
acdha 8y ago
Mistakes: if it’s a server used by a small number of security conscious admins, it’s moot. If it’s used by a lot of people, however, the odds go up dramatically that someone will have a weak password, one which is on a common list, or reused on a site which you’re just about to learn was breached. Keys can be leaked but since it involves copying files and users aren’t penalized for using strong ones it’s much less common.
e12e 8y ago
Just to add to @borealid's comment: a password that encodes 96+bits of entropy is effectively a shared symmetric key (OK, technically a secret). Point being - it needs to be managed like a key: it's inconvenient to type, hard to remember, should be stored encrypted at rest, preferably in an hsm. Gnupg agent/ssh agent and the various key agents for desktops all do this, and generally support hsm as well. There's also a small difference in the complexity of enumerating the keyspace of rsa/ed2259 vs trying random passwords. With key stretching I'm not sure if there's implicit differences in rate of attempting login. As for no direct root login via ssh - I think it depends a bit on the server. On a shared system login via regular user +sudo leaves an easier audit trail (who ran "sudo apt-get dist-upgrade" on Friday evening and took the weekend off without checking that production systems didn't crash... Was it "root" or "bob "?). Then there's the nudge towards only doing what needs root as root (eg: curl/wget stuff as regular user, verify signatures, content - then run as root). Is it more secure to locally dump and asymmetrically encrypt backups on disk as root - locally, and have a dedicated backup-user that gets the archives? Probably. In general ssh keys (and certs more so) makes it feasible to split up access and authorization, revoke access etc without relying on something complex like ldap/kerberos for user management. > Also, if somebody hacked into a non-root administrative account, they can just use sudo to elevate. If they only have your ssh key, they'd typically need your password to elevate. Or you might require a shared root password - or set a password on wheel and require newgrp wheel before sudo. Not sure if the latter with disabled root account has much benefit, though.
- acdha 8y ago
  One other nice thing about keys is that you can restrict them to a specific command. If you have users who are running well defined tasks that can be a great way to avoid handing out full accounts.

Borealid 8y ago

1. A "good" key safe for the forseeable future would have around 256 effective security bits. To get a key that strong, your password would have to be (speaking VERY generously here) 40 characters long and truly random. 2. When using real password authentication, connecting to a compromised server results in a disclosure of your password. When using challenge-response authentication, it does not. Note that correctly-configured OpenSSH uses challenge-response even for password-based methods. Incorrectly configured SSH will send passwords over the wire.

jwilk 8y ago
> Incorrectly configured SSH will send passwords over the wire. What do you mean?
- pests 8y ago
  Real password based vs challenge response. With real password when you type your password into the ssh password prompt it then sends that password to the server. Challenge response is a method in which you usually encrypt or hash random server provided data. You send the hash. The server knows your password and can hash the data with it too. The hashes are compared not the password. In this method the password never leaves your machine. Replay attacks are prevented due to the server sending different data for you to hash on different login attempts.
  - e12e 8y ago
    Note also that requiring a password for sudo might have some issues, as the password is sent over the ssh connection as you type. I'm not sure what the state of the art is wrt counting and guessing characters - or if mossh makes the problem worse - or helps. For the general idea, see: http://www.securiteam.com/securitynews/5KP0O0A3PU.html http://www.securiteam.com/securitynews/5KP0O0A3PU.html Does anyone know of recent work on passively attacking interactive ssh in order to guess what's being typed? I could see machine learning helping here, given the ability to observe enough sessions to form a training set...
    - e12e 8y ago
      Of course, with Pam for sudo authentication you could use otp, u2f with or in place of a password.

acdha 8y ago

Mistakes: if it’s a server used by a small number of security conscious admins, it’s moot. If it’s used by a lot of people, however, the odds go up dramatically that someone will have a weak password, one which is on a common list, or reused on a site which you’re just about to learn was breached. Keys can be leaked but since it involves copying files and users aren’t penalized for using strong ones it’s much less common.

e12e 8y ago

Just to add to @borealid's comment: a password that encodes 96+bits of entropy is effectively a shared symmetric key (OK, technically a secret). Point being - it needs to be managed like a key: it's inconvenient to type, hard to remember, should be stored encrypted at rest, preferably in an hsm. Gnupg agent/ssh agent and the various key agents for desktops all do this, and generally support hsm as well. There's also a small difference in the complexity of enumerating the keyspace of rsa/ed2259 vs trying random passwords. With key stretching I'm not sure if there's implicit differences in rate of attempting login. As for no direct root login via ssh - I think it depends a bit on the server. On a shared system login via regular user +sudo leaves an easier audit trail (who ran "sudo apt-get dist-upgrade" on Friday evening and took the weekend off without checking that production systems didn't crash... Was it "root" or "bob "?). Then there's the nudge towards only doing what needs root as root (eg: curl/wget stuff as regular user, verify signatures, content - then run as root). Is it more secure to locally dump and asymmetrically encrypt backups on disk as root - locally, and have a dedicated backup-user that gets the archives? Probably. In general ssh keys (and certs more so) makes it feasible to split up access and authorization, revoke access etc without relying on something complex like ldap/kerberos for user management. > Also, if somebody hacked into a non-root administrative account, they can just use sudo to elevate. If they only have your ssh key, they'd typically need your password to elevate. Or you might require a shared root password - or set a password on wheel and require newgrp wheel before sudo. Not sure if the latter with disabled root account has much benefit, though.

acdha 8y ago
One other nice thing about keys is that you can restrict them to a specific command. If you have users who are running well defined tasks that can be a great way to avoid handing out full accounts.