Cool OpenSSH authorized_keys tricks

I have used the ~/.ssh/authorized_keys file with OpenSSH for ages. However, I always treated it as just a dumb list of keys, where I would dump my public key whenever I needed access to a new account or host.

But today I learned from this blog entry that there is a bit more to it. Details are available from `man 8 sshd’.

Basically, each key can be prefixed by a list of options which restrict the kind of access granted to a connection attempt providing the given key.

Of particular interest is the command=”/usr/local/bin/foobar” option. This makes sshd run the given command on connect, disabling the normal login shell or direct execution of commands supplied by the remote user. There are also a few further options for disabling port forwarding, pty allocation, and similar stuff. This can be used to provide ssh-authenticated access to only certain controlled services, not including arbitrary remote shell access.

This is really useful, as it allows a very flexible way of setting up secured access to custom services, building on the widespread and very mature SSH infrastructure already in place all over the ‘net. The blog entry linked above discusses this for setting up remote access to revision control repositories. I could probably have put it to good effect on a remote build setup for a continuous integration system I built at MySQL a few years back, if I had known it existed. And I imagine that I will find it useful for something in the future.

It is a really good idea to build custom remote access security on top of SSH like this. It means one can reuse existing key infrastructure, avoid reinventing the wheel (and reinventing strong authentication is very much not trivial to do correctly!), etc.

And I agree btw. with the blogger that this method of setting up restricted access with OpenSSH is quite hard to do securely. It is of course very easy to put in the wrong options in authorized_keys and open some hole for arbitrary command execution. So beware!


  1. rssh

    I’m starting to implement this now.
    For a simple, second layer of security, I’m making the remote user’s shell rssh.
    At least that way, their choice of arbitrary commands to hack in there are limited.

    You can also set up chroot jails for rssh, but I’m not that sophisticated (yet).
    At least if your authorized_keys has a hole, exposure can be limited with rssh

    1. Re: rssh

      aargh. It appears that you need to choose between rssh or a command= directive in the authorized_keys file. they do not work together.
      For now, I’m sticking with the new rssh with only cvs and svnserve allowed.

Leave a comment

Your email address will not be published. Required fields are marked *