RSA Authentication for SSH
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
public keys.
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
password.
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.
Notes:
- "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
under ~descartes/.ssh.
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.
- 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
Note:
If you copy the .ssh directory to a Cygwin home directory on Windows,
then you can ssh without passwords from that machine as well.
Last update:
December 10, 2013 09:33:17 PM
© 1994-2023
Stanford Computer Graphics Laboratory