[From daryl's blog <http://daryl.learnhouston.com/blog/daryl> ]
Using public keys to log in via ssh to servers is a wonderful thing if only because it prevents you from having to type your password each time you want to log in. I've been using this method happily for years. Today, I learned something new (to me) about using public keys to log in. In the authorized_keys file that lists accepted keys for a user, you can specify the "command" option along with some other things that allow you to limit what people can do when logging in. Say for example you wanted to grant someone access to an svn repository with a real user account (because you have other privileged users already hitting the repository with user accounts and so can't use svn's authentication). But you don't want this person to have a full shell or in fact to be able to do anything but use svn. The command option lets you dictate what operation is performed upon login. You prepend the default key output with the command information, as follows: command="program" ssh-dsa AAAABtce9euch⦠[EMAIL PROTECTED] So in my example, I add the following: command="svnserve -t --tunnel-user=svn_username" [from somewhere] This makes it so that as soon as svn_username logs in, he gets a tunnel to the svnserve command. If he's issuing svn commands at his command line and sending the appropriate output, this is great. If he's trying to ssh directly, he gets some server status gobbledegook and is effectively locked out from actually logging into the server. Just what I needed. To prevent further interactivity during the session, you can pass some other options, as follows: command="svnserve -t --tunnel-user=svn_username",no-port-forwarding,no-agent-forwarding,no-X1\ 1-forwarding,no-pty You can also have some other fun with the command, though. For example, just to play around, I created a user and added the command "ls /tmp". Sure enough, when I ssh'd in as that user, I got the output from an ls command. I could see more practical applications, however. For example, you might add "ps -eaf" as a command and have a script try to log a user in periodically and parse the output to see if a given program is running. There are no doubt much better ways of handling this particular case, but you see my point.
