S 5.64 Secure Shell

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

When having no special add-ons, the protocols telnet and ftp only offer rudimentary authentication mechanisms. Usually, simple querying of user ID and password is performed; then, this data - just like the payload - is sent as plain text. Confidentiality of the authentication data and payload is not ensured this way. The related protocols rsh, rlogin and rcp, which are often summarised as the r services, show similar security problems.

Secure Shell (ssh) can be used as alternative tool for the r services; it uses comprehensive functions for secure authentication and for ensuring confidentiality and integrity. This makes use of a hybrid encryption method, i.e. a combination of asymmetric and symmetric encryption. The Secure Shell is located in layer 7 (application layer) of the ISO/OSI reference model; however, other protocols such as the X11 protocol used by the graphical interface X-Window can also be transported via ssh.

Currently, Secure Shell is based on three protocols that are built on each other and that have an Internet draft, respectively.

Implementations of both ssh clients and ssh servers exist for all established Unix operating systems. Moreover, there are ssh clients for Windows, Mac OS, and as Java applet, among others.

In principle, the use of Secure Shell is recommended when using the functions of the r services via communication channels that are not sufficiently protected against compromising and/or manipulation (e.g. via the Internet). The following states some information on the secure use of ssh.

The risk exposed by man-in-the-middle attacks are of particular importance. Here, the attacker filters the whole traffic between the communication partners and forwards the counterfeited public key. If the communication partners are not able to verify the public key, the attacker may read and manipulate the whole traffic by decrypting the data, reading and modifying the data, and then encrypting the data with another key and forwarding them. This can be prevented by using a suitable key/certificate management. When using Secure Shell in practice, this often represents a compromise enabling the use of ssh without any additional infrastructure. Here, when connecting to a host whose public key is not known yet, this public key will be sent via the insecure network and stored in a local database When establishing subsequent connections to this host, its public key can then be verified with the help of the local database. It should be verified within scope of the security concept whether this procedure offering reduced protection against man-in-the-middle attacks will be sufficient for the present application.

The Internet drafts include specified cryptographic procedures that must be provided by the Secure Shell implementations. Optionally, additional cryptographic algorithms can be implemented. The procedures actually used will be negotiated at the time of establishment of the connection. By selecting suitable client and server programs as well as a suitable configuration it should be ensured that the ssh client and the ssh server agree on qualified cryptographic algorithms that meet the security requirements.

When using ssh, other protocols whose functions are covered by Secure Shell, e.g. the r services and telnet, should be completed deactivated, if possible, so that the security safeguards cannot be circumvented. However, this requires that all communication partners have suitable implementations.

It is known that older implementations of ssh include security-relevant program errors. Correspondingly, a version that eliminates such problems should be used. Compatibility between implementations, whose program versions differ significantly, could be problematic. Mixed use should be avoided correspondingly.

It should be taken into account that content-sensitive control of the data flow is not possible any more when using ssh via firewalls.

Review questions:

© Federal Office for Information Security. All rights reserved.