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, 2014 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, 2014 at 13:39

2 Answers 2


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.


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).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .