Even if the exchanged information does not have a high security level, the hacker obtains access to an account on the remote machine and can possibly escalate his privileges on the machine to obtain root access.
Given that it is impossiblie to control all physical infrastructures located between the user and the remote machine (the Internet being an open network by definition), the only solution is to rely on security at the logical level (at the data level).
The SSH (Secure Shell) protocol is a response to this problem in that it enables users (or TCP/IP services) to access a machine via an encrypted communication (called a tunnel).
The SSH (Secure Shell) protocol was developed in 1995 by Tatu Ylönen, from Finland.
It is a protocol that makes it possible for a client (a user or even a machine) to open an interactive session on a remote machine (server) to send commands or files over a secure channel:
The goal of version 1 of the protocol (SSH1), which was proposed in 1995, was to offer an alternative to interactive sessions (shells) such as Telnet, rsh, rlogin and rexec. Yet this protocol had a flaw that enabled hackers to insert data in encrypted flows. This is why version 2 of the protocol (SSH2) was proposed in 1997 as a draft to the IETF. The documents defining the protocol can be accessed online at http://www.ietf.org/html.charters/secsh-charter.html.
Secure Shell Version 2 also includes a Secure File Transfer Protocol (SFTP).
SSH is a protocol, that is, a standard method enabling machines to establish a secure connection. As such, there are a variety of SSH client and server implementations. Some require a fee, while others are free or open source: you will find a certain number of SSH clients in the downloading section of CommentCaMarche.
An SSH connection is established in several phases:
The establishment of a secure transport layer starts with a negotation phase between the client and server so they can agree on the encryption methods they want to use. The SSH protocol is designed to work with a large number of encryption algorithms, which is why the client and server must first exchange the algorithms they support.
Next, to establish a secure connection, the server sends its host key to the client. The client generates a 256-bit session key it encrypts with the server's public key, and sends the server the encrypted session key as well as the algorithm used. The server decrypts the session key with its private key and sends a confirmation message encrypted with the session key. After this point, the remaining communications are encrypted thanks to a symmetric encryption algorithm using the session key shared by the client and the server.
The transaction's security is based on the client and server's confidence that the other party's host keys are valid. As such, when first connecting to a server, the client generally displays a message asking to accept the connection (and possibly presents a hash of the server's host key):
Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)?In order to obtain a truly secure session, it is best to verbally ask the server's administrator to validate the public key presented. If the user validates the connection, the client saves the server's host key to keep from having to repeat this phase.
Conversely, depending on its configuration, the server can sometimes verify that the client is who it claims to be. If the server has a list of hosts authorized to connect, it will encrypt a message using the client's public key (which it has in its host key database) to verify whether the client is capable of decrypting it with its private key (this is called a challenge).
Once the secure connection is established between the client and the server, the client has to log on to the server to obtain an access right. There are several methods: