../../protocols/ssh.rst:9 2

../../protocols/ssh.rst:11

One of the initial motivations for building computer networks was to allow users to access remote computers over the networks. In the 1960s and 1970s, the mainframes and the emerging minicomputers were composed of a central unit and a set of terminals connected through serial lines or modems. The simplest protocol that was designed to access remote computers over a network is probably :term:`telnet` :rfc:`854`. :term:`telnet` runs over TCP and a telnet server listens on port `23` by default. The TCP connection used by telnet is bidirectional, both the client and the server can send data over it. The data exchanged over such a connection is essentially the characters that are typed by the user on the client machine and the text output of the processes running on the server machine with a few exceptions (e.g. control characters, characters to control the terminal like VT-100, ...) . The default character set for telnet is the ASCII character set, but the extensions specified in :rfc:`5198` support the utilization of Unicode characters.

../../protocols/ssh.rst:28 4

../../protocols/ssh.rst:40 5

../../protocols/ssh.rst:46

English

The secure shell protocol was designed in the mid 1990s by T. Ylonen to counter the eavesdropping attacks against :term:`telnet` and similar protocols [Ylonen1996]_. :term:`ssh` became quickly popular and system administrators encouraged its usage. The original version of :term:`ssh` was freely available. After a few years, his author created a company to distribute it commercially, but other programmers continued to develop an open-source version of :term:`ssh` called `OpenSSH <http://www.openssh.com>`_. Over the years, :term:`ssh` evolved and became a flexible applicable whose usage extends beyond remote login to support features such as file transfers, protocol tunneling, ... In this section, we only discuss the basic features of :term:`ssh` and explain how it differs from :term:`telnet`. Entire books have been written to describe :term:`ssh` in details [BS2005]_. An overview of the protocol appeared in [Stallings2009]_.

../../protocols/ssh.rst:62 7

../../protocols/ssh.rst:70 8

../../protocols/ssh.rst:81 9

../../protocols/ssh.rst:84 10

../../protocols/ssh.rst:85 11

../../protocols/ssh.rst:86 12

../../protocols/ssh.rst:87 13

../../protocols/ssh.rst:89 14

../../protocols/ssh.rst:121 15

../../protocols/ssh.rst:131 16

../../protocols/ssh.rst:138 17

../../protocols/ssh.rst:140 18

../../protocols/ssh.rst:148 19

../../protocols/ssh.rst:151

English

This is a slightly modified authenticated Diffie Hellman key exchange with two interesting points. The first point is that when the server authenticates the key exchange it does not provide a certificate. This is because ``ssh`` assumes that the client will store inside its cache the public key of the servers that it uses on a regular basis. This assumption is valid for a protocol like ``ssh`` because users typically use it to interact with a small number of servers, typically a few or a few tens. Storing this information does not require a lot of storage. In practice, most ``ssh`` clients will accept to connect to remote servers without knowing their public key before the connection. In this case, the client issues a warning to the user who can decide to accept or reject the key. This warning can be associated with a fingerprint of the key, either as a sequence of letters or as an ASCII art which can be posted on the web or elsewhere [#fdnsssh]_ by the system administrator of the server. If a client connects to a server whose public key does not match the stored one, a stronger warning is issued because this could indicate a man-in-the-middle attack or that the remote server has been compromised. It can also indicate that the server has been upgraded and that a new key has been generated during this upgrade.

../../protocols/ssh.rst:173

English

The second point is that the server authenticates not only the result of the Diffie Hellman exchange but also a hash of all the information sent and received during the exchange. This is important to prevent `downgrade attacks`. A `downgrade attack` is an attack where an active attacker modifies the messages sent by the communicating hosts (typically the client) to request the utilization of weaker encryption algorithms. Consider a client that supports two encryption schemes. The preferred one uses 128 bits secret keys and the second one is an old encryption scheme that uses 48 bits keys. This second algorithm is kept for backward compatibility with older implementations. If an attacker can remove the preferred algorithm from the list of encryption algorithms supported by the client, he can force the server to use a weaker encryption scheme that will be easier to break. Thanks to the hash that covers all the messages exchanged by the server, the downgrade attack cannot occur against ``ssh``. Algorithm agility is a key requirement for security protocols that need to evolve when encryption algorithms are broken by researchers. This agility cannot be used without care and signing a hash of all the messages exchanged is a technique that is frequently used to prevent downgrade attacks.