English French
a key used by the client (resp. server) to authenticate the data that it sends
a key used by the client (resp. server) to encrypt the data that it sends
a key used by the client (resp. server) to initialize the negotiated encryption scheme (if required by this scheme)
Among the various features of the ``ssh`` protocol, it is interesting to mention how users are authenticated by the server. The ``ssh`` protocol supports the classical username/password authentication (but both the username and the password are transmitted over the secure encrypted channel). In addition, ``ssh`` supports two authentication mechanisms that rely on public keys. To use the first one, each user needs to generate his/her own public/private key pair and store the public key on the server. To be authenticated, the user needs to sign a message containing his/her public key by using his/her private key. The server can easily verify the validity of the signature since it already knows the user's public key. The second authentication scheme is designed for hosts that trust each other. Each host has a public/private key pair and stores the public keys of the other hosts that it trusts. This is typically used in environments such as university labs where each user could access any of the available computers. If Alice has logged on ``computer1`` and wants to execute a command on ``computer2``, she can create an ``ssh`` session on this computer and type (again) her password. With the host-based authentication scheme, ``computer1`` signs a message with its private key to confirm that it has already authenticated Alice. ``computer2`` would then accept Alice's session without asking her credentials.
At this point, all the messages sent over the TCP connection will be encrypted with the negotiated keys. The ``ssh`` protocol uses messages that are encoded according to the Binary Packet Protocol defined in :rfc:`4253`. Each of these messages contains the following information :
Authenticating messages with HMAC
compression
encryption
Footnotes
For example, :rfc:`4255` describes a DNS record that can be used to associate an ``ssh`` fingerprint to a DNS name.
For some of the algorithms, it is possible to negotiate the utilization of no algorithm. This happens frequently for the compression algorithm that is not always used. For this, both the client and the server must announce ``null`` in their ordered list of supported algorithms.
From a security viewpoint, the main drawback of :term:`telnet` is that all the information, including the usernames, passwords and commands, is sent in cleartext over a TCP connection. This implies that an eavesdropper could easily capture the passwords used by anyone on an unprotected network. Various software tools exist to automate this collection of information. For this reason, :term:`telnet` is rarely used today to access remote computers. It is usually replaced by :term:`ssh` or similar protocols.
HMAC uses two padding strings : `ipad` (resp. `opad`) which is a string containing 20 times byte ``0x36`` (resp. byte ``0x5C``). The HMAC is then computed as :math:`H[K \oplus opad, H(K \oplus ipad, data) ]` where :math:`\oplus` denotes the bitwise XOR operation. This computation has been shown to be stronger than the naive :math:`H(K,data)` against some types of cryptographic attacks.
In practice, an ``ssh`` implementation supports four types of cryptographic algorithms :
It is common practice among designers of security protocols to never use the same key for different purposes. For example, allowing the client and the server to use the same key to encrypt data could enable an attacker to launch a replay attack by sending to the client data that it has itself encrypted.
key exchange
``length`` : this is the length of the message in bytes, excluding the MAC and length fields
``MAC`` : this field is present if a Message Authentication Code has been negotiated for the session (in practice, using ``ssh`` without authentication is risky and this field should always be present). Note that to compute the MAC, an ``ssh`` implementation must maintain a message counter. This counter is incremented by one every time a message is sent and the MAC is computed with the negotiated authentication algorithm using the MAC key over the concatenation of the message counter and the cleartext message. The message counter is not transmitted, but the recipient can easily recover its value. The ``MAC`` is computed as :math:`mac = MAC(key, sequence\_number || unencrypted\_message)` where the key is the negotiated authentication key.
Message Authentication Code (MAC)
Once the cryptographic algorithms have been negotiated, the key exchange algorithm is used to negotiate a secret key that will be shared by the client and the server. These key exchange algorithms include some variations over the basic algorithms. As an example, let us analyze how the Diffie Hellman key exchange algorithm is used within the ``ssh`` protocol. In this case, each host has both a private and a public key.