S 5.64 Secure Shell

Initiation responsibility: Head of IT Section, IT Security Management

Implementation responsibility: Administrators, users

Without special extensions, the telnet and ftp protocols offer only rudimentary mechanisms for authentication. As a rule, a simple request is issued for the user ID and password, which then - in exactly the same way as the user data - are sent as plain text. The confidentiality of the authentication data and user data can therefore not be ensured. The related protocols rsh, rlogin and rcp, which are often grouped under the term rservices, exhibit similar security deficiencies.

Secure Shell ( ssh) can be used as a substitute for the r-services. It makes use of extensive functions designed to ensure secure authentication and to maintain confidentiality and integrity. This is achieved with a hybrid encryption technique, in other words a combination of asymmetric and symmetric encryption. The Secure Shell resides on layer 7 (application layer) of the ISO/OSI reference model; other protocols can also be transported via ssh, however, such as the X11protocol, which is used by the graphical user interface XWindows.

Currently Secure Shell is based on three protocols, one built upon the other. An Internet draft has been drawn up for each one.

• The lowest protocol is the transport layer protocol. This protocol performs the majority of the security functions of ssh, namely authentication at the host level, encryption, and protection of data integrity. The cryptographic algorithms are negotiable between the communication partners.

• The middle protocol is the user authentication protocol. This allows authentication at the user level; in this case, too, the procedure can be negotiated. If a method of simple transmission of user IDs and passwords is used for the purpose of authentication, the confidentiality of the information with respect to the communication route is ensured by the underlying transport layer protocol. The recommended approach, however, is to use a public key procedure for authentication.

• The connection protocol is built on the two preceding protocols and allows several logical user information channels to be set up. The data on these user information channels is transmitted via a common single Secure Shell connection.

There are implementations of ssh clients and ssh servers for all commonly used Unix operating systems. There are also ssh clients for 32-bit Windows, OS/2 and Macintosh, among others, and as a Java applet.

Basically the use of Secure Shell is to be recommended if the functionalities of the r-services are used via communication channels which are not adequately protected against compromise and/or manipulation (for example via the Internet). A few notes on the secure use of ssh are given below.

One risk that is particularly significant is that of attacks known as man-in-the-middle attacks. These involve the attacker filtering all traffic between the communication partners and forwarding forged public keys. If the communication partners are unable to check the public keys, the attacker can read and manipulate all of the traffic by decrypting the data himself, then reading it and modifying it before finally encrypting it with another key and forwarding it to its destination. This can be prevented with the aid of a suitable key/certificate management structure. When Secure Shell is in practical operation, however, a compromise solution is often used, which allows the use of ssh without any additional infrastructure. When a connection is set up to a host whose public key is not yet known, the public key is sent via the non-secure network and stored in a local database. For all subsequent connections with that host, the public key can then be checked using the local database. It must be clarified within the framework of the security concept whether this approach, which offers a lower level of security against man-in-the-middle attacks, is adequate for the application concerned.

The Internet drafts contain definitions of cryptographic procedures which have to be made available by the Secure Shell implementations. There is also the option, however, of implementing additional cryptographic algorithms. The procedures that are actually used are negotiated during the establishment of a connection. Suitable client and server programs must be chosen and an appropriate configuration put in place in order to ensure that the ssh client and ssh server agree on eligible cryptographic algorithms which satisfy the security requirements.

Whenever ssh is used, if possible all other protocols whose functionality is covered by Secure Shell, i.e. for example the r-services and telnet, should be entirely deactivated so that the safeguards cannot be circumvented. This assumes, however, that all communication partners have suitable implementations at their disposal.

There are known to have been program errors relevant to security in older implementations of ssh. A version should therefore be used in which any such deficiencies have been eliminated. Compatibility between implementations with widely differing program versions may be a problem in some circumstances. Mixed operation should therefore be avoided if possible.

It should be noted that when ssh is used across firewalls, it is no longer possible to have content-sensitive control of the data flow.

Additional controls:

• Are r-services or similar protocols used via non-secure communication channels?

• How is the verification of public host keys regulated when using Secure Shell (organisational measures, for example)?

• Have all of the known security deficiencies been corrected in the version of Secure Shell that is used?