A side node on security: It's not a good idea to allow root access from the internet or even a local network. Consider to create a non-privileged management-user account and then issue specific sudo /bin/whatever commands (w/o password) by that particular user. After testing, disable root access (i.e. /etc/ssh/sshd_config). Take care to disable password expiration for that user and change PKs regularily. That are the basics. Study the hardening documentation of your distro for more measures.

All good and right. But OpenSSH has another nice feature that we use for our backups:

There is a central Linux backup server that connects to each real and virtual Linux machine in need of a backup. It does so as root, both on the backup and on the target machine, on a dedicated network, using a public key distributed to all target machines. After connecting, it runs rsync through the ssh connection to fetch changes since the last backup. All target machines are essentially configured the same. root can login, but only using public keys stored in /root/.ssh/authorized_keys. The relevant line in /etc/ssh/sshd_config is PermitRootLogin prohibit-password. Up to this point, the root user on the backup server would be allowed to run any command as root on the target machine. But the authorized_keys file can do more than that: You can specify a command (using the command option) that will be executed INSTEAD of the command passed via the ssh connection. In our case, it's a simple shell script that aborts for anything but rsync, by checking the original command passed via $ENV{'SSH_ORIGINAL_COMMAND'}. Effectively, this limits the root access via ssh to running rsync. Also in the authorized_keys file, the access is restricted to only the backup server, and only via the dedicated backup network, using the from option.

Combining this features, you get a very restricted root access, not needing any passwords, but still reasonable secure. Of course, this trick also works for other users, and allows even more restricted access. Combine that with a restrictive sudoers file, and you should be pretty secure.

Yes, one could abuse rsync to write files TO the target machine instead of reading changes FROM the target machine. Using a smarter command that knows more about rsync parameters could prevent that. But to do so, you would have to gain root access to our backup server, and at that moment, we would be screwed anyway.

Just for reference, this is our authorized_keys file:

from="the.one.backup.server",command="${HOME}/.ssh/ssh_validate.sh",no
+-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa
+ AA...Rw== some-note-about-this-key
[download]

It's not perfect. Instead of selectively disabling features, all features should be disabled using the restrict option, as OpenSSH promises to add any future restriction capabilities to this option. And the command path should be absolute, not relying on $ENV{'HOME'} to be set correctly.

And this is ssh_validate.sh:

#!/bin/sh
case "$SSH_ORIGINAL_COMMAND" in
        *\&*) echo "Rejected" ;;
        *\;*) echo "Rejected" ;;
        rsync*) $SSH_ORIGINAL_COMMAND ;;
        *) echo "Rejected" ;;
esac
[download]

Again, it's not perfect. It prevents running stuff in background, or several commands combined using semicolons, and anything not starting with rsync. I can think of a few ways to do evil stuff despite these limitations. $ENV{'SSH_ORIGINAL_COMMAND'} should be validated much more. Maybe one day, I'll find some time to fix that.

I did not invent that mechanism, I inherited it from the previous root, and it is sufficient for our company. Only three people can legally gain root access, and from the other ones not more than two might have or gain the knowledge required to illegally gain root access and to bypass ssh_validate.sh.

But to cause as much damage, no knowledge of Linux is required. Just find a big hammer from the workshop, and hit anything roughly looking like a server as hard as you can until it stops emitting sparks or any sounds. Almost anyone in the company knows where the main servers are mounted, and most of them also know the location of the backup server. That attack is probably also much faster than fiddling with the Linux command line. Yes, there are doors with locks between the servers and the outside world, but nothing that would withstand a big hammer.

Alexander