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.
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!