Over the past two tips about OpenSSH, we've considered the use of public key authentication as a way to simply logging in to multiple hosts and even using ssh-agent as a way to avoid repeated login sequences to hosts we have to repeatedly work on through the day. This tip will cover a way to simplify remote access even further with the OpenSSH config file. By making a few quick changes, you can create nicknames for frequently accessed hosts or automate program execution.
Before going any further, it will pay to make sure you're up to speed with the use of public keys. Our last two tips cover everything you need using OpenSSH to get a working public key and ssh-agent setup:
- Crossnodes Tip: Secure and Convenient? Key Authentication with OpenSSH
- CrossNodes Tip: OpenSSH Revisited: Simplify Remote Access with ssh-agent
The OpenSSH configuration file is usually located in the .ssh directory of the user's home. It's called, simply enough, config. It uses a very simple syntax, an example of which we'll use to discuss some time-savers:
host webserver hostname webserver.acmefoo.com user wile
Line by line:
The host line provides ssh with an alias for the remote host to be accessed. This will allow us, with the next line, to access the host 'webserver.acmefoo.com' by typing ssh webserver instead of the full hostname.
The hostname line provides ssh with the full name of the remote host to be accessed. In this case, 'webserver.acmefoo.com'.
The user line provides ssh with our login name on the remote host. If our username on the local machine, for instance, were "jed," and our username on the remote host were "wile," we'd have to use the command ssh -l wile webserver.acmefoo.com to access that host. With the above configuration, we can do it with this command:
ssh webserverwhich saves a healthy amount of typing over time.
Running Commands Automatically
Another useful feature involves running commands automatically based on the key being used to access an account. If, for instance, we only visit a remote server to look in on running processes, or if we'd like to grant limited access to another user without letting them have full access to our account, this is the way to go. We can set up automatic commands by modifying the authorized_keys2 file we created on the remote host in the first tip.
Start by logging in to the remote host, and opening the file .ssh/authorized_keys2 in a text editor. There should be, if our previous tips were followed, a line that starts with something like:
ssh-dss AAA..followed by a long string of characters, and ending with the user name and host from which the key originated.
To execute a command automatically using that key, just append a command starting with command= to the beginning of the key's line, like:
command="/usr/bin/top" ssh-dss AAA....which will execute the 'top' command, a monitor of system processes.
There are some important things to keep in mind, namely that this command will execute automatically unless you take steps to force a login with a password (such as specifying an alternate identity file, which you can create when using the ssh-keygen program we discussed in the first tip. Consequently, if you ever plan to use the account to access more than a single program, you must either specify a program that runs then exits to a shell or a program that allows shell escapes.
This same general functionality can be used to provide limited access to others to your account. By creating a special key called, for instance, "assistant," and copying its attendant "assistant.pub" into the remote .ssh/authorized_keys2 file, you can specify that the person using the 'assistant' key only have access to a given program, like mail or a calendar application.
If you're going to take this approach, remember that if you're really concerned about others accessing more than a single program, you should ensure that the program they're running automatically has no provisions for escaping to a shell: many UNIX programs do.
CrossNodes Net Tips are a regular feature of CrossNodes. If you have a networking tip or trick that you'd like to share, please submit it to the Managing Editor. There can be no financial remuneration, though we will place your byline upon request.