OpenSSH is at home in most Unix environments, and the Mac’s OS X is no exception. But getting OpenSSH to feel a little more Mac-like takes a download or two.
OpenSSH, the standard for secure console access over the Internet, was written to be at home among text shell users or the graphical environment for Unix variants, so getting OpenSSH to feel a little more Mac-like takes a download or two.
For several years now, the standard for secure console access over the Internet has been OpenSSH. Administrators who need shell access on their servers count on OpenSSH to both secure their login and provide some useful convenience features that make dealing with multiple logins simpler.
OpenSSH is right at home in most Unix environments, and OS X is no exception. On the other hand, OpenSSH was written for text shell users or X11, the traditional graphical environment for Unix variants, so getting OpenSSH to feel a little more Mac-like takes a download or two.
One of the most common tasks SSH users have to perform is setting up their public keys. It’s simple enough to use SSH like an encrypted telnet, but with public keys SSH becomes much more useful and secure, because you can take advantage of the SSH agent, a broker that remembers your SSH credentials for other hosts and only requires you to enter a public key password once, instead of every time you log in to a remote host.
If you’re not sure what the benefit of this is, consider this example:
What’s That Term? Not sure what a particular term means? Check out the searchable PracticallyNetworked Glossary. |
Suppose you have to maintain a Web server. We’ll call it “webserver,” a name that makes up for in simplicity what it lacks in flair. Now consider your daily routine if you use a simple password-based login.
To check in on server A, you might enter the command “ssh webserver.” You get a password prompt, you enter your password, do your business, then sign out. But then you remember something else that needed to be done. No problem … “ssh webserver,” enter your password. Now let’s add “mailserver” and “fileserver” to the mix. That’s three sets of passwords on three machines you’re logging in and out of all day long.
This proliferation of passwords can be a drag, and some of the worst security behaviors people indulge in are in reaction to the confusion it engenders. They use simpler passwords than they should, they use the same password everywhere, and they get in the nasty habit of leaving logins to their assorted servers open all the time, which means that both their logins are vulnerable if they wander away from their workstation and they risk doing something that would be perfectly harmless on one machine that could have unexpected consequences if they accidentally do it on another.
The SSH agent handles some of this problem with its use of keys. Here’s that same routine with SSH and a public key with a strong signature:
You open a terminal, you type “ssh-add” and you answer the prompt for your key’s password. For as long as that terminal is open, ssh-agent remembers your key. Every host you log onto that uses that key will, if properly configured, accept your login without needing to know your key’s password. You just type “ssh mailserver” and you log into the mail server, “ssh webserver,” and you’re in the Web server.
The benefits to this approach include a level of convenience, and a better chance that you’ll use more secure passwords for your keys, because you don’t need to enter them as often.
You may also notice a few pitfalls. What, for instance, happens if you close your terminal window? Well, you’ll have to re-add your key to the ssh agent the next time you want to use it. That’s not so terrible from a security standpoint, but it lacks a certain amount of convenience. Especially if you’re using an operating system with a GUI and you don’t like a lot of open terminal windows.
This problem has been solved for a while, though, in the form of graphical tools that allow you to wrap your entire graphical login in an SSH agent. So you start up your machine, enter the password for your public keys at login, and for the rest of your login session, any terminal you open is already authenticated with the agent.
One such tool for OS X, the one we’ll consider today, is SSHKeychain, a simple little app that manages your SSH keys for you and includes a number of features that make SSH under OS X simple but still secure. If you have a PowerPC-based Mac (a G3, G4 or G5), you can just download the current version from the download page. If you have an Intel-based Mac (such as an iMac Core Duo, a Macbook, or a Macbook Pro), you can get a Universal Binary version at this link (that’s a 1.1MB DMG file).
SSHKeychain can run as an application in your dock, or as an icon in your status bar, or both. It’s one of those apps you’ll want to run all day long, so if you don’t like dock clutter you might want to open its preferences and select “Status Bar” under the “Display” preferences.
Making a Key
The tab that will be of the most interest if you’re just starting out with SSH will be the “SSH Keys” window. That’s where you can create and manage your SSH keys. To make a new one, for instance, open SSHKeychain’s preferences and click on the “SSH Keys” icon, then click on the “New…” button.
Click the “Select …” button to pick where the new key will go and what it will be named (traditionally in a hidden directory in your home directory called “.ssh,” which is what SSHKeychain will suggest if it’s present). If you don’t already have keys, you’ll want to name your new one id_dsa.
The default Type (dsa) and number of bits (1024) are fine. Then pick a really secure passphrase for your key and remember it. Since you won’t need to continually reenter this passphrase, it should be stronger than normal. My favorite password creation technique is to pick a sentence then use the first letter of every word from that sentence. For instance, I keep a copy of the AP Guide on my desk, so I might use it for a password by changing “The Associated Press Stylebook and Briefing on Media Law” to “tapsaboml,” then season it with some punctuation or numbers, like “tapsab0ml!”
SSHKeychain will create two files in the directory you told it to: One file will just be called “id_dsa,” the other will be “ida_dsa.pub.” If you add the contents of that .pub file to the file “authorized_keys2” in your .ssh directory on a server where you log in using ssh, you’ll be able to use your ssh key and not your normal password. That means with SSHKeychain running, you can just pop open a terminal and log in.
Security Features
Did you detect the one big problem with just authenticating your SSH key and then not worrying about it for the rest of the day? It’s the same as any other password-based authentication. If you get up and walk away, your computer is an open portal to all your remote hosts for anyone who walks by and sees an opportunity. SSHKeychain’s developer thought of that.
Check out the “Security Settings” icon in the preferences. By default, the “use custom security settings” checkbox should be unchecked. If you check it, you’ll see all of SSHKeychain’s security features. These are worth looking at in a little detail.
On keychain events: If you set this to “both,” your ssh keys are effectively tied to the OS X Keychain. So if you lock your Keychain, the ssh agent forgets your keys. If you unlock your keychain, the agent reauthenticates your keys for you.
On screensaver: The best balance between simple and secure in this setting is probably to select “Lock Keychain.” That way your keys are secure and you only have one password to enter when you return. If you’re not worried about the physical security of your system, “No action” is the most convenient setting.
On system sleep is a setting laptop users might be interested in. If you set this to “Remove keys after time-out,” you can keep your keys active for a period reflective of how much you’re opening and closing your laptop during the day. So if you’re usually back to your laptop within five or ten minutes, but want to remove all the keys when you fold it shut for the night, setting the sleep time-out to 60 minutes might do the trick.
Key time-out is best left to your discretion. If your computer is always on, even when you’re not around it, and if you’re concerned about someone gaining access to your logins when you’re away from it, you’ll have to balance convenience with that concern.
That’s about all we have time for this week, but it puts us in a good position for next week, when we can look at ssh tunneling and a few practical applications for ssh in a Mac context. See you then!
