4 ms·

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 transpare

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.

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.