-
Archives
- February 2010
- October 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- November 2007
- October 2007
- September 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
- February 2006
- January 2006
- December 2005
- November 2005
- October 2005
- September 2005
- August 2005
- July 2005
- June 2005
- May 2005
- April 2005
- March 2005
- February 2005
- January 2005
- December 2004
- November 2004
- October 2004
- September 2004
- August 2004
- July 2004
- June 2004
- May 2004
- April 2004
- March 2004
- February 2004
-
Meta
Daily Archives: December 6, 2006
Limiting ssh access with the command option in authorized_keys
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… user@example.com
So in my example, I add the following:
command=”svnserve -t –tunnel-user=svn_username”
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-X11-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.
powered by performancing firefox
Posted in Linux, Tech
Leave a comment