RSA Authentication for SSH
and its related utilities like scp and sftp,
make up the core tools for safely communicating across the network.
By default, SSH sessions are authenticated by typing in passwords,
but this can be awkward to do in scripts and inconvenient or
impossible in some situations.
Rather than using passwords, one can set up RSA keys which are
exchanged by client and server for authentication.
SSH public/private key pairs
In order to avoid typing passwords, a public/private key pair may be used.
The public key is not secret and can be freely distributed.
The private key is secret and it must be safeguarded as anyone
who possesses the private key possesses the identity it represents.
Here's how the keys work.
The public key is used by a client to encrypt a message for the owner
of the private key.
Only the private key can decrypt messages encrypted by the public key.
When a client first connects to a server, they each symmetrically use
this technique to set up an encrypted channel between them by exchanging
From that point forward all communication goes over the encrypted
link which is why ordinary ssh can then be used to supply the user's
However, it's also possible to employ key pairs for authentication.
Before attempting to authenticate the user with a server, the client
authenticates the server by asking for that server's public
key and searching for a match by the server's name in the known_hosts
file on the client.
If it's not found, the client asks its user whether to continue by accepting
the server's public key.
(It's also possible for the server to challenge the client to identify
itself using a public key authorized by the server,
but we don't require this)
To use the server's ssh services, the client uses the public key of the server
to send the server the public key of the user.
At its end, the server searches a list of authorized public keys
and, if matched, uses the key to create a challenge for the client.
A client possessing the corresponding private key will be able
to decode the challenge and return a response.
When the server receives the correct response it knows that the
client possesses the users private key and so grants the user access.
- "ssh -v ..." causes the login negotiation to be displayed
and is useful in debugging.
- ssh clients silently refuse to use private keys
if .ssh or its parent directory is group or world writable
- The host name used when searching known hosts files
is the exact name used for the connection,
e.g. "gpo" is distinct from "gpo.stanford.edu".
For all command options and additional information, see the
OpenSSH manual pages.
Setting up personal SSH V2 RSA keys
The following instructions are for setting up an identity in the home
directory of user descartes on the unix cluster
Because the home directory is generally mounted by all machines,
a single set of keys is sufficient.
For the keys to work, the client machine must find the private key saved
where the ssh client expects it and it must store the public key
of each server in the ~descartes/.ssh/known_hosts.
For the server to accept the key for authentication, the public
key must be found in ~descartes/.ssh/authorized_keys file.
If you copy the .ssh directory to a Cygwin home directory on Windows,
then you can ssh without passwords from that machine as well.
- Create .ssh directory
- mkdir -m 700 .ssh
- cd .ssh
You may also put a config file in this directory to set
defaults. One handy default is to have your RSA key forwarded
on if you ssh again. To do this, add the following lines:
- Host *
- ForwardAgent yes
- Create SSH V2 RSA identity with ssh-keygen
There are two versions of the SSH protocol and each version can
have an RSA identity.
Although the version 1 protocol is valid, it is no longer the
default when using ssh.
Unfortunately version 1 is the default when using the
key generation utility so you must be careful to specify
that you want "-t rsa" when creating keys.
- ssh-keygen -t rsa -f id_rsa
generates a keypair under the default name for version 2.
You will be given the chance to specify a passphrase
which ssh will use to encrypt the private key.
This passphrase provides strong additional security, especially
on the cluster home directories where preventing
access to the private key cannot be guaranteed.
The use of a passphrase is now strongly recommended.
One can now easily use passphrase protection for all identities,
including ones used by helper programs such as ssh tunnels for mail clients.
The ssh-agent and ssh-add commands on
Unix and Cygwin and Putty's Pageant service permit you to
enter the passphrase once to unlock the private key for use with
all clients for the rest of your session.
OS-X 10.5 and later understand passphrase-protected keys
and will store them in your keychain.
Without a passphrase it's critical that the private key file permissions
allow only you to access it.
- Create authorized_keys file (writable only by owner)
- touch authorized_keys
- chmod 600 authorized_keys
- Add the public key to authorized_keys file
- cat id_rsa.pub >>authorized_keys
- Perform initial login to accept and add host public key to known_hosts file
- ssh gpo.stanford.edu date
Setting up CVS to use SSH V2 RSA keys
To use CVS securely in a remote setting you should use SSH and
you can use RSA identities, like the one created above, to avoid
Independent CVS users
When the CVS repository is on a machine where everyone has an id,
then if each person sets up an identity as above, all they need
do is tell CVS to use SSH by setting up an environment variable:
Shared Common CVS user
Sometimes it's more convenient or necessary to have all the
CVS commands executed as single local user on the server.
This can be done as follows:
The CVS requests are transformed and issued with
"ssh firstname.lastname@example.org cvs...."
- On the CVS server (e.g., repository.stanford.edu)
in the home directory of the local id you will use for
CVS (e.g. ~hotproj) append the public key part of one or
more ssh identities (the content of ~descartes/.ssh/id_rsa.pub above)
to the file ~hotproj/.ssh/authorized_keys.
The authorized_keys file can have
keys in it from as many remote users as you wish.
- On the client set the environment variable CVS_RSH=ssh
- Each client CVS command uses email@example.com
when connecting to the repository
You only need a single private/public keypair. As long as the client has the
private key and the server has the public key in its authorized_keys, file,
you're good-to-go. You could reuse your existing keys if you want.
You could even use the same keypair for all CVS users although that
means if the key is ever compromised, all users will have to get a new one.
- The client ssh picks up the key in ~descartes/.ssh/id_rsa.pub
and sends it to the sshd on repository.stanford.edu.
- the sshd server on repository looks in
and if the key sent is found there, the CVS command is executed as
August 6, 2010 03:56:52 PM
Stanford Computer Graphics Laboratory