3

I have a user account that is not designed for logging in interactively, but want to allow it to run a single command (as root). Is there a better way to accomplish this (without granting more rights than I intend to) than I have currently:

  • Changing their shell to rbash, with sudo as the only executable in their path, as they need a valid shell in order to run any commands.
  • Adding their account to sudoers with "ALL=(root:root) NOPASSWD: /sbin/executable"
  • Adding an authorized_keys entry for the account with no-{X11,port}-forwarding,no-pty,command="sudo executable"

Context: I am trying to grant a non-*nix savvy manager the ability to fix any print server troubles while I am away. Obviously first port of call is the CUPS web interface and physically walking over and inspecting the printer (which he can and does do now), but I can't expect him to ssh in and restart the appropriate services when that fails (and do not trust him with unrestricted sudo access anyway). Currently I am just giving him access to run /sbin/reboot, and I will change that to a script that restarts cups/samba/etc. instead when I get a chance.

  • 2
    Is there any issue with the approaches you have listed? It seems like a perfectly reasonable way to me. – terdon Apr 28 '14 at 13:08
  • I agree with terdon - except that if possible, I'd also limit the IP addresses from which the key can be used. – Jenny D Apr 28 '14 at 13:39
1

If you want to avoid any other possible interraction with the server, one way is to create a dedicated account with your command as connection shell. For instance user "reboot" with uid 0 and /sbin/reboot as connection shell.

The shell can be a script menu, authorizing to choose between options; that way you can use sudo and avoid the UID 0 for the account

1) Purge the print jobs
2) Restart cups
3) Reboot 
4) Quit
Enter your choice: 

Menus scripting here
Much simpler example using bash select function on StackOverflow

Better authenticate with personal ssh keys, that way you will know who is rebooting the server.

0

The way I do it, its to run a web-server-script* executed by root and which executes only the commands you need (like the menu proposed by Emmanuel). Then, you can protect it using a password, or a firewall to restrict who can access to it.

*web-server-script: it can be a small perl script (using HTTP::Daemon), a small java webserver, or anything else, running in a non common port (like higher than 1000).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.