Difference between revisions of "Set up ssh-agent"

From cctbx_xfel
Jump to: navigation, search
(Added comments from the Gentoo documentation.)
(Added comments from the "OpenSSH key management" article series.)
Line 1: Line 1:
Checking out or updating the ''PHENIX'' sources will establish many ssh(1) connections to cci.lbl.gov.  While not necessary for a successful installation, having an ssh-agent(1) running on the machine used to access cci.lbl.gov will save much error-prone password-typing.  The idea is to provide the remote system with the public half of a cryptographic key pair, which enables it to send a challenge to the ssh-agent.  If the agent agent has acquired a corresponding private key, it can decrypt the challenge, thus authenticating to the remote system without any further user intervention.
+
Checking out or updating the ''PHENIX'' sources will establish many ssh(1) connections to cci.lbl.gov.  While not necessary for a successful installation, having an ssh-agent(1) daemon running on the machine used to access cci.lbl.gov will save much error-prone password-typing.  The idea is to provide the remote system with the public half of a cryptographic key pair, which enables it to send a randomly generated challenge to the ssh-agent.  If the agent agent has acquired a corresponding private key, it can decrypt the challenge, thus authenticating to the remote system without any further user intervention.
  
 
<!-- 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.  -->
 
<!-- 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 ==
 
== Creating a cryptographic key pair ==
The first step is to generate a pair of cryptographic keys.  One of the keys is public and the other is private; together they define an <i>identity</i>.  This step can be skipped if a key pair already exists.  In the example below, the key pair is generated in the default location, <i>/home/user/.ssh/id_rsa</i>.  The passphrase, <b><i>yourverysecretpasswordhere</i></b> below, is used to encrypt the private key, and this passphrase will be needed to use the key pair.  The passphrase should be complex—when using ssh-agent(1) one will not need to type it very often.  It is possible to generate a key pair without a passphrase, but then anybody who gains access to the key also acquires access to all systems the key unlocks.
+
The first step is to generate a complementary pair of cryptographic keys.  One of the keys is public and the other is private; together they define an <i>identity</i>.  This step can be skipped if a key pair already exists—it is perfectly safe to use the same key pair to authenticate to any number of remote systems.  In the example below, the key pair is generated in the default location, <i>/home/user/.ssh/id_rsa</i>.  The passphrase, <b><i>yourverysecretpasswordhere</i></b> below, is used to encrypt the private key, and this passphrase will be needed to use the key pair.  The passphrase should be complex—when using ssh-agent(1) one will not need to type it very often.  It is possible to generate a key pair without a passphrase, but then anybody who gains access to the key also acquires access to all systems the key unlocks.
 
  $ ssh-keygen
 
  $ ssh-keygen
 
  Generating public/private rsa key pair.
 
  Generating public/private rsa key pair.
Line 14: Line 14:
 
  The key fingerprint is:
 
  The key fingerprint is:
 
  <i>ba:f2:7a:78:aa:b0:33:1d:53:de:63:01:62:15:d6:c9 user@host</i>
 
  <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.
+
Then, start the ssh-agent, and add the newly generated identity to the ssh-agent's cache of decrypted private keys.
 
  $ eval `ssh-agent`
 
  $ eval `ssh-agent`
 
  $ ssh-add
 
  $ ssh-add
Line 48: Line 48:
 
== Using agent forwarding ==
 
== 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.
+
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.  ''keychain'' will recognize that agent-forwarding is in effect and will not start a new agent on the remote system.  Note that forwarding the agent connection has security implications.
  
  

Revision as of 06:48, 5 February 2014

Checking out or updating the PHENIX sources will establish many ssh(1) connections to cci.lbl.gov. While not necessary for a successful installation, having an ssh-agent(1) daemon running on the machine used to access cci.lbl.gov will save much error-prone password-typing. The idea is to provide the remote system with the public half of a cryptographic key pair, which enables it to send a randomly generated challenge to the ssh-agent. If the agent agent has acquired a corresponding private key, it can decrypt the challenge, thus authenticating to the remote system without any further user intervention.


Creating a cryptographic key pair

The first step is to generate a complementary pair of cryptographic keys. One of the keys is public and the other is private; together they define an identity. This step can be skipped if a key pair already exists—it is perfectly safe to use the same key pair to authenticate to any number of remote systems. In the example below, the key pair is generated in the default location, /home/user/.ssh/id_rsa. The passphrase, yourverysecretpasswordhere below, is used to encrypt the private key, and this passphrase will be needed to use the key pair. The passphrase should be complex—when using ssh-agent(1) one will not need to type it very often. It is possible to generate a key pair without a passphrase, but then anybody who gains access to the key also acquires access to all systems the key unlocks.

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): yourverysecretpasswordhere
Enter same passphrase again: yourverysecretpasswordhere
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
ba:f2:7a:78:aa:b0:33:1d:53:de:63:01:62:15:d6:c9 user@host

Then, start the ssh-agent, and add the newly generated identity to the ssh-agent's cache of decrypted private keys.

$ eval `ssh-agent`
$ ssh-add
Enter passphrase for /home/user/.ssh/id_rsa: yourverysecretpasswordhere
Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)

ssh(1) will now find the running ssh-agent(1), and attempt to use the keys it holds to authenticate with the remote system.

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 ~/.ssh/authorized_keys on the remote system.

$ cat ~/.ssh/id_rsa.pub | ssh user@remote.host "cat - >> ~/.ssh/authorized_keys"

This will append the public key of the recently created key pair to ~/.ssh/authorized_keys on the remote 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. The private key would have to be unlocked from every login shell separately. Furthermore, 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. If no ssh-agents are running, keychain starts a new process and uses ssh-add(1) to add the specified identities.

At CCI and SLAC keychain is installed at ~hattne/gentoo/usr/bin/keychain (at NERSC it is at /global/project/projectdirs/lcls/gentoo/usr/bin/keychain). 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 ~/.bash_profile:

 test -x /path/to/keychain && \
   eval `/path/to/keychain --agents ssh --eval id_rsa --inherit any-once --stop others`

csh(1) would modify ~/.login instead.


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 -A option to forward the authentication agent when logging in. keychain will recognize that agent-forwarding is in effect and will not start a new agent on the remote system. Note that forwarding the agent connection has security implications.


External links