6 ms·

Disable root authentication over ssh should be the default too. This is literally ssh 101.

• jstimpfle 9y ago
  what's wrong with public key auth as root? The "alternative" would be making a sudo-enabled login account. Another indirection, and probably not fully transparent...
  • drdaeman 9y ago
    In my personal opinion, there's nothing wrong with that, as long as key is not compromised, of course. However, it's somewhat less secure than sudo-enabled account with password requirement. If your SSH key is somehow compromised (unpassworded keyfile or attacker had gained access to ssh-agent's socket, or you've ran a network-listening daemon from your account that had an exploitable RCE) you're a little bit more safe if attackers won't get root access. This only works well for noexec $HOME, of course, as attacker can't mess with your .*shrc and trick you into entering the password.
  • Spooky23 9y ago
    Use of shared accounts eliminates individual accountability if humans are using them. Unless you have an system with its own auth and audit capability connecting as root, shared accountability is bad. People do dumb shit, including illegal shit.
  • isostatic 9y ago
    If you have more than one person logging in, it's far easier to identify who did something as root by looking at the username that logged in. Also far better to encourage running sudo for every command, gives a nice simple audit log of what happened, right there in your syslog, so you can identify and undo mistakes, and also eliminate lines of enquiry. Clearly you can cover your tracks with the old sudo vi / !bash and similar tricks, but the goal isn't to protect against hostile privileges users, its to know what happened so that when John is on holiday you can see what he did to fix the problem you had last week.
    • cuckcuckspruce 9y ago
      If your sudoers policy allows you to run vi then you've already failed. sudoedit(8) has been around for a long time and it solves this problem.
      • isostatic 9y ago
        Failed at what? I want my sysadmins to have full access, I just want to know what they did. I'm not trying to defend against malicious staff members - I trust them, otherwise they wouldn't have sudo access.
        • cuckcuckspruce 9y ago
          If you can trust your administrators then you don't need to worry about shell escapes in editors. The idea for sudoedit is that it allows you to allow non-root users to safely edit files, and if they shell out of their editor then they've not gained root rights - they edit a temporary file as a regular user and then sudo moves the file into place after it is edited.
  • xstartup 9y ago
    If you run any command it will run with the root privilege when you are root. It happened to me many times, where I ran a command and it asked for root then I investigated why the particular command needs root and figured that this is not what I want in the first place. So, account with sudo capabilities is better than then one which is sudo by default.
• merb 9y ago
  it's not more secure/less secure if you enable root over pubkey only. I mean if I can login with a user that has sudo rights (probably with no password, the default on most cloud providers) there is no real benefit in having a user called ubuntu or centos that can login and gain full sudo rights than using root directly.
  • pecg 9y ago
    If the password used for the user, in the remote machine, is different from that of the machine he/she is connecting from, the attacker will not be able to gain root access, even if the account has permission to escalate priviledges.
    • inetknght 9y ago
      I don't see how the authentication used for a user on a local machine has anything to do with the authentication of a user on a remote machine unless both are using the same domain authentication (RADIUS, Active Directory, etc). Even then, there can be cache involved.
      • closeparen 9y ago
        There could be a local compromise that exposes the SSH keys (for login) but not the remote password (for sudo).
        • inetknght 9y ago
          My parent comment indicates that the password needs to be different. Your comment does not support that. First, sudo should not be cached for this very reason. Second, agent caching should never be enabled for this very reason. Third, agent forwarding should never be enabled for this very reason. Indeed, using key authentication to log in and then using a password to upgrade to sudo is, I think, very reasonable.
          • merb 9y ago
• fiddlerwoaroof 9y ago
  I don’t really see the benefit of disabling root logon vs. allowing user login + sudo to root, if you only allow login via keypairs. This seems to me to be one of those cases where there might be some theoretical benefits, but those benefits don’t matter in practice. Edit: I see several other people posted this while I was typing :)
  • emsy 9y ago
    I configured it so I can only sudo with my password. So even if someone gets hold of my private key, they'd have to guess my password for sudo access. Also, as someone pointed out you can restrict sudo commands, which is the sensible thing to do.
    • icebraining 9y ago
      they'd have to guess my password for sudo access. SSH to your account, add an alias to sudo in .bashrc (or equivalent for your shell) that records the password in a hidden file before passing it to the real sudo.
      • zrth 9y ago
        Is there a practical way to prevent this kind of attack? Also, what the name for this class of exploitation so I can read more?
        • daimrod 9y ago
          Use the absolute path to any */sbin utilities :-)
          • jwilk 9y ago
            Doesn't help much. Once the attacker took over the account, nothing you do or see can be assumed to be real. For example, the attacker could inject a LD_PRELOAD library that redirects execve() calls from /usr/bin/sudo to a fake version of sudo.