Is it always better to put authorized_keys in one's own .ssh directory rather than in root's .ssh directory? [duplicate]

Question

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.

Thanks,

doug

Answer 1

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).

Answer 2

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.

Answer 3

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).