SSH II - Setup

Summary:

• Generating Your Own Key Pair
• Distributing Your Key
• Keeping Keys In System Memory

Generating Your Own Key Pair

Generating and distributing your own keys has two advantages: you protect yourself from 'man-in-the-middle' attacks (e.g. by a machine which fakes the fingerprint of the remote host) and you can use one password for all the servers you connect to.

Notice that there are currently two major, partly incompatible versions of SSH in use: version 1 and version 2. Whereas SSH version 2 servers can be configured to accept keys created with version 1, you are better off when you create two key pairs: one for version 1 and one for version 2. Since the names of the generated keys are different, they can be stored in the same directory and you can let the SSH server figure out which key it wants.

The version 1 key is generated by the command

ssh-keygen

The key using version 2 wants this:

ssh-keygen -t rsa

Version 2 'RSA' keys as generated by this command are preferred to version 2 'DSA' keys.

'ssh-keygen' will invoke the following dialog:

Generating RSA keys: ............................ooooooO......ooooooO<br> Key generation complete.<br> Enter file in which to save the key (/home/&#123;user&#125;/.ssh/identity):

Created directory '/home/&#123;user&#125;/.ssh'.<br> Enter passphrase (empty for no passphrase):

Enter same passphrase again:<br>

Your identification has been saved in /home/{user}/.ssh/identity.

Your public key has been saved in /home/&#123;user&#125;/.ssh/identity.pub.<br> The key fingerprint is: 2a:dc:71:2f:27:84:a2:e4:a1:1e:a9:63:e2:fa:a5:89 &#123;user&#125;@&#123;local machine&#125;

ssh-keygen -t rsa

Now you have a key pair: a public key to distribute to all the remote machines you want to ssh to and a private key, which is the heart of the authentication process. Which means: no one should ever be able to access your private key1.1

ls -l ~~/.ssh/identity

ls -l ~~/.ssh/id_rsa

-rw––-

If you suspect your private key has been compromised, do not hesitate to generate a new pair. You will then have to distribute your new public key again, of course.

section index

Distributing Your Key

On each server you need an SSH connection to, create a .ssh subdirectory in your home directory. Into this directory, copy the local file '/.ssh/identity.pub' and rename it to 'authorized_keys'. Likewise for version 2 keys: copy '/.ssh/id_rsa.pub' and rename it to 'authorized_keys2'. Now execute on the remote server

chmod 644 .ssh/authorized_keys .ssh/authorized_keys2

Do not forget this step, SSH won't work if the 'authorized_keys(2)' file is writable by anyone other than you1.1

'authorized_keys(2)' can hold more than one public key, in case you want to connect to the remote server from a different machine. In this case you have to generate a new key pair on the machine, copy the content of the local 'identity.pub' file and paste it into the remote 'authorized_keys' file. Of course you should only do that if you have an account of your own on the client machine and the key is password protected1.1 Furthermore, don't forget to remove the key pair when you no longer need it.
Simply put: it's better not to use key-based authentication on untrustworthy machines ;).

section index

Keeping Keys In System Memory

This method comes in handy when you usually connect to more than one machine during a session. The trick is to run applications which are automatically authenticated. This is achieved by a combination of the programs

ssh-add

ssh-agent

man ssh-add

"The authentication agent must be running and must be an ancestor of the current process for ssh-add to work."

Huh? ;)

ssh-agent

eval

eval $(ssh-agent)

You should now see a message like

Agent pid {number}

Enter

ssh-add

in the same terminal and the key will be loaded into memory, asking you for the password, if you have protected the key with one. Now you can start SSH sessions from this terminal without having to give any passwords, provided you set up the SSH 'config' file accordingly, which will be discussed on the next page.

The 'pure' ssh-add command will be default only load SSH version 1 keys. To load a version 2 key, you have to specify its filename:

ssh-add .ssh/id_rsa

To load both keys (version 1 and version 2) at once, you have to specify both filenames:

ssh-add .ssh/identity .ssh/id_rsa

If you want to be 'ssh-agent' the 'ancestor' of all virtual terminals in a session, add the command

eval $(ssh-agent)

ssh-add

Notice that all this isn't necessary for ML 7.1 and later, if you boot directly into X: '/etc/X11/Xsession' automatically starts the agent if there is an SSH key in the user's '~~/.ssh' directory.

Other useful options are

• ssh-add -l

  which lists the key(s) currently kept in memory, and

• ssh-add -d

  which removes an identity from the system memory.

And now for some SSH configuring ...

Other Languages: Français?

Related Resources:

SSH FAQ
Getting started with SSH

man ssh-keygen

man ssh-add

man ssh-agent

Revision / Modified: Sep. 27, 2001 / Oct. 09, 2001
Author: Tom Berger

Legal: This page is covered by the GNU Free Documentation License. Standard disclaimers of warranty apply. Copyright LSTB and Mandrakesoft.