Mandriva Club - KB - SecureSssh2

Space Menu Home Downloads Kiosk Newbie Area Documentation Knowledge Base E-Training Forum Blogs Chat RPMs Farm Linux Events

History |

More Actions

View

Code | XML |

Help

XWiki Syntax |

SSH II - Setup

Summary:

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

Section index - KB index

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/{user}/.ssh/identity):

{Just hit ENTER here unless you already have another key with that name, e.g. for a different SSH version}

Created directory '/home/{user}/.ssh'.<br> Enter passphrase (empty for no passphrase):

{The entered passphrase will not appear on the screen.}

Enter same passphrase again:<br>

{The passphrase is not recoverable. If you forget it, you will have to generate a new keypair.}

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

{This is your private key.}

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

ssh-keygen -t rsa

basically does the same, but saves the key pair by default to '/home/{user}/.ssh/id_rsa' (private key) and '/home/{user}/.ssh/id_rsa.pub' (public key). You can use the same passphrase for both key pairs.

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

should always show these permissions:

-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

and

ssh-agent

man ssh-add

reads:

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

Huh? ;)

ssh-agent

executes several commands, creates an PID file and sets some system environment variables. To make this work, you need the shell's

eval

command:

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)

to your personal X startup files, either '/.xinitrc', if you are starting X from the console, or '/.xsession', if you are booting directly into X. Then run

ssh-add

and all terminals you will open during this session will be authenticated.

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