SSH Keys

ssh with public/private key combinations

Reviewed by bil hays 2018.04.25

Reason for public/private key pair authentication

The ssh program (see our article on ssh) has the ability to use public/private encryption key pairs for authentication between machines instead of passwords.  An advantage of public/private key encryption is the ability to open a secure connection to a machine such as the department CVS server without having to enter a password for each transaction.

Recommended structure for public/private encryption key pairs for CS linux account with home dirs in AFS

Note that this doesn’t apply to your personal machine, windows machines, or other OSes that do not use AFS as home directory space.

The downside to using public/private key pairs is that an AFS token is not obtained on authentication, and that means you land in your afs home directory with read/write rights, and your login profile will not load.

Also, since AFS permissions only apply to folders, not files, a public key has to be in a .ssh directory that is readable by a user without an AFS token.  The CS Dept suggests a workaround to this problem of a rearranged directory structure for ssh and a frontend for the ssh and scp commands that defaults to this structure.

The recommended structure for running public/private key encryption pairs is to place private keys into ~/.ssh-private and place public keys into ~/.ssh/authorized_keys.  The access to ~/.ssh-private is closed off to everyone but the user, while the access to ~/.ssh is opened up to unauthenticated users.

Some users have had success placing id_rsa in ~/.ssh and setting up a ~/.ssh/config file under UNIX.  Into this ~/.ssh/config place a description of any host to which a public/private key authenticated connection is desired.  In addition, place a default description that turns off public/private key authentication for all other hosts.

Here are the sample entries for ~/.ssh/config:

PubkeyAuthentication = yes
ForwardX11 = no

Host *
PubkeyAuthentication = no
ForwardX11 = yes

Generating public/private encryption key pairs

To generate a pair of public/private encryption keys, run the following commands on your AFS home directory:

mkdir ~/.ssh-private
/usr/bin/fs setacl ~/.ssh-private <userid> all -clear
/usr/bin/ssh-keygen -N ” -t rsa -b 4096 -f ~/.ssh-private/id_rsa
touch ~/.ssh/authorized_keys
/bin/cat ~/.ssh-private/ >> ~/.ssh/authorized_keys
/usr/bin/fs setacl ~/.ssh cs-machines rl
/bin/chmod go-w ~
/bin/chmod go= ~/.ssh

The second command sets the AFS access control list on the ~/.ssh-private directory so that only one’s userid has any permissions on it.  The third command generates a 4096 bit RSA type key and places it into ~/.ssh-private/id_rsa and ~/.ssh-private/  Longer keys can be created by increasing the number of bits.

The third command creates the public and private keys and places them into the ~/.ssh-private directory with filenames id_rsa for the private key and for the public key.  The keys created are unlocked by the -N ” option and do not require a passphrase or password to use them.

The fourth command creates a file for the list of SSH authorized keys.

The fifth command appends the public key onto the list of SSH authorized keys.

The sixth command opens read access to the ~/.ssh directory to machines on the CS production network.

The seventh command ensures that UNIX write permission is not set for group and other on the home directory.   Although the UNIX permissions on the home directory are ignored by AFS, some applications, including the ssh server daemon, check UNIX permissions as a method for providing some security.

The eighth command ensures that UNIX permissions for group and other are empty on the ~/.ssh directory where the public key resides.  This is to avoid potential security checks by the ssh server daemon.

If one wants to be able to read UNIX startup files while unauthenticated, the home directory needs to be set with read permissions for cs-machines.  Before opening up read access to all of the department machines, place any sensitive files into a directory with tighter permissions.  In order to access ~/.ssh without authentication, the home directory ~ has to have at least read and list permissions (rl).

Utility for using ssh key pairs to connect between machines

Users should use the ‘ssh-agent’ utility to load keys for use in connecting between machines.  In order to start the ssh-agent under the bash shell, first check to see whether an agent is already running, and, if necessary start one. For example,

[ -z “${SSH_AUTH_SOCK}” ] && eval $(ssh-agent);

The GNOME Desktop Environment starts an ssh-agent upon login, so the check for an ssh-agent should only be needed when connecting to another machine via ssh.

Keys are added to an ssh-agent with the command:
ssh-add <key-file>

For example, ssh-add ~/.ssh-private/id_rsa.

The department used to provide utilities for connecting between machines using SSH Key Pairs, sshp and scpp.  These utilities encapsulated the presentation of an ssh key with a subset of the functionality of ssh-agent and ssh-add.

NOTE: When using SSH Key Pairs to connect between machines, a user lands without an AFS token.  Therefore, the remote connection may not work quite as expected:

bluetang/anderegg $ ssh snapper
Last login: Thu Jan 6 10:16:31 2011 from
Kickstarted Wed Jan 13 09:25:20 EST 2010
$ /usr/bin/tokens

Tokens held by the Cache Manager:

–End of list–

This demonstrates how the shell was opened on the remote machine, and how there are no AFS tokens on the remote machine.

NOTE: The department is experimenting with Kerberos ticket-granting-ticket forwarding and automatically obtaining an AFS token at the other end. Users can test this by invoking the ‘-K’ option when connecting between two machines with ssh. Under Red Hat Enterprise Linux 5 users must manually add the options ‘-oGSSAPIAuthentication=yes -oGSSAPIDelegateCredentials=yes’. Although the Kerberos forwarding can be made a default, it won’t be the default until this behavior works across all Linux systems in the department.

Testing public/private encryption key authentication

Test a public/private key authentication between two machines by verifying that an ssh-agent is running by testing for SSH_AUTH_SOCK, ensuring that keys are present by running ‘ssh-add -L’, and then running ssh and verifying that you are not asked for a password.

Using SSH public/private encryption key authentication from Windows CVS

A student here in the department has used TortoiseCVS for Windows with the Plink SSH client from PuTTY.  The URLs are:

According to the student, Plink SSH uses its own key format, so it will be necessary to generate the public/private keys inside of Plink and append the public key to your ~/.ssh/authorized_keys directory.  You still need to open up your ~/.ssh directory to cs-machines with read and list permission as listed above.

Using public/private encryption key authentication from CygWin environment

A student here in the department has used the .ssh-private and .ssh directory setup with OpenSSH under CygWin and Windows.  Inside of CygWin a bash script similar to /usr/local/bin/sshp was placed in the
home directory.  This script was then invoked by WinCVS to connect to