To work with the SSH client programs ssh and scp, a server (the SSH
daemon) must be running in the background, usually listening for
connections on TCP/IP port 22. The daemon generates three key pairs when
starting for the first time. Each key pair consists 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. Version 1 on the other side is obsolete
and should not be used for new setups or when you need to connect to
servers which supports only the old one. 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
contacted SSH daemon can decrypt the session key using its private keys.
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.
![]() | Backup Your Keys |
---|---|
It is recommended to back up the private and public keys stored in
|