I connect via ssh to multiple Linux servers during the day from my Mac's Terminal window.

On my Mac I have the public and private keys in my .ssh directory.

On the Linux servers I always use "sudo su" after logging in to do what I need.

Right now I have my public key in the .ssh directory of my home directory on Linux, in the authorized_keys file. That way I can login without sending a password.

But I notice, since I have su access, that I could create an authorized_keys file in the .ssh directory inside ~root. Then to access I could ssh as root instead of my username.

The advantage is just that I wouldn't have to do sudo su after logging in, thus saving a step.

The disadvantage is that if everybody with su access did this we wouldn't know who was logged in at any time via the users command. It would always just show root.

It seems "too easy" to be able to add my public key to the ~root/.ssh directory though.

What is considered best practice in this case? Is it "better" in general to login with my own account and then do sudo su as needed?

Note I'm not asking whether it is safe to ssh in as root or not, which has been discussed elsewhere. Since I'm doing "sudo su" anyway, I'm always becoming root, and the handful of users with accounts on these machines can all do that, and need to do that to accomplish their tasks.

What I do all the time is (1) login; (2) sudo su; (3) cd to a certain directory; (4) do what needs to be done and exit. I do this dozens of times a day on multiple servers.

So what I'm curious about is for people in my situation is whether there is an advantage to doing it that way rather than going in directly as root and saving a bit of time.



  • 1
    I suppose it would be interesting to modify sshd to log which key matched.
    – Joshua
    Mar 16, 2015 at 19:53

3 Answers 3


Security wise you want people to use sudo not su (Sudo can be setup so it logs all activity, a.k.a. an audit log).

further more on most *nix root access to ssh is prohibited (Setting in the settings file that I would recommend you enable). this is to prevent a breached SSH(-server) can be utilize for ROOT access.

Further security I would recommend is use encrypted keys (e.a. you have a password you need to enter for your key not your login prompt) and use an agent to share your public keys. Otherwise all I would need is your stored key to gain access, removing 1 of the security thresholds.

further more, limit sudo (and su) use for System Administration tasks only (and only for those task you can not do otherwise) use groups for shared access not the root.

I would even go so far as to recommend you use different keys per connection (do not reuse keys especially the id_rsa key) and use the .ssh/config to set what key is used when.

-> Additional Clarification for the "different keys"

The reason you use different keys is so you have layered security, it makes it easier to revoke a key and replace it (and not 'forget' an old server locking you out of that one) and if you do it per client and connection you have the same option on both ends.

Especially if you control more than a few servers this can become a hassle in the long run. for some systems I even have more than 1 key to segregate permissions and authority (having multiple "security zones" on the server with different keys (that have different passwords) so that the one with write access is not the same as the one with shell access.

Another Point I would like to make is that its always better to use the least amount of permissions as possible. So instead of using su to login as root, use su to become a different user (the one with write permission in your folder anyway, such as www-data on ubuntu for the apache httpd folders) than do your thing, and if you really need to use more permissions (change permissions and installing applications are those mostly for me) use "sudo [operation] (options)" instead of just sudo su. not only leave this cleaner audit logs, it also limits possible errors (writing in the wrong location, writing files as root when they should be owned by the webserver, etc.) and it requires you to know what it is you are doing. instead of just going "hey, it worked like this last time".

"Sudo su" is like removing a wall with a pipe bomb. it removes the wall, but a simple sledge hammer could have done the same (with less possible collateral damage).

  • 1
    I would even go so far as to recommend you use different keys per connection Do you mean use a separate key on each client for each server, and if so, why? What benefit does this give? Exposing the public fingerprint in the authorized_keys file does not reveal the private key, and since the private keys are likely to be stored on the same machine (and most users are likely to use the same passphrase), this seems to offer little to no protection to me. Of course, one should probably consider using a separate private key on each client for ease of revocation should the client be compromised. Mar 16, 2015 at 20:18
  • With these servers, there is no purpose of accessing them other than to do sudo tasks. Typically they are accessing to fix a problem in something that is running and then leave. There are only a small handful of people with shell access to the servers, and all of them need to be able to do sudo. It's the only reason their accounts exist. Mar 16, 2015 at 23:20

It's all about managing a risk - as with all such things.

If you routinely do everything as root, I'd suggest that's your problem, rather than the login mechanism. Why? Well, because you're doing everything with a maximum level of privilege.

That suggests you haven't set up your permissions and ACLs appropriately. Ideally no one should ever 'work as root' - and merely privilege escalate occasionally in order to execute commands that require that privilege.

Direct login as root seems rather a moot point - especially if you don't need to re-authenticate in order to sudo su.

Personally I would suggest you don't do either and instead:

  • use sudo for single commands when you need it.
  • work normally as "you".
  • set up permissions that allow "you" to do the things you need to.

And limit how much root activity you're doing at all.

  • In our situation, there is no need to access the Linux server at all other than to perform root activity. It's typically a "quick in, install or fix something, get out" and basically every command (except for things like ls and cd) would require root access for what we are doing. That's why the first thing I always enter is "sudo su". Mar 16, 2015 at 23:28
  • If it's quick access, wouldn't sudo <somecommand> be appropriate? E.g. sudo cpan install newperlmodule etc.? Personally though, I'd suggest - have a 'trusted' server, which (is well secured) and have a privileged account there, with a set of root public-private key pairs. So you still have to escalate, but you do it once on your management server. And then do root-root logins over ssh. (And restrict access from anywhere else as much as possible)
    – Sobrique
    Mar 17, 2015 at 7:39
  • 1
    I am very tempted to print your answer out and physically tape it to one of my co-workers machines. It elaborates this particular concept in a clearer manner than I can Mar 18, 2015 at 7:56

There are only really a few security benefits I can think of offered by logging in as yourself and using sudo vs. logging in as root.

  • Audit trails are available if you are not the only administrator on the machine (if you are the sole administrator, this doesn't really apply at all)
  • You have to enter your password in order to elevate to root with sudo, which provides marginal protection against key compromise (this isn't really a whole lot of security; a clever adversary might simply do something like change your PATH in .bashrc and make their own "sudo" script that saves your password next time you log in). This benefit doesn't apply at all if you have sudo configured for passwordless login.
  • You have more protection if you walk away from an open SSH session without locking your console (if you ever do this, I'm revoking your sysadmin license).

In my opinion, the primary reason most people recommend that you log in with a normal user account and elevate to root for system administration tasks only isn't really to protect you from attackers, it's to protect you from yourself (that accidental extra forward slash in rm -rf is a lot less dangerous running as you than as root). Personally, if I am not expecting to ever perform non-root tasks on a machine, I won't even bother with the normal user account at all - I'll just delete it and use root (only).

If you're paranoid and would like to truly benefit from the extra protection provided by sudo, I would add two SSH keys. Create one for root and install it in /root/.ssh/authorized_keys, and create one for your normal user. Edit /etc/sudoers to only allow your normal account to perform specific tasks that need to be performed as root on a routine basis. For everything else make sure your group membership allows you to perform the tasks you need to perform. The normal user key goes on your computer. The root key goes on a flash drive or smart card / token in a fire safe. The tradeoff is convenience (as it always is), but if you really think you need the added security, that is a way to go about it (not the only way, just what I came up with off the top of my head).

  • I also don't expect to be ever performing non-root tasks on a machine. The only thing which seems advantageous in not logging in directly as root is the "quick look" via the users command to see if another person is there. For example, two people may respond to an alert to go in and fix something. I usually check, with users, to see if somebody beat me too it. If everybody was logging in as root it would be unclear. But based on everybody's answers so far, that would seem to be the only advantage. And the disadvantage is having to enter my password to do sudo. Mar 16, 2015 at 23:22

Not the answer you're looking for? Browse other questions tagged .