If I change the root password on a linux server, can someone still access root if they created an SSH authorized_key for root user?

Question

I'm not even sure if I asked that right. Anytime someone mentions changing the root password, they mention changing /etc/passwd, or just using the passwd command, but I've never heard of having to change it in an authorized_keys file as well. Where might I find that, and how can I safely delete an entry or change this for root without causing havoc? Thanks!

Answer 1

Yes. You'll need to delete the user's public SSH key to completely remove access. If you're simply trying to remove one user's access to root it's a little tricky. Hopefully you've been using separate private keys, because otherwise you'll have to recreate the file and redistribute the public keys to the authorized users.

To remove the entry, you need to edit the authorized_keys file. If this is your root user on a Linux box, chances are the the file can be found at /root/.ssh/authorized_keys. You'll need to remove the line that contains the public key of the user that you're removing. Unfortunately, there's no easy way to know what line this is without a copy of that user's public key.

Answer 2

Yes; it's considered bad practice to allow people to ssh in as "root" for just this reason. Your boxes should probably have root's ssh disabled, and use something like "sudo" to provide access controls over who can do what as root, that way you won't need to give out the root password or anything equivalent.

Leavers' accounts can simply be disabled and you can guarantee that they can't get back in (unless of course, they've left some back doors, which is something you can't do anything about anyway).

We use an ldap directory to store users, groups and ssh keys, then restrict "sudo" access by group.

Answer 3

If someone has had root, it's very difficult, perhaps impossible, to be sure they can't get it back, unless you reinstall and restore from a backup taken before they had access. Things to watch out for: firstly an old trick: any extra users in /etc/passwd with UID 0. For example:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
..etc...
something-innocuous:0:42:foo:/:/bin/sh
..etc..

That extra user would have a separate password and be effectively root as soon as they logged in.

Run visudo if you have sudo installed, and check for anything unusual there.

You should check /etc/pam.conf and all of /etc/pam.d (possibly elsewhere too?) to make sure nothing is configuring PAM to grant passwordless login to root from a particular IP or similar.

You should check for any extra processes running as root, that might offer up a root shell to a particular remote or local user; that process' executable need not exist on disk anymore, or need not be what it was when the process was started.

Finally, if you still don't think it's impossible: search any mount points whose mount options don't contain nosuid for setuid/setgid binaries (using something like find -perm /6000) or binaries that root might run, that might have been modified. Which ones might have been modified/added recently? Any of them. Timestamps are trivial to change.

A rootkit might have done any combination of the above, and might have patched the kernel (perhaps in memory too, without a reboot) to impede your ability to detect it (removing things from ps/netstat etc.)

Good luck. :-)

Answer 4

If you use SSH keys, you might want to consider disabling a password altogether.

SSH is close to unhackable without passwords, but these two are like an "or" so if you can hack either, you're hacked.

Answer 5

You can disable root logins via ssh by setting PermitRootLogin no in your sshd_config file. If you have servers exchanging data or remotely executing commands as root (e.g. backup some systems) then you probably don't want to do this. If this is the case then Kyle Cronin's answer is the way to go.

Answer 6

It is worth thinking very very hard about using ssh's authorized keys for root.

Let's say that I can be root on system ZZ and I add my public key to root's authorized_key. Now, my private key is much more valueable because now it not only lets someone break into possibly all of my accounts, but, it allows root on ZZ as well. Plus, of course, any system that lets root on ZZ also be root on themselves.

Note that if I put my private key on a system that others can be root on, those users can also get root on ZZ since they can trivially get my private key.

etc

etc

etc

It's a very dangerous relaxing of security. People tend to be a bit too free about where they put their private key since it make ssh so much easier.

I concur with no root ssh along with sudo, but, if you do that, you might want to add special users which have no NIS/LDAP/NFS/etc network dependency so that you can still log in when there is a network fubar. Normally root can log in when others can't since root tends to have less of these external requirements.