View source for Set up ssh-agent

Checking out or updating the ''PHENIX'' sources will establish many ssh(1) connections to cci.lbl.gov.  Having an ssh-agent(1) running will save much error-prone password-typing. An easy way to accomplish this is to have an ssh-agent(1) running on the machine used to access the remote host. 

<!-- A cryptographic key pair consist of a private key, which should be held secret, and a public key, which should be distributed to the system to which access is desired.  -->

== Creating a cryptographic key pair ==
The first step is to generate a pair of cryptographic keys.  This step can be skipped if a key pair already exists.
 $ ssh-keygen
 Generating public/private rsa key pair.
 Enter file in which to save the key (<i>/home/user/.ssh/id_rsa</i>):
 Enter passphrase (empty for no passphrase): <b><i>yourverysecretpasswordhere</i></b>
 Enter same passphrase again: <b><i>yourverysecretpasswordhere</i></b>
 Your identification has been saved in <i>/home/user/.ssh/id_rsa</i>.
 Your public key has been saved in <i>/home/user/.ssh/id_rsa.pub</i>.
 The key fingerprint is:
 <i>ba:f2:7a:78:aa:b0:33:1d:53:de:63:01:62:15:d6:c9 user@host</i>
Then, start the ssh-agent, and add the newly generated identity.
 $ ssh-agent
 $ ssh-add
 Enter passphrase for .ssh/id_rsa: <b><i>yourverysecretpasswordhere</i></b>
 Identity added: .ssh/id_rsa (.ssh/id_rsa)


== Distribute the public key to the remote system ==

The remote system has to be aware of the key pair to grant access.  This means that the public component of the key pair has to be present in <code>~/.ssh/authorized_keys</code> on the remote system.
 $ cat ~/ssh/id_rsa.pub | ssh <b><i>remote.system</i></b> "cat - >> ~/.ssh/authorized_keys"
This will append the <em>public</em> key of the recently created key pair to <code>~/.ssh/authorized_keys</code> on the <em>remote</em> system.


== Using keychain ==

An ssh-agent started from command line only affects ssh-connections started from the same shell, and separate ssh-agents would be required for each new login shell.  Since ssh-agents are not terminated when the login shell is exited, this has the potential to clutter the system with "orphaned" ssh-agents.  ''keychain'' is a shell script that was written to avoid this situation: it probes the system for any running ssh-agents, and attempts to use a present agent instead of starting a new process.  At CCI and SLAC ''keychain'' is installed at <code>~hattne/gentoo/usr/bin/keychain</code> (at NERSC it is at <code>/global/project/projectdirs/lcls/gentoo/usr/bin/keychain</code>).

It is recommended to run ''keychain'' from the shell configuration files for interactive, login shells.  To do so, bash(1) users can add the following lines to <code>~/.bash_profile</code>:
  test -x <b><i>/path/to/keychain</i></b> && \
    eval `<b><i>/path/to/keychain</i></b> --agents ssh --eval id_rsa --inherit any-once --stop others`
csh(1) would modify <code>~/.login</code> instead.

<!-- Commands in <code>~/.bash_profile</code> or <code>~/.login</code> will only be executed when a new login shell is started, which is appropriate for ssh-agent(1). However, even non-login shells may need environment variables to be set, and in what follows, those will be defined in ~/.bashrc (or ~/.cshrc for csh(1) users). Assuming that all customisations for non-login shells are applicable to login shells as well, putting the line
test -r "${HOME}/.bashrc" && . "${HOME}/.bashrc"
near the top of ~/.bash_profile is a way to avoid duplicating configuration options in ~/.bash_profile and ~/.bashrc. With csh(1), this is not necessary because ~/.cshrc is always read.
-->


== Using agent forwarding ==

It is not necessary to start ssh-agents on every system logged in to.  If an ssh-agent is running on the host used to access the remote system from, the agent can be forwarded using the ssh(1)’s <code>-A</code> option to forward the authentication agent when logging in.  Note that forwarding the agent connection has security implications.