Now the actual authentication takes place, which, in its simplest form,
consists of entering a password as mentioned above. The goal of SSH was to
introduce a secure software that is also easy to use. Because it is meant
to replace rsh and rlogin, SSH must also be able to provide an
authentication method appropriate for daily use. SSH accomplishes this by
way of another key pair, which is generated by the user. The SSH package
provides a helper program for this: ssh-keygen. After entering
ssh-keygen -t rsa
or
ssh-keygen -t dsa
, the key pair
is generated and you are prompted for the base filename in which
to store the keys.
Confirm the default setting and answer the request for a passphrase. Even if
the software suggests an empty passphrase, a text from 10 to 30
characters is recommended for the procedure described here. Do not use short
and simple words or phrases. Confirm by repeating the passphrase.
Subsequently, you will see where the private and public keys are stored, in
this example, the files id_rsa
and
id_rsa.pub
.
Use
ssh-keygen -p -t rsa
or
ssh-keygen -p -t dsa
to
change your old passphrase. Copy the public key component
(id_rsa.pub
in the example) to the remote machine and
save it to ~/.ssh/authorized_keys
. You will be asked to
authenticate yourself with your passphrase the next time you establish a
connection. If this does not occur, verify the location and contents of
these files.
In the long run, this procedure is more troublesome than giving your
password each time. Therefore, the SSH package provides another tool,
ssh-agent, which retains the private keys for the duration of an X session.
The entire X session is started as a child process of ssh-agent. The
easiest way to do this is to set
the variable usessh
at the beginning of the
.xsession
file to yes
and log in via
a display manager, such as KDM or
XDM. Alternatively, enter
ssh-agent startx
.
Now you can use ssh or scp as usual. If you have distributed your public key as described above, you are no longer prompted for your password. Take care of terminating your X session or locking it with a password protection application, such as xlock.
All the relevant changes that resulted from the introduction of
version 2 of the SSH protocol are also documented in the file
/usr/share/doc/packages/openssh/README.SuSE
.