39.5 The SSH Daemon (sshd)—Server-Side
To work with the SSH client programs ssh and scp, a server, the SSH daemon,
must be running in the background, listening for connections on
TCP/IP port 22. The daemon generates three key pairs
when starting for the first time. Each key pair consist of a private and a
public key. Therefore, this procedure is referred to as public
key–based. To guarantee the security of the communication via SSH,
access to the private key files must be restricted to the system
administrator. The file permissions are set accordingly by the default
installation. The private keys are only required locally by the SSH daemon
and must not be given to anyone else. The public key components
(recognizable by the name extension .pub) are sent to
the client requesting the connection. They are readable for all users.
A connection is initiated by the SSH client. The waiting SSH daemon and the
requesting SSH client exchange identification data to compare the protocol
and software versions and to prevent connections through the wrong port.
Because a child process of the original SSH daemon replies to the request,
several SSH connections can be made simultaneously.
For the communication between SSH server and SSH client, OpenSSH supports
versions 1 and 2 of the SSH protocol. Version 2 of the SSH
protocol is used by default. Override this to use version 1 of the
protocol with the -1 switch. To continue using
version 1 after a system update, follow the instructions in
/usr/share/doc/packages/openssh/README.SuSE. This
document also describes how an SSH 1 environment can be transformed
into a working SSH 2 environment with just a few steps.
When using version 1 of SSH, the server sends its public host key and
a server key, which is regenerated by the SSH daemon every hour. Both allow
the SSH client to encrypt a freely chosen session key, which is sent to the
SSH server. The SSH client also tells the server which encryption method
(cipher) to use.
Version 2 of the SSH protocol does not require a server key. Both
sides use an algorithm according to Diffie-Helman to exchange their
keys.
The private host and server keys are absolutely required to decrypt the
session key and cannot be derived from the public parts. Only the SSH
daemon contacted can decrypt the session key using its private keys
(see man
/usr/share/doc/packages/openssh/RFC.nroff).
This initial connection phase can be watched closely by turning on the
verbose debugging option -v of the SSH client.
The client stores all public host keys in
~/.ssh/known_hosts after its first contact with a
remote host. This prevents any man-in-the-middle attacks—attempts by
foreign SSH servers to use spoofed names and IP addresses. Such attacks
are detected either by a host key that is not included in
~/.ssh/known_hosts or by the server's inability to
decrypt the session key in the absence of an appropriate private
counterpart.
It is recommended to back up the private and public keys stored in
/etc/ssh/ in a secure, external location. In this way,
key modifications can be detected and the old ones can be used again after
a reinstallation. This spares users any unsettling warnings. If it is
verified that, despite the warning, it is indeed the correct SSH server,
the existing entry for the system must be removed from
~/.ssh/known_hosts.