This is a howto discussing the use of Gentoo’s keychain and OpenSSH public-private keys to enable passwordless logins between Linux/Unix machines. When you are done with this process, you will be able to log on to your local machine, type a passphrase once, and that will eliminate the need to type passwords when ssh’ing from that local machine to remote machines. I will explain this howto giving you instructions for generating and using a DSA key which works with ssh2. At the end, I will explain how to add RSA keys that work with ssh1 and RSA keys that work with ssh2. Note, I use tcsh, so some of the commands might be different if you use a different shell, such as bash.
Before I detail the steps for the howto, I want to setup some terminology:
- Local-initiation host: A local-initiation host is any host that you locally log into and from which you wish to log into remote hosts without a password.
- Target host: A target host is any host into which you wish to login using ssh. A local-initiation host may also be a target host.
Here are the steps for setting up passwordless login. These steps should can be run from a local-initiation host.
- Create a DSA public-private key pair.
- Please use the most up-to-date OpenSSH implementation if you are generating your keys on a Debian-based machine (including Ubuntu) because there is a known openssh bug on Debian-based Linux distributions released between September 2006 and May 13, 2008.
- Run:
ssh-keygen -t dsa
- By default it will ask to place your private key in
~/.ssh/id_dsa, which is where you want it.
- Then it will ask you for a passphrase. It is my understanding that an empty passphrase is less secure than a non-empty passphrase, so use an empty passphrase at your own risk.
- Create an authorized keys file and disseminate it to target hosts.
- Ssh uses a file called
~/.ssh/authorized_keys on target hosts to determine if incoming hosts can login without a password . The authorized keys file contains a set of public keys. Any incoming host using an unlocked private key that is paired with a public key in the authorized keys file, will be granted access without a password.
- To create the authorized keys file, run the following commands:
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
Note, this adds your public key to the set of authorized keys.
- Remotely copy the authorized keys file to the
~/.ssh directory of all your target hosts. If the current host is not a target host, then you can delete it from your local host. Make sure the permissions on the authorized keys file on all target hosts is 600.
- Optional: Disseminate your private key to local-initiation hosts.
- If you have more than one local-initiation host, then copy
~/.ssh/id_dsa to the ~/.ssh directories of all your local-initiation hosts, and make sure it has 600 permissions on each host.
- Set up Gentoo’s keychain on local-initiation hosts.
- First, let me explain what keychain does, so you’ll understand the setup.
- If there is not an ssh-agent process running (for the local user), then keychain starts a persistent ssh-agent process.
- Keychain saves environment variables in
~/.keychain/${HOST}-* files with information about the currently running ssh-agent.
- Keychain make private keys know to the currently running ssh-agent, if they are not already known. If the keys are not already known, you are prompted for your passphrase, so they can be loaded.
- Setup steps
- Install Gentoo’s keychain on each of your local-initiation hosts.
- Automatically run keychain. There are two methods to run keychain.
- The first method is to run keychain every time a shell is created. For example, I add the following lines to my
~/.cshrc file to do that:
if (!($?SSH_CONNECTION)) then
if (-X keychain) then
keychain ~/.ssh/id_dsa
source ~/.keychain/${HOST}-csh
endif
endif
This code checks to see if the shell is local or remote(i.e., invoked through an ssh connection). If the connection is local, the shell runs keychain and reads in environment variables identifying where the local ssh-agent is running. (Note, if keychain has already been run, it is actually redundant to run it in every shell.)
- The second method is to run keychain once when you log into a local-initiation host, not every time a shell starts up. This can be accomplished in a few steps. To run keychain once when you login, create the following
keychain-startup.pl script:
#!/usr/bin/env perl
# Import HOST
use Env;
Env::import();
$cmd = "rm -f ~/.keychain/" . $ENV{HOST} . "-*";
`$cmd`;
$cmd = "keychain ~/.ssh/id_dsa";
`$cmd`;
Then set up your current windowing environment to call that script on startup. In Gnome, you can do this if you go through the following menu progression: Ubuntu Main Menu->System->Preferences->Sessions->Startup Programs. In your shell configuration script you need to read the appropriate keychain generated file for your shell, created in ~/.keychain. I do this by adding the following code to my ~/.cshrc file:
if (!($?SSH_CONNECTION)) then
if (-e ~/.keychain/${HOST}-csh) then
source ~/.keychain/${HOST}-csh
endif
endif
- In both methods above, we only run keychain if we are on a local host. If you are on a remote host, i.e., one that you’ve logged into via ssh, there is no need to run keychain on it because you can forward the ssh-agent from the local host, through ssh. That is done by calling ssh with the -A option or by setting up agent forwarding in your <code>~/.ssh/config</code> file. In addition, this eliminates you having to type your passphrase on the remote host. Note, the use of agent forwarding implies that if you start at a local-initiation host, you can type your passphrase once on that host, log into target host A without a password, and then log into target host B from the just-created ssh connection to target host A, also without a password.
- Test your setup.
Troubleshooting:
- Remote host identification has changed: If you try to ssh into a machine and get a warning about the remote host’s identification changing, see this site for an explanation.
- Permission problems: If you’re having troubles, you may want to check the permissions of your
~/.ssh directory and of the files in it. Most notably, your private keys should not be readable by anyone but yourself, and neither your ~/.ssh directory nor the files in it should be writable by anyone but yourself.
Setting up RSA keys in addition to your DSA key:
- Generate the RSA keys similarly to how you generated the DSA key above, except you pass
-t rsa1 to ssh-keygen to generate an RSA key for ssh1 and -t rsa to generate an RSA key for ssh2. Note, private RSA keys for ssh1 are stored in ~/.ssh/identity and private RSA keys for ssh2 are stored in ~/.ssh/id_rsa
- Similarly to what you did with your public DSA key, add your public RSA keys to your authorized keys file and disseminate it to your target hosts.
- Optional: Disseminate your private RSA keys to local-initiation hosts.
- Modify the keychain code you added to your shell configuration file so that keychain is also called with your private RSA keys. For example, I would change the keychain line in my
~/.cshrc file to read: keychain ~/.ssh/id_dsa ~/.ssh/id_rsa ~/.ssh/identity.
For more information:
- Run man on the following: keychain, ssh-keygen, and ssh-agent.
- Visit the following websites:
Posted in gentoo's keychain, gnome, howto, keychain, linux, linux passwordless login, openssh, passphrase, passwordless login, public-private keys, remote access, security, ssh
Tags: gentoo’s keychain, gnome, howto, keychain, linux, linux passwordless login, openssh, passphrase, passwordless login, public-private keys, remote access, security, ssh
