Allowing automatic command execution as root on Linux using SSH

I believe an appropriate solution for a majority of simple cases [ ie if a framework like Puppet/Chef/CfEngine/Ansible is overkill ], but a high level of control of the remote system is required is to

(a) Require key based authentication (b) lock down the locations that can be used by SSH - particularly to lock down the IP addresses that root users can use (c) Ensure that the machines with this trust relationship are properly secured.

I do not believe "logging in as root is frowned upon", as much as "logging in as root to do things which do not require root permissions" is frowned upon. Having a guessable password makes it possible for the account to be brute-forced, so that is an issue to contend with, and by allowing people to log in as root they can make stupid errors with a wider scope, and do questionable things which hide malicious activity - but depending on the architecture this may not actually be meaningful.

This XKCD commic points out that depending on the environment, it may not actually matter if a root account is compromised.

Probably the simpist and most effective solution for the general case is to limit exactly who can log in as root by controlling the keys in conjunction with specifying an appropriate AllowUsers line in /etc/ssh/sshd.conf. An appropriate line to allow normal users but lock root access down might look like:

  AllowUsers normaluser1 normaluser2 [email protected]

Of-course, it is important that password based login is disallowed, or that the root account does not have a password (ie has a "!" or "*" in the password field of the password file.)

As you have postulated, if only a single (or small number of) program(s) need to be run, you might be better off setting up a specific user with key based authentication and allowing appropriate sudo access to the required commands.

There are, of-course, a lot of things that can be done to "lock down" access further, depending on the value of the data - selinux, remote logging, limited shell, time-of-day constraints, notifications immediately on logins, active log monitoring like fail2ban [ in addition to network restrictions which I see as non-optional] can all be part of a solution. That said, if you are simply controlling a system which can be blown away and recreated easily, much of this is likely overkill.

Please remember that security is built up in layers, in order to be able to get root access, an account should need to get through a number of layers. Locking down access, SSH private keys, firewalls, time-of-day restrictions [ and principle of least access, ie only providing access to what is needed, no more, logging, backups ] should all function together as part of good security.

Additional - SUDO access

Sudo is a mechanism to allow a regular user to run certain commands with elevated access, and is quite flexible and varied in scope. While a rundown of sudo is not appopriate here (but is well documented if you type man sudo in most distributions, the appropriate steps might be -

1. Edit /etc/sudoers - Most variants of Linux have a special program to do this called "visudo" which needs to be run as root, and roughly equivalent to using the system editor to edit /etc/sudoers (which is another way to do this - although probably fround upon)

2. Add/change appropriate lines to let a given user do particular things. If, for example, you wanted them to be able to mount directories for example and without having to enter a password, you would enter a line like :

   username    ALL=/sbin/mount NOPASSWD: ALL
   

To then run this command the appropriate user would run something like

  sudo mount /dev/xxx /path/to/mount

You can list multiple lines for multiple commands, uses groups rather then uses - sudoers is a fairly flexible subsystem. In many distributions it is also possible to add files with commands to a subdirectory like /etc/sudoers.d

The following is an answer from the Unix Stackexchange post
How to remote execute ssh command a sudo command without password.

This method lets the administrator of the server to allow your account to execute one command as sudo without specifying the password. The command is probably the call to your script, and it is only allowed when run under your account. As the permitted command is entirely specified including arguments, I believe that this method is pretty secure.

you can tell sudo to skip password for some command.

e.g. in /etc/sudoers

archemar  ALL = (www-data) NOPASSWD: /bin/rm -rf /var/www/log/upload.*

this allow me to use

sudo -u www-data /bin/rm -rf /var/www/log/upload.*

as archemar without password.

Note that

sudo -u www-data rm -rf /var/www/log/upload.*

won't work (will ask a password) as rm differ from /bin/rm.

Be sure to edit /etc/sudoers using visudo command.

Once you've reach advanced level, you might wish to have your own sudo files in /etc/sudoers.d.