I've got a server that I want to use as an SSH gateway for remote and local port forwarding. I don't want arbitrary commands to be able to be executed on it, only my scripts.
I keep reading about how restricted shells are easy to break out of, but is rbash good enough if:
- the user has no password (so s/he can't log in to a shell)
- ssh passwords are disabled (so a key is required)
- PATH=~/usr/bin (only, so no files from elsewhere can be executed)
- the entry in ~/.ssh/authorized_keys is prefixed with:
"cmd_handler" is an rbash shell script that can do a couple of different specific things based upon what is piped into ssh from stdin. It lives in the ~/usr/bin folder along with symlinks to executables it requires, specifically
tr. ~/usr/bin is the only folder in PATH, so these are the only commands available.
The user is the group owner, with read-only access, for any files or folders requiring access (including the ~/usr/bin folder). The user is not the owner, and does not have write access, to any files and folders other than ~/.ssh and ~/.ssh/authorized/keys (which is required).
I don't see any way this leaves the system vulnerable, since the single command that can be executed by the remote computer is "cmd_handler". And if, somehow, the remote user could in fact execute another command, there's not much avaialble.
ssh-keygen create the theoretical possibility of ~/.ssh/authorized_keys being modified to execute arbitrary commands, but even if they could, all that's around to use are the seven commands, and if they write something into /tmp or ~/.ssh, it won't matter because rbash won't execute anything not in PATH.
So, back to the original question: is this good enough for what I want to do, or do I really need to look into AppArmor or something? I'd like an answer that explains a specific vulnerability, rather than general statements about everyone knowing that rbash is easy to break out of and whatnot. That may be true, but is it specifically insecure for this application?