The Secure Shell (SSH)

The Secure Shell (SSH), developed by Tatu Ylonen in 1995, has become one of the internet standards to securely login via potentially unsecured networks. In 2006, SSH v2 was accepted as internet standard RFCs.

The following set of RFCs specifies SSH v2:

  • RFC 4250, The Secure Shell (SSH) Protocol Assigned Numbers
  • RFC 4251, The Secure Shell (SSH) Protocol Architecture
  • RFC 4252, The Secure Shell (SSH) Authentication Protocol
  • RFC 4253, The Secure Shell (SSH) Transport Layer Protocol
  • RFC 4254, The Secure Shell (SSH) Connection Protocol
  • RFC 4255, Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
  • RFC 4256, Generic Message Exchange Authentication For the Secure Shell Protocol

Typical Use of SSH

SSH implements an application layer protocol with the following capabilities:

  • Authentication
  • Channel Encryption and Tunneling
  • Compression

Authentication

Authentication of server and client is part of the authentication protocol (RFC 4252).

Server-side

With SSH, a server is (optionally) identified by a public/private key-pair (aka. host key). During the authentication phase, key exchange takes place. The server makes use of its host key to authenticate itself towards the client connecting.

For server authentication, two server to key associations do exist:

  • client-side database containing the public key of the server
  • certificate server to key binding

In the first case, the client is assumed to have an a priori knowledge of the servers public key stored in a local repository. At first login, a server authenticates itself towards the client and provides its fingerprint for public key validation by the user.

In the second case, a trust relationship based on certificate infrastructure authenticates the server towards the client.

Client-side

The client is able to authenticate itself by three different mechanisms:

  • password
  • public key
  • host-based

Password-based authentication requires the client to send a username/password pair that is used at server-side for client authentication. With the password-based authentication mechanisms, a secured channel between client and server is required since the password is transmitted to the server.

Public key authentication builds on the paradigms of public key cryptography. Under the assumption that the private key of the client is not compromised, clients are authenticated by their private key that is used to create an authentication response to the server. Since no username/password combination is transmitted to the server, potentially less trusted servers do not received any sensitive information during authentication.

Host-based authentication builds on the host key of the client. It requires therefore a non-compromised client.

Channel Encryption and Tunneling

Channel encryption ensures confidentiality of transmitted information. SSH adds integrity preservation mechanisms by using message authentication codes (MAC). Based on afore introduced authentication of client and server, a secure connection is established that encrypts the data by symmetrical keys negotiated during the key exchange phase. A set of cipher-block chaining (CBC) mode algorithms is supported by SSH.

This channel is used to safely and securely tunnel data between client and server. SSH multiplexes different communications between client and data over the secure connection. It does so by providing a communication protocol, the Secure Shell Connection Protocol, that provides the methods to safely setup (open) and tear down (close) communication channels for tunneling.

Compression

SSH supports compression of payload communicated. Compression is negotiated during the key exchange phase. Compression is direction specific and may differ between the channels client-to-server and server-to-client. It takes place before message authentication codes are calculated and payload is encrypted.

How Consecom AG Supports You

Consecom AG is proven expert in the field of authentication and encryption (references on personal request). Besides SSH-based solutions, Consecom AG designed and implemented communication mechanisms with SmartCard-based authentication and strong encryption methods.

Consecom AG supports you with the analysis of requirements, the design and specification of suitable solution, the implementation and deployment of new authentication and encryption mechanisms as well as with auditing and reviewing of existing solution. Please contact contact@consecom.com for further information.