|
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
Key generation complete.
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'.
Enter passphrase (empty for no passphrase):
[The entered passphrase will not appear on the screen.]
Enter same passphrase again:
[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.
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 key! ls -l ~/.ssh/identity or
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  top
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 you!
'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 protected! 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 top
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 programsssh-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 runssh-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
ssh-add -l which lists the key(s) currently
kept in memory, andssh-add -d which removes an identity
from the system memory.
section index top
And now for some  SSH configuring
...
|
