Datasheet

“main” (Installation and Administration) — 2004/6/25 — 13:29 — page 654 — #680
i
i
i
i
i
i
i
i
26.4.5 The SSH Daemon (sshd) — Server-Side
To work with the SSH client programs ssh and scp, a server, the SSH dae-
mon, 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. There-
fore, 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 ac-
cordingly by the default installation. The private keys are only required
locally by the SSH daemon and must not be given to anyone else. The pub-
lic 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 pro-
tocol and software versions and to prevent connections through the wrong
port. Because a child process of the original SSH daemon replies to the re-
quest, several SSH connections can be made simultaneously.
For the communication between SSH server and SSH client, OpenSSH sup-
ports versions 1 and 2 of the SSH protocol. A newly installed SUSE LINUX
system defaults to version 2. To continue using version 1 after an 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 ses-
sion key and cannot be derived from the public parts. Only the SSH dae-
mon contacted can decrypt the session key using its private keys (see man
/usr/share/doc/packages/openssh/RFC.nroff). This initial con-
nection phase can be watched closely by turning on the verbose debugging
option -v of the SSH client.
654
26.4. SSH — Secure Shell, the Safe Alternative