For the communication between SSH server and SSH client, OpenSSH supports ver-
sions 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 en-
crypt 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. 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 inabil-
ity 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
.
14.6 SSH Authentication Mechanisms
Now the actual authentication takes place, which, in its simplest form, consists of enter-
ing 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
164
Security Guide
Summary of Contents for LINUX ENTERPRISE DESKTOP 11
Page 1: ...SUSE Linux Enterprise Server www novell com 11 March 17 2009 Security Guide...
Page 9: ...32 7 Managing Audit Event Records Using Keys 433 33 Useful Resources 435...
Page 10: ......
Page 29: ...Part I Authentication...
Page 30: ......
Page 55: ...Figure 4 2 YaST LDAP Server Configuration LDAP A Directory Service 41...
Page 126: ......
Page 127: ...Part II Local Security...
Page 128: ......
Page 158: ......
Page 173: ...Part III Network Security...
Page 174: ......
Page 194: ......
Page 197: ...Figure 16 2 Scenario 2 Figure 16 3 Scenario 3 Configuring VPN Server 183...
Page 210: ......
Page 228: ......
Page 229: ...Part IV Confining Privileges with Novell AppArmor...
Page 230: ......
Page 274: ......
Page 300: ......
Page 328: ......
Page 340: ......
Page 342: ......
Page 386: ......
Page 387: ...Part V The Linux Audit Framework...
Page 388: ......