Restricting SSH Commands in bash

You’d like to restrict what an incoming SSH user or script can do.*

Edit the ~/.ssh/authorized_keys file, use SSH forced commands, and optionally disable unnecessary SSH features.

For example, suppose you want to allow an rsync process without also allowing interactive use.
First, you need to figure out exactly what command is being run on the remote side.
Create a key and add a forced command to tell you.

Edit the ~/.ssh/authorized_keys file and add:

before the key. It will look something like this, all on one line:

Now execute your command and see what the result is.

Now, the problem with this approach is that it will break a program like rsync that depends on having the STDOUT/STDIN channel all to itself.

But we can work around that by modifying our forced command as follows:

So on the client side we try again:

And on the remote host side we now have:

So we can update our forced command as necessary.
Two other things we can do are to set a from host restriction and disable SSH commands.

The host restriction specifies the hostname or IP address of the source host.

Disabling commands is also pretty intuitive:

So when we put it all together, it looks like this (still all on one giant line):

If you have any problems with ssh, the -v option is very helpful. ssh -v or ssh -v -v
will almost always give you at least a clue about what’s going wrong.

Give them a try when things are working to get an idea of what their output looks like.
If you’d like to be a little more open about what the key can and can’t do, look into
the OpenSSH Restricted Shell rssh (http://www.pizzashack.org/rssh/), which supports scp, sftp, rdist, rsync, and cvs.
You’d think restrictions like these would be very easy, but it turns out they are not.
The problem has to do with the way SSH (and the r-commands before it) actually
work.

It’s a brilliant idea and it works very well, except that it’s hard to limit.

To vastly oversimplify it, you can think of SSH as connecting your local STDOUT to
STDIN on the remote side and the remote STDOUT to your local STDIN.

So all things like scp or rsync do is stream bytes from the local machine to the remote machine as if over a pipe.

But that very flexibility precludes SSH from being able to restrict interactive access while allowing scp.

There’s no difference. And that’s why you can’t put lots of echo and debugging statements in your bash configuration files  that output will intermingle with the byte stream and cause havoc.
So how does rssh work? It provides a wrapper that you use instead of a default login
shell (like bash) in /etc/passwd.

That wrapper determines what it will and will not allow, but with much more flexibility than a plain old SSH-restricted command.