www-106.ibm.com/developerworks/linux/library/l-keyc2 -> www-106.ibm.com/developerworks/linux/library/l-keyc2/
Linux | 10 Open source projects 11 developerWorks Common threads: OpenSSH key management, Part 2 12 85KB 13 e-mail it! One of OpenSSH's more intriguing features is its ability to authenticate users using the RSA and DSA authentication protocols, which are based upon a pair of complementary numerical "keys". One of the main appeals of RSA and DSA authentication is the promise of being able to establish connections to remote systems without supplying a password. In this second article, Daniel introduces ssh-agent (a private key cache) and keychain, a special bash script designed to make key-based authentication incredibly convenient and flexible. With ssh-agent you simply use ssh-add to add your private keys to ssh-agent's cache. Using ssh-agent Let's take a look at how this whole ssh-agent key caching system works. When ssh-agent starts up, it spits out a few important environment variables before detaching from the shell and continuing to run in the background. Due to the included export commands, these environment variables would be made available to any additional commands run later. Well, all that would happen if these lines were actually evaluated by the shell, but right now they're simply printed to stdout. To fix this, we can invoke ssh-agent in the following way: eval ssh-agent This command tells bash to run ssh-agent and then evaluate ssh-agent's output. Invoked this way (with back-quotes, not normal single quotes), the SSH_AGENT_PID and SSH_AUTH_SOCK variables get set and exported by your shell, making these variables available to any new processes you may start during your login session. The environment variable of particular importance is SSH_AUTH_SOCK; Using ssh-add But of course, ssh-agent starts up with an empty cache of decrypted private keys. Before we can really use ssh-agent, we first need to add add our private key to ssh-agent's cache using the ssh-add command. Limitations of ssh-agent ssh-agent is really cool, but its default configuration still leaves us with a few minor inconveniences. If you only open a single terminal or console on your system, this is no big deal, but most of us open quite a few terminals and need to type in our passphrase every single time we open a new console. Technically, there's no reason why we should need to do this since a single ssh-agent process really should suffice. Another problem with the default ssh-agent setup is that it's not compatible with cron jobs. Since cron jobs are started by the cron process, they won't inherit the SSH_AUTH_SOCK variable from their environment, and thus won't know that a ssh-agent process is running or how to contact it. Enter keychain To solve these problems, I wrote a handy bash-based ssh-agent front-end called keychain. What makes keychain special is the fact that it allows you to use a single ssh-agent process per system, not just per login session. This means that you only need to do one ssh-add per private key, period. As we'll see in a bit, keychain even helps to optimize the ssh-add process by only trying to add private keys that aren't already in the running ssh-agent's cache. However, the result is the same -- our ever-important SSH_AUTH_SOCK is defined, and ssh-agent is running and ready for use. First, head over to the 28 keychain project page and download the most recent available version of the keychain source archive. Now, if you log out and log back in again, you'll find that keychain will find the existing ssh-agent process; In addition, keychain will verify that the private key you specified are already in ssh-agent's cache. If not, then you'll be prompted for the appropriate passphrases, but if all goes well, your existing ssh-agent will still contain the private key that you previously added; In fact, as long as your initial ssh-agent process keeps running, you'll be able to log in and establish ssh connections without supplying a password. And it's very likely that your ssh-agent process will continue to run until the machine is rebooted; Welcome to the world of secure, passwordless connections using RSA and DSA authentication. Go ahead and create several new login sessions, and you'll see that keychain will "hook in" to the exact same ssh-agent process each time. Don't forget that you can also get your cron jobs and scripts to "hook in" to the running ssh-agent process. Keychain options After you have keychain up and running, be sure to type keychain --help to familiarize yourself with all of keychain's command-line options. We're going to take a look at one in particular: the --clear option. You'll recall that in 29 Part 1, I explained that using unencrypted private keys is a dangerous practice, because it allows someone to steal your private key and use it to log in to your remote accounts from any other system without supplying a password. Well, while keychain isn't vulnerable to this kind of abuse (as long as you use encrypted private keys, that is), there is a potentially exploitable weakness directly related to the fact that keychain makes it so easy to "hook in" to a long-running ssh-agent process. What would happen, I thought, if some intruder were somehow able to figure out my password or passphrase and log into my local system? If they were somehow able to log in under my username, keychain would grant them instant access to my decrypted private keys, making it a no-brainer for them to access my other accounts. Now, before I continue, let's put this security threat in perspective. If some malicious user were somehow able to log in as me, keychain would indeed allow them to access my remote accounts. Yet, even so, it would be very difficult for the intruder to steal my decrypted private keys since they are still encrypted on disk. Also, gaining access to my private keys would require a user to actually log in as me, not just read files in my directory. Nevertheless, if an intruder were successfully able to log in as me, they could do quite a bit of additional damage by using my decrypted private keys. So, if you happen to be using keychain on a server that you don't log into very often or don't actively monitor for security breaches, then consider using the --clear option to provide an additional layer of security. The --clear option allows you to tell keychain to assume that every new login to your account should be considered a potential security breach until proven otherwise. When you start keychain with the --clear option, keychain immediately flushes all your private keys from ssh-agent's cache when you log in, before performing its normal duties. Thus, if you're an intruder, keychain will prompt you for passphrases rather than giving you access to your existing set of cached keys. However, even though this enhances security, it does make things a bit more inconvenient and very similar to running ssh-agent all by itself, without keychain. Here, as is often the case, one can opt for greater security or greater convenience, but not both. Despite this, using keychain with --clear still has advantages over using ssh-agent all by itself; Since a logout from the system does not constitute a potential security breach, there's no reason for keychain to respond by flushing ssh-agent's keys. Thus, the --clear option an ideal choice for infrequently accessed servers that need to perform occasional secure copying tasks, such as backup servers, firewalls, and routers. Now that the OpenSSH key management series is complete, you should be very familiar with RSA and DSA keys and know how to use them in a convenient yet secure way. Be sure to also check out the following resources: Resources * Read 30 Part 1 and 31 Part 3 of Daniel's series on OpenSSH key management on developerWorks. The 37 Authors' site contains information about the book, a FAQ, news, and updates. He has also served as a contributing author for the Macmillan books Caldera OpenLinux Unleashed, SuSE Linux Unleashed, and Samba Unleashed. Daniel has been involved with computers in some fashion since the second grade, when he was first exposed to the Logo programming language as well as a potentially dangerous dose of Pac Man. This probably explains why he has since ...
|
http://csua.com/feed/