Translation

English
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.
0/5090 · 509
English French Actions
Remote login Connexion à distance
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.
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.
The secure shell (ssh)
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]_.
The :term:`ssh` protocol runs directly above the TCP protocol. Once the TCP bytestream has been established, the client and the server exchange messages. The first message exchanged is an ASCII line that announces the version of the protocol and the version of the software implementation used by the client and the server. These two lines are useful when debugging interoperability problems and other issues.
The next message is the ``SSH_MSG_KEX_INIT`` message that is used to negotiate the cryptographic algorithms that will be used for the ``ssh`` session. It is very important for security protocols to include mechanisms that enable a negotiation of the cryptographic algorithms that are used. First, these algorithms provide different levels of security. Some algorithms might be considered totally secure and are recommended today while they could become deprecated a few years later after the publication of some attacks. Second, these algorithms provide different levels of performance and have different CPU and memory impacts.
In practice, an ``ssh`` implementation supports four types of cryptographic algorithms :
key exchange
encryption
Message Authentication Code (MAC)
compression
The IANA_ maintains a `list of the cryptographic algorithms <http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-16>`_ that can be used by ``ssh`` implementations. For each type of algorithm, the client provides an ordered list of the algorithms that it supports and agrees to use. The server compares the received list with its own list. The outcome of the negotiation is a set of four algorithms [#fnull]_ that will be combined for this session.
This negotiation of the cryptographic algorithms allows the implementations to evolve when new algorithms are proposed. If a client is upgraded, it can announce a new algorithm as its preferred one even if the server is not yet upgraded.
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.
the client generates the random number :math:`a` and sends :math:`A=g^{a} \mod p` to the server
the server generates the random number :math:`b`. It then computes :math:`B=g^{b} \mod p`, :math:`K=B^{a} \mod p` and signs with its private key :math:`hash(V_{Client} || V_{Server} || KEX\_INIT_{Client} || KEX\_INIT_{Server} || Server_{pub} || A || B || K )` where :math:`V_{Server}` (resp. :math:`V_{Client}`) is the initial messages sent by the client (resp. server), :math:`KEX\_INIT_{Client}` (resp. :math:`KEX\_INIT_{Server}`) is the key exchange message sent by the client (resp. server) and :math:`A`, :math:`B` and :math:`K` are the messages of the Diffie Hellman key exchange
the client can recompute :math:`K=A^{b} \mod p` and verify the signature provided by the server

Loading…

User avatar None

New source string

cnp3-ebook / protocols/ssh — French

New source string 3 years ago
Browse all component changes

Glossary

English French
No related strings found in the glossary.

String information

Source string location
../../protocols/ssh.rst:28
String age
3 years ago
Source string age
3 years ago
Translation file
locale/fr/LC_MESSAGES/protocols/ssh.po, string 3