How to make a restricted user which can only start a shellscript?

Question

How can I create a local user, which can log in via SSH to linux machines, ex.: SLES12 and can only execute a shellscript, which comes up after SSH login?

So it shouldn't be able to trick that it would read any other users 777 file or issuing other any commands.

The shellscript would be a small menu-based stuff, which executes commands via sudo, that I can handle, only question is the restriction for the user that it really should face the menu-based script automatically when loggin in and it shouldn't be able to issue cmds via ex.: "ssh user@linuxmachine "somecmd""

Answer 1

You can force that with the command= flag in the authorized_keys file on the server side. From man sshd:

command="command"

Specifies that the command is executed whenever this key is used for authentication. The command supplied by the user (if any) is ignored. The command is run on a pty if the client requests a pty; otherwise it is run without a tty. If an 8-bit clean channel is required, one must not request a pty or should specify no-pty. A quote may be included in the command by quoting it with a backslash.

This option might be useful to restrict certain public keys to perform just a specific operation. An example might be a key that permits remote backups but nothing else. Note that the client may specify TCP and/or X11 forwarding unless they are explicitly prohibited, e.g. using the restrict key option.

The command originally supplied by the client is available in the SSH_ORIGINAL_COMMAND environment variable. Note that this option applies to shell, command or subsystem execution. Also note that this command may be superseded by a sshd_config(5) ForceCommand directive.

If a command is specified and a forced-command is embedded in a certificate used for authentication, then the certificate will be accepted only if the two commands are identical.

You'll find lots of examples for this in tutorials on settings up git, bzr, and friends, for ssh access, where you want them to do nothing but access the version control.

Note there's also a sshd_config directive ForceCommand, which does mostly the same thing ("Forces the execution of the command specified by ForceCommand, ignoring any command supplied by the client and ~/.ssh/rc if present. The command is invoked by using the user's login shell with the -c option."), but also works if you use password-based login and can be restricted to certain source IPs. It will need to go into the global server configuration, though, so it doesn't scale well.

Answer 2

What you are looking for are restricted shell. Look into rbash and the security issues that come with it. If you set it up properly this might work for you. Better options are to use virtual environments or jails if your OS support that.

Answer 3

What's the expected threat level? Is it enough that the menu system can withstand accidental misuse and casual experimentation, or is it protecting something of actual value that might attract serious attacks?

For the more casual end of the spectrum, this old-school Unix trick might be enough:

Make sure the menu script is executable without any parameters, add it to /etc/shells and then use chsh to set the menu script as the shell for that user.

You'll need to make sure the user cannot escape from the menu script into a command mode, but if the user simply interrupts the menu script, the restricted session just ends.

If the user attempts to execute other commands (e.g. using the ssh <host> <command> syntax), the execution of those commands will be attempted using the menu script in place of a regular shell. If the menu script takes no parameters in any case, the attempt will fail and the user will end up in the menu anyway.

This is for traditional password-based logins; if can enforce the use of SSH key authentication exclusively, the command= flag in the authorized_keys file, as suggested by Ulrich Schwarz is pretty much at the same level.