Default solutions for very limited remote linux shells

I have a user that needs to connect to a remote machine M (via ssh) and run one in a fixed set of commands (say N in total).

These commands rely on python, libraries thereof, and privileged access to the network (which machine M has).

Are there default strategies to limit the linux user shell only to the execution of these N commands, without any possibility of:

• further access to the fs
• reading the content of the commands themselves
• acquiring privileged access to the network
• and alike

In other words, what are default strategies to prompt a limited console to the user after they login, allowing, e.g., only numbers between 1 and N as inputs?

There is a neat trick in authorized_keys file, you can use command option to define command to be run on login, identified by a key, so if your N commands are static - they you can define them on the server and voila. It will not restrict the network, only launching the command. It will look something like that in authorized_keys file:

command = "date" ssh-rsa AAAA

You can find more information about this tutorial

To prevent the user from network access - you can use SELinux or other similar software, also you could write a eBPF hook to allow exactly what you want.

Let's assume this is not a tiny chroot or container with only what they need, but rather a general purpose multi user operating system.

With sufficient automation, logging into the host may not be required. Perhaps provide via some self-serve system these limited options, which the automation does.

For letting them do the thing on the host, try what I would call a captive text menu. Which is a script you may need to write.

Strictly confining the person from doing other things requires several tricks.

• Login as a non-privilaged, ideally unique to them user. Escalate for privilaged stuff with tools like doas or sudo.
• Mandate this menu is what runs with OpenSSH ForceCommand blocks.
• Also exec it from shell profiles. exec so it replaces the shell process, and when the menu exits so does their session.
• Trap signals in the menu script.
• Beware programs that can run arbitrary commands. Shelling out is trivial in vim, the command is :shell
• Write and use as menu items wrapper scripts, for more complex operations or more control over output.

Take your pick of scripting languages to write the menu in. Consider using an existing text menu library. An input loop by itself is not difficult, but making it robust, easy to modify, and with good UX is what you actually want in production.