21

I came across this old paper, discussing the possibility of password length information being disclosed when usin SSH: Timing Analysis of Keystrokes and Timing Attacks on SSH. The paper has been discussed here before .

This made me wonder: should entering passwords over SSH generally be avoided? If that's the case, wouldn't it be preferable to connect as a privileged user (using a ssh key) than to connect as an unprivileged user and then successively sudo into the root account? Using the former method, no password would be transfered, while with the latter, it might be possible to guess the password. Even if ssh is configured to allow password-less login only, this could be used to read/send mails or access whatever other service is available to the user.

Is this sound reasoning? Did I get a premise wrong somewhere?

Community
  • 1
tarleb
  • 1,200
  • 9
  • 22
  • 1
    Related: http://security.stackexchange.com/q/66894/47143 – kasperd Dec 02 '15 at 10:42
  • I use `ssh-copy-id` to copy my credentials to the other system, and `ssh root@other`, `scp -l root ...` – waltinator Dec 01 '15 at 23:54
  • I have a problem with the way this question is asked: Why would a connection as priviledged user somehow imply "using a ssh key", and why would a connection as unpriviledged user imply "entering passwords"? – DevSolar Dec 02 '15 at 10:54
  • 2
    @DevSolar Passwords entered at login aren't susceptible to the timing attack mentioned above, so it doesn't matter if a ssh-key or password is used during initial authentication. The important part is that `sudo` almost always requests the user's password, which is the password input that I was referring to when talking about "connecting as an unpriviledged user". Please feel free to edit the question if it you think it should be improved. – tarleb Dec 02 '15 at 11:05
  • @tarleb: Ah... forget what I said. I hadn't actually read the abstract of the paper and thought you were concerned about the typing of the password for the `ssh` connection, not the one for `sudo` itself. – DevSolar Dec 02 '15 at 12:09

4 Answers4

18

It is a matter of risk assessment.

On the one hand you have a speculative article where you base ephemeral information on some vague timings.

On the other hand you have the capacity to connect to ssh as a user (ideally using ssh keys), then to do a sudo (possibly without password, it depends on your specific case). You are in a highly standard environment, with best practices in place.
Even if you ssh with a password, then type a password for sudo - you are in the realms of the best practices above.

Email compromission via timing attacks is IMHO not realistic (what you get is, best case, some lengths of "stuff". With luck and specific environments you may correlate this length to passwords).

WoJ
  • 8,968
  • 3
  • 33
  • 51
  • Nice answer, thank you! I guess the part about the whole thing being rather speculative is key here. I brought mails up as an example service with which a recovered password could be used; I didn't mean to imply that timing attacks on SMTP would get you anywhere. – tarleb Dec 01 '15 at 12:35
12

"connect as an unprivileged user and then successively sudo into the root account" is usually the recommended way of using UNIX systems. Many distributions are configured by default to not allow logins with root and expect users to sudo when they need root privileges. But the reason you gave is not among the main ones.

  • On a system with multiple admins, you don't need to share the same root password between multiple persons, because every sudoer can have a different root password.
  • On a system with multiple admins, sudo can log which user performs a command. When all admins use the root account, all log entries will appear as user root and you can't tell who actually did it.
  • Attackers who try to guess the password also need to guess a valid username.
  • It prevents people from using root privileges for tasks which don't require it, because typing sudo in front of every command is additional work.
Philipp
  • 49,017
  • 8
  • 127
  • 158
  • Thanks for the feedback. I may have worded my question poorly: I am less interested in why *sudo*ing is considered a best practice, but was wondering if the mentioned paper should be counted as an argument *against* that practice. – tarleb Dec 01 '15 at 12:29
  • 3
    This setup makes sense when password logins are allowed, but a properly configured server does not allow ssh password login at all, only public key. In that case, having sudo (a suid-root binary) installed, much less using it, is a significant additional risk. – R.. GitHub STOP HELPING ICE Dec 01 '15 at 17:03
  • 1
    @R.: not having an audit log of all the command run with root privilege is also a significant risk. Also, a properly configured server can have fine grained sudoers privilege rather than giving every sysadmins all privileges. – Lie Ryan Dec 02 '15 at 00:23
  • 1
    @LieRyan: There's no reason you can't configure sshd to behave like sudo with forced commands and logging. The privilege model is much more sound and the attack surface is much smaller. – R.. GitHub STOP HELPING ICE Dec 02 '15 at 07:05
4

Another thing to consider if you log in as a normal user and then use sudo is that anyone who breaks your normal user account can modify your environment so that next time you log in and try to use sudo they intercept the request and capture your password and/or run their evil software as root.

Overall while I would discourage password based logins as root I think ssh key logins as root are overall no higher risk than other options for getting root access and are far more conviniant than having to use sudo.

Peter Green
  • 4,968
  • 1
  • 22
  • 26
3

Other reasons to not ssh as root:

  • sudo may log every time it is used so you can keep better track of who did what when
  • accidentally mistyping a command that you don't need privileges for is far less likely to do serious damage
  • you can have a different key password from your user password, meaning an attacker would have to have the key AND 2 different passwords in order to compromise that system
  • better ssh logs so you can know john logged into ssh and then linda instead of the mysterious root.
  • if you are worried about timing attacks possibly being used to sniff out a password, you should be more worried about reusing a password with other servers/services. It would be better to enforce a policy of not reusing passwords since it is far more likely that an attacker found your username and password from another service than it is that an attacker has enough network access to determine how quickly keys are being pressed and actually use that.
  • if you use a password manager and have to copy/paste passwords into your terminal then you can't time how long it takes for your fingers to move from key to key.
Erroneous
  • 191
  • 3
  • 2
    Saying "don't worry about *that one* thing, *that other* thing is way worse" might be technically true, but it doesn't help much when assessing the actual risk of *that one* thing. The point about ssh logs isn't necessarily true, as one can log which key was used to log in as root (just turn up logging verbosity). Thanks for the other input though, +1 – tarleb Dec 01 '15 at 16:29
  • sudo commands are commonly logged, so it's more standard and less work to use sudo for each privileged command. Why go to extra work to log more information about ssh and then need to do extra work for find that information, for no benefit? – jetset Dec 01 '15 at 17:22