Suppose I wanted to add a group of users who are allowed to run mount and umount without passwords.
So I first want to add a group called "anyname"
sudo groupadd anyname
Next we need to edit the /etc/group and add the users
anyname:x:407:
will be present ,hence append users you want to add the users seperated by commas.
anyname:x:407:user1,user2,...
Now we need to configure sudo to allow members of the "anyname" group to actually invoke the mount and umount commands.
You just need to add the following lines to /etc/sudoers
%anyname ALL=NOPASSWD: /sbin/mount, /sbin/umount
Now sudo mount wont ask password but since it is a pain in the butt typing sudo all the time, we can avoid it by dong the following:
I can create the following script called "/usr/bin/mount" (and similar script for umount)
#! /bin/sh
sudo /sbin/mount $*
To make this slightly more secure, We might want to change the ownership of these scripts to the "anyname" group.
chgrp anyname /usr/bin/mount /usr/bin/umount
and then make them executable only for the group "anyname"
chmod g+x /usr/bin/mount /usr/bin/umount
EDIT:Depending on the OS you are using please check where mount and umount commands are located. It might be in /bin/ instead of /sbin.So you might have to make necessary changes
IMPORTANT: BTW don't run the script on Arch based systems where all of the bin folders are symlinked with each other.
General Considerations
Whenever using SSH, password authentication should be avoided, i.e. the /etc/ssh/sshd_config file should contain the following lines:
PermitRootLogin no
PasswordAuthentication no
However, if one - for some reason - has to use password authentication, one should use established, well known and tested tools, like sshpass. Do not start to pipe around passwords by yourself.
If using pubkey authentication it does not make sense to protect the private key by a passphrase, if the passphrase is in turn stored inside a config file or alike. If an attacker is able to gain filesystem read access to steal the private key file, he will also be able to steal the config file.
All commands that can run with user privileges, should run with user instead of root privileges.
The used programming language will not be considered in this answer, since there is no difference between Python's subprocess.call, Java's java.lang.Runtime.exec or a subshell environment inside a shell script with regards to security.
Further hardening the remote host against external attackers by configuring a firewall, putting IDS/IPS systems in place and the like will also not be considered, since it is out of scope.
That said, let us consider different scenarios:
Running Commands of Which a Finite Subset Requires Root Privileges
One should use a separate user (adduser --shell /bin/rbash --disabled-password remcmdexec will create a user with a restricted shell, not able to do local but only remote logins, see man adduser and man rbash) in combination with a sudoers file that allows this user to only run the required, finite set of commands as root (see man sudoers) on the remote host:
# /etc/sudoers
remcmdexec ALL = (root:root) NOPASSWD: /usr/bin/systemctl reload some.service
Requiring a password to run these commands with sudo does not make sense, since local login was disabled (--disabled-password parameter) and an attacker who was able to steal the key file will also be able to steel the required password (see answer's first section).
The authorized_keys file should contain further restrictions to prevent e.g. port forwarding, see man sshd:
restrict ssh-rsa <BASE64-PUBKEY-REPRESENTATION> remcmdexec
It should further be owned by root and being read- but not writable by the remcmdexec user, to prevent removal of SSH restrictions:
$ ls -l /home/remcmdexec/.ssh/authorized_keys
-rw-r--r-- 1 root root 739 Sep 18 22:47 /home/remcmdexec/.ssh/authorized_keys
Invoke e.g. ssh remcmdexec@remhost sudo /usr/bin/systemctl reload some.service for a command that requires root privileges. For all other commands skip sudo.
Running Commands of Which a Nonfinite but Proper Subset Requires Root Privileges
The same setup as presented at the answer's previous section can be used, but the sudoers file needs to be adapted:
remcmdexec ALL = (ALL:ALL) NOPASSWD: ALL
This is, because remcmdexec finally needs to gain root privileges. Understand that an attacker who is able to login as remcmdexec is now able to remove each and every restriction put in place on the remote host, no matter how intricately the way to achieve root privileges was designed. Therefore all those restrictions are futile in regards to security (A willing attacker). However, they are not futile in regards to safety (System failures).
Running a Nonfinite Set of Commands of Which All Require Root Privileges
It does no longer make sense to use sudo. Instead login in as a user with root privileges to run a command: ssh root@remhost /usr/bin/somecmd
Therefore the following line has to be present at the /etc/ssh/sshd_config file:
PermitRootLogin prohibit-password
However, keep the restrictions inside the authorized_keys file to preserves some basic safety.
Best Answer
Are you sure that the program you are trying to execute is actually a binary, and not a shell script. Most shells ignore suid scripts because they are really, really hard to do safely. An easy way to check is to use the
filecommand on the program.