Several protocols for remote shell access were created in the 1970s and 80s, when security was not a concern; for example, Telnet in 1969, Remote Shell (rsh) in 1983, and Remote Login (rlogin) a bit later in 1991. These protocols do not have encryption, so the login and password information, as well as any commands launched by the client, are transported clearly along the network.
So anybody could sniff the traffic and read the data. If your network contains hubs, anybody connected to the hub can see all the traffic. For example, Figure 15-1 shows a packet capture of a short Telnet connection.
Tip
A hub and a switch are network devices that connect several computers on a network. Hubs and switches have multiple ports where machines are connected. A switch transmits the incoming data on one port to another port based on the final destination. A hub forwards the data from one port to all of the other ports. Any computer connected to a hub can sniff all the data sent and received by any other computer connected on the same hub. This is why hubs are often banned from corporate networks.
Be careful with switches! Under certain circumstances, a switch can be forced into forwarding packets like a hub. A hacker with Layer 2 access to a switch could mount an attack against the switch by filling up its MAC cache table. This is easily done by injecting packets with spoofed destination MACs into the switch. When the switch's MAC table is full, it will usually start copying packets on all ports out, just like a hub.
The packet capture of a Telnet communication in Figure 15-1 shows how a couple of packets sniffed on a network can compromise the entire network. It reveals the login and password to connect to the machine and to get sudo access, as well as the list of local accounts.
Due to the insecurity of the early remote shell access protocols, the Secure Shell (SSH) protocol was introduced in 1995 to offer secure remote access. SSH provides data encryption, host identification, and data integrity. The first version, SSH-1, had some security issues that were fixed in 1996 with the second protocol revision, SSH-2. SSH-1 should not be used anymore.
SSH also provides additional features such as tunneling (see SSH Advanced Use) and secured file copy (see Remote File Access with SSH).
SSH-2 uses both an asymmetric key (public and private key) and a symmetric key (the same key is used to encrypt and decrypt). The asymmetric keys are used to authenticate the SSH server, and optionally the SSH client, and then to negotiate a symmetric key, called a session key, between the two hosts. The data is encoded with the symmetric key. Encryption and decryption is much faster with a symmetric key than with an asymmetric key.
SSH supports the following algorithms:
The SSH protocol can be decomposed in three layers: the transport layer, the user authentication layer, and the connection layer. Each layer is discussed in the next three sections.
This layer contains the public key exchange and the server authentication. The encryption and the compression algorithms are negotiated, and the session key is generated. This is the first step to initiate an SSH connection. The sequence is as follows:
The client opens a TCP connection to the SSH server.
Client and server negotiate an SSH protocol version (1 or 2).
Warning
Both server and client should be configured to only support SSH-2, because SSH-1 is insecure.
The server sends unencrypted data to the client to identify itself. This includes a list of encryption, compression, and authentication mechanisms that it supports. It also includes a server public key.
The server public key is 64 random bytes, called check bytes, which must be sent back by the client in the next request. This prevents replay attacks where an attacker would capture an SSH connection and replay it several times to create a denial of service (DoS) condition.
Both the client and server create a hash from the server's public key and the check bytes. This hash identifies the session.
Tip
A hash is a small fingerprint. It is often used to fingerprint larger data. A good hash function has a low probability of collisions (i.e., a low probability for two different data chunks to have the same hash).
The client creates a hash or fingerprint of the server's public key. If it is the first time the client connects to the server, the fingerprint and the server IP address are added to the list of known hosts. If it is not the first time, the fingerprint is compared to the fingerprint previously computed for the same IP address. See SSH Authentication for more information on known hosts.
A session key, unique to this SSH session, is created. The key is not exchanged between the client and server. Instead, hints are exchanged and used by both sides to compute the session key. During this step, data is encrypted with the recipient's public key. This allows the client to verify that the server has the matching private key and can fully authenticate it. Diffie-Hellman is used for key exchange. This algorithm allows the two parties to compute the same secret key over an insecure (unencrypted) channel.
The server sends a confirmation encrypted with the new session key.
All data is encrypted with the symmetric session key.
Session keys are usually renewed every hour, or after 1 GB of data has been exchanged.
There are three main mechanisms to authenticate a user with SSH:
- Password
The user enters a login and password. This is natively implemented by the SSH server and independent from the keyboard-interactive method.
- Public key
The user's public key must be present on the server. The client authenticates transparently with its public key (see SSH Authentication). Here are the steps to authenticate:
The SSH client requests authentication of a given user to the server.
If there is a public key on the server in that user's home directory, the server replies with a challenge (random string) encrypted with the client's public key.
The client decrypts the message with its private key, signs the challenge with its public key, and sends the signature back to the server.
The server computes the same signature with the user's public key and compares it to the signature sent by the client. If they match, the user is authenticated.
- Keyboard-interactive
The authentication is not done by the SSH server, but by another module on the server. The SSH is simply an interface between the client and the external module. This is often used with Pluggable Authentication Modules (PAM) to authenticate users who have shell access on the server.
The server defines which mechanisms are supported and in what order they are tried. Commonly, the public key mechanism is tried first, then the keyboard-interactive method.
The benefits of user authentication versus public key authentication are discussed in SSH Authentication.
SSH supports several communication channels per session. Channels are used for port forwarding (see SSH Advanced Use), X forwarding, or to send control commands (e.g., terminal window resizing). This is done transparently.