If you've administered any remote Linux machines, then you're probably already familiar with SSH. As you may know, SSH provides secure, encrypted network communication. Utilities like ssh and sftp, which are based on SSH, protect remote login sessions and file transfers, respectively, and have largely subsumed similar but insecure and unencrypted utilities such as ftp, rlogin, rsh, rcp, and telnet. (In fact, if any of your systems still use telnet, put down this magazine at once, go disable telnet, install and enable SSH, and then continue reading.)
If you’ve administered any remote Linux machines, then you’re probably already familiar with SSH. As you may know, SSH provides secure, encrypted network communication. Utilities like ssh and sftp, which are based on SSH, protect remote login sessions and file transfers, respectively, and have largely subsumed similar but insecure and unencrypted utilities such as ftp, rlogin, rsh, rcp, and telnet. (In fact, if any of your systems still use telnet, put down this magazine at once, go disable telnet, install and enable SSH, and then continue reading.)
The ssh utility is easy to use, but typing passwords again and again is a hassle, and precludes scripting remote access. This month, let’s explore a better way to use SSH, using OpenSSH (http://www.openssh.org) and SSH protocol version 2. (If you’re using a different SSH suite or protocol version 1, some of this month’s instructions may not apply or may need to be modified to suit your version of the software.)
To connect to a remote machine, say hosta.example.com, via ssh, simply type:
Typically, the remote machine prompts for a password, but you can also configure the remote machine to use public key authentication.
Public key authentication involves a pair of keys: a private key and a public key. The private key is retained on your local system (where it’s arguably very safe), and the public key is propagated to remote systems. When you attempt to login in to a remote machine, the (local) private key and the (remote) public key are “combined” by the remote server and verified. If the keys match, the remote server permits and establishes your login or file transfer session.
For SSH protocol version 2, the DSA algorithm is used to generate the private and public keys. The private key is generated into $HOME/.ssh/id_dsa, and the public key is created in $HOME/.ssh/id_dsa.pub, both on the local host. To use the public key with a remote host, you must append it to $HOME /.ssh/authorized_keys on that host.
Let’s go ahead and set that all of that up. First, generate the public and private keys with ssh-keygen, using the command:
The command prompts for a passphrase (a password to protect your keys), which you can leave blank for now, and then creates $HOME/.ssh/id_dsa and $HOME/.ssh/id_dsa.pub, the private and public key, respectively.
Make sure to keep your private key private by changing its mode to “read/write by user only” via:
% chmod 600 $HOME/.ssh/id_dsa
Next, copy the id_dsa.pub file to the remote server you’d like to log into and append it to $HOME/.ssh/authorized_keys2 on that server. (If that file doesn’t exist, you can simply rename id_dsa.pub to authorized_keys2.) After that file’s in place, be sure to set its permissions with chmod 600 authorized_ keys2. If authorized_keys2 is readable by anyone other than you, ssh will refuse to match keys.
You should now be able to login to the machine without a password. If you’re unable to login, retry using ssh v, which prints debugging information. In some cases, the remote server may not permit public-key authentication.
Logging in without a password can be very useful. For instance, it allows you to automate backups and script the execution of remote commands.
With this convenience, however, comes a risk. Since access to the remote machine is now tied to your private key, a compromised key can compromise the remote machine. For an extra level of security, protect your private key with a passphrase. To use a passphrase with public key authentication, follow the exact steps as above, except fill in a passphrase when prompted during the creation of your keys.
If your situation requires you to remember a large number of passphrases, you’ll eventually get frustrated having to remember a multitude of machine/passphrase combinations. Luckily, OpenSSH comes with a program named ssh-agent to help manage your keys.
Typing sshagent starts the agent and puts it in the background. To add a key, which ssh-agent calls an identity, use ssh-add. By default, ssh-add tries to load $HOME/.ssh/id_dsa (and some others), or you can specify a filename. ssh-add prompts for the passphrase once and then remembers the passphrase until it shuts down. You can see a list of managed identities at any time by typing ssh add l.
One drawback to ssh-agent is that it is tied to a login session. To avoid this you may want to look into keychain, which was covered in the August 2002 issue of Linux Magazine (available online at http://www.linux-mag.com/2002-08/potm_01.html), and works across an entire system.
Jeremy Garcia is the founder and administrator of
LinuxQuestions.org, a free, friendly, and active Linux community. Please send questions and feedback to firstname.lastname@example.org.
is the founder and administrator of LinuxQuestions.org, a free, friendly, and active Linux community that filters its email with SpamAssassin. Please send questions and feedback to email@example.com.