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
Содержание LINUX ENTERPRISE DESKTOP 11
Страница 1: ...SUSE Linux Enterprise Server www novell com 11 March 17 2009 Security Guide...
Страница 9: ...32 7 Managing Audit Event Records Using Keys 433 33 Useful Resources 435...
Страница 10: ......
Страница 29: ...Part I Authentication...
Страница 30: ......
Страница 55: ...Figure 4 2 YaST LDAP Server Configuration LDAP A Directory Service 41...
Страница 126: ......
Страница 127: ...Part II Local Security...
Страница 128: ......
Страница 158: ......
Страница 173: ...Part III Network Security...
Страница 174: ......
Страница 194: ......
Страница 197: ...Figure 16 2 Scenario 2 Figure 16 3 Scenario 3 Configuring VPN Server 183...
Страница 210: ......
Страница 228: ......
Страница 229: ...Part IV Confining Privileges with Novell AppArmor...
Страница 230: ......
Страница 274: ......
Страница 300: ......
Страница 328: ......
Страница 340: ......
Страница 342: ......
Страница 386: ......
Страница 387: ...Part V The Linux Audit Framework...
Страница 388: ......