SSH Features

The SSH protocol ensures that all communication over the network is secure through the following safeguards:

1. Encryption of data during transmission to protect privacy

   Data exchanged between hosts need protection from disclosure, especially since anybody with access to the network hardware or to hosts connected to the network may be able to read the transmitted data using sniffer programs. SSH provides a secure connection by encrypting all traffic travelling through the network.

2. Prevention of data corruption, whether deliberate or otherwise, through integrity checking

   Although TCP/IP has mechanisms for checking data corruption due to network problems (e.g. noise, dropped packets), it does not protect against intentional data tampering, such as what happens in a replay attack.

   SSH uses what are known as keyed hash algorithms to ward against data alteration. The SSH-2 protocol uses cryptographic integrity checking based on MD5 and SHA-1, to check that no tampering has occurred as well as to verify that the data is truly coming from the other end of the connection and not from another source (see IP spoofing). On the other hand, SSH-1 uses the weaker CRC-32 (for cyclic redundancy check), which can be thwarted by certain cleverly staged insertion attacks.

3. Authentication of users and hosts to prevent unauthorized logins/connections

   SSH implements different authentication methods to verify the identity of users and SSH servers. User authentication is performed to prevent people from masquerading as legitimate users on a machine. By the same token, server authentication guards against situations whereby the connection is redirected to a different host on the network, in what is known as IP spoofing. Authentication of the server could be fine-grained, as in the case of the SSH-1 protocol which can authenticate different SSH servers running on the same host. Or it could be coarse-grained, whereby the authenticity of the host running the SSH server is checked, as implemented in SSH-2.

   The authentication of the user and server can take many forms, and is discussed in more detail in the section "How SSH works" of the TACC Introduction to SSH webpage.

4. Authorization or controlling access and privileges

   Authorization involves restricting access to SSH services like login sessions, TCP port forwarding, agent forwarding, etc. Control can be implemented at the account level, e.g. through the file $HOME/.ssh/config or at the server level using a system-wide configuration file (e.g. in Linux, this resides in /etc/ssh/ssh_config for SSH2).

5. Protection of other TCP/IP sessions through tunneling or forwarding

   Other TCP-based services such as ftp and news service can be encapsulated within a SSH session, and thus benefit from the previously discussed security features like privacy protection, integrity checking, authentication, and authorization. The SSH protocol implements three types of forwarding: port, X, and agent forwarding.

---

Components of SSH

• Server

  A program that allows incoming SSH connections, handling authentication, authorization, etc. In most Unix SSH implementations, the server is sshd.

• Client

  A program that connects to SSH servers and makes requests, such as login connections, file transfers, etc. In SSH1 and SSH2, examples of clients are ssh, scp, and sftp.

• Session

  An ongoing connection between a client and a server, may be interactive or in batch mode. It begins after the client successfully authenticates to a server and ends when the connection terminates.

• Key

  A relatively small amount of data used as a parameter to cryptographic algorithms such as encryption or message authentication. The use of the key binds the algorithm operation in some way to the key holder: in encryption, it ensures that only someone else holding that key (or a related one) can decrypt the message; in authentication, it allows verification that the key-holder actually signed the message. There are two kinds of keys: symmetric or secret-key, and asymmetric or public-key. Refer to the Cryptography Primer for an explanation of these terms.

  SSH uses four types of keys: user key, session key, server key, host key.

• User key

  A persistent, asymmetric key used by clients as proof of a user's identity.

• Session key

  A randomly generated, symmetric key for encrypting the communication between the SSH client and server. It is shared by the two parties in a secure manner during the SSH connection setup, so that an eavesdropper cannot discover it. Both sides then have the session key, which they use to encrypt all communication. The key is destroyed when the session ends.

• Server key

  A temporary, asymmetric key used in the SSH-1 protocol. It is regenerated by the server at regular intervals (by default every hour) and protects the session key. Often confused with the host key. This key is never explicitly stored on disk, and its private component is never transmitted over the connection in any form; it provides perfect forward secrecy for SSH-1 sessions.

• Host key

  A persistent, asymmetric key used by a server as proof of its identity, as well as by a client when providing its host's identity as part of trusted-host authentication. If a machine runs a single SSH server, the host key also uniquely identifies the machine. If a machine is running multiple servers, each may have a different host key or they may share. Often confused with the server key.

• Key generator

  A program that creates persistent keys (user keys and host keys) for SSH, SSH1 and SSH2 has the program ssh-keygen.

• Known hosts database

  A collection of host keys. Clients and servers refer to this database to authenticate one another.

• Agent

  A program that caches user keys in memory, so users need not retype their passphrases. The agent responds to requests for key-related operations, such as signing an authenticator, but it doesn't disclose the keys themselves. It is a convenience feature. SSH1 and SSH2 have the agent ssh-agent, and the program ssh-add loads and unloads the key cache.

• Signer

  A program that signs hostbased authentication packets.

• Random seed

  A pool of random data used by SSH components to initialize software pseudorandom number generators.

• Configuration file

  A collection of settings to tailor the behavior of a SSH client or server.

Not all these features are included in a SSH implementation. Certainly servers, clients, and keys are mandatory, but many implementations don't have an agent, and some don't even have a key generator.

---

How Secure Shell Works

The discussions in this section presumes knowledge of very basic cryptography concepts and the different components of the SSH architecture.

In very general terms, request of a service from a remote host (e.g. login connection, execution of commands, file transfers) using SSH can be divided into two broad parts:

1. Establishment of a secure connection between the SSH client and server

   A secure connection needs to be set up prior to any type of meaningful communication between two hosts. Two necessary conditions have to be satisfied in order to achieve this: encryption of all network traffic involving the SSH client and server; and integrity protection of the data exchanged between the two hosts.

   An encrypted connection is necessary to protect security sensitive information i(e.g. password) from being detected by a network snoop. However, this precaution alone will not foil all types of security intrusions. For instance, so-called replay and insertion attacks can still be be mounted against encrypted sessions if no checks are in place to protect against tampering during data transmission.

   Without going into too much detail, several processes take place during the establishment of a secure connection. They are outlined as follows:

   1. The SSH client contacts the server
   2. Both client and server disclose the SSH protocol versions they support
   3. The remote host identifies itself to the SSH client by sending the following data, unencrypted:
      1. The remote host's public key (a discussion of public-key cryptography will follow in the next section)
      2. In the case of SSH1, the public key for the SSH server (note that there might be more than one SSH server for a given host)
      3. A sequence of random bytes called check bytes, to foil against IP spoofing. The client must then include these in its next response or the connection request will be rejected.
      4. A list of encryption, compression, and authentication methods supported by the SSH server. Both sides then compute and exchange what is known as a session identifier, a common 128-bit session identifier which is a MD5 hash of the host key, server key, and check bytes taken together. The client checks the host public key against $HOME/.ssh/known_hosts and /etc/known_hosts.
   4. A bulk cipher is generated for the session. Known as the session key, its purpose is to encrypt and decrypt all data exchanged between client and server. In addition, the session key plays an important role in guarding against replay attacks during the user or host authentication phase.

      The generation of the session key varies according to whether SSH-1 or SSH-2 is followed. Under the SSH-1 protocol, the client formulates the session key, encrypts it twice with the host public key and the server key (in what is known as perfect forward secrecy), and sends it to the server. SSH2 has a different key- exchange procedure, in which both client and server produce a shared secret that is input to another process which generates the session key. Thus, neither side can fully determine the session key as an additional precaution. And unlike in the SSH-1 protocol, a server key is not necessary in SSH-2 to produce the session key.

      In SSH1, only one session key is used throughout the SSH session, however long the session takes. Potentially, this gives the cryptanalyst more data encrypted with the same key, and hence greatly increases the chances of the key being discovered. SSH-2 on the other hand, allows for session-rekeying, whereby a new session key is generated as agreed upon by both client and server.

   5. The server sends the client a confirmation message encrypted with the session key.
   6. The secure connection is established between client and server. All succeeding communication will henceforth be encrypted and decrypted using the session key.
2. Authentication of the client to the server

   After the secure connection is set, the client attempts to authenticate itself to the server using any of the following methods until one succeeds:

   Under the SSH-1 protocol, six authentication methods are tried in the following order:

   1. Kerberos
   2. Rhosts
   3. RhostsRSA
   4. Public-Key
   5. TIS
   6. User password

   while the SSH-2 protocol only supports three:

   1. Public-key
   2. RhostsRSA
   3. User password

   Both Kerberos and TIS are not available by default but rather must be specified prior to building the SSH client on the local machine.

3. Rhosts and RhostsRSA authentication

   Hostbased authentication methods like Rhosts or RhostsRSA rely on trust relationships between hosts. To authenticate user Alice, say, connecting from machine A, the SSH server does not directly verify Alice's identity. Rather, it checks the identity of the local machine and makes a determination of whether A is trusted or not. Furthermore, the SSH server ensures that the SSH client program is trusted, in the sense that only somebody with root privileges can install the program, and that the SSH client will honestly vouch for Alice's identity on the local machine. If both the local host and the SSH client program pass the "trustworthiness" test, then Alice is allowed to connect.

   The SSH server relies on the concept of a privileged port in UNIX to verify that the SSH client is trusted. Essentially, ports 1-1023 are reserved by UNIX-based TCP and UDP stacks for processes running as root to listen on or use on the local side of a connection. If the source port of the SSH client program is within this range of privileged ports, this provides verification to the SSH server that the connection is being initiated by a trusted client program.

   There are two mechanisms in SSH1 for determining the trustworthiness of a remote host. The Rhosts mechanism, in use for years by the "r" commands rsh, rcp, rlogin, relies on the following steps to authenticate the host on the client-side:

   1. Use of the concept of privileged ports to verify that the SSH client is a trusted program
   2. The presence of a .rhosts file in the user's home directory on the remote host
   3. An entry in .rhosts containing the client-side host and the user name on the client host which is to be allowed access

   The weakness of this authentication method cannot be overemphasized, and its vulnerability to IP spoofing and subversion of the DNS renders it infeasible to use as the sole means of SSH authentication. Not to mention the fact that privileged ports are practically meaningless on desktop PC systems, where ordinary users can have superuser privileges.

   The second mechanism, which involves the use of asymmetric keys or public-key cryptography, is employed by RhostsRSA. In a nutshell, public- key cryptography uses two separate keys, a public key for encryption and a private one for decrypting messages encrypted with the public key.

   During the establishment of a secure connection, the server sends the client its host key and in the case of SSH-1, its server key as well. As a first check, the SSH client looks for an entry in its .ssh/known_hosts corresponding to the server host's public key. If the entry is not found, then the user is prompted whether to add the host key in the known_hosts file of the SSH server. A more frightening message is displayed when the entry in the known_hosts file does not match the host's public key. In such an event, the user is cautioned about a possible man-in-the-middle attack and is prompted as to whether to continue notwothstanding. Should the user decide to ignore the message, the client begins to authenticate the server host by first sending a challenge, that is, a message encrypted by the server's public key. The server decrypts the message with its private key, adds the session key to bind the message with the current session as a measure against replay attacks, uses a hashing function on the result, and sends this reply (called the "authenticator") back to the remote host. At the other end, the client also performs a hash on the combined original message and session key. Authentication of the server follows if the result of the hash and the authenticator match.

4. Public-key authentication of the user

   SSH1 falls back on RSA authentication of the user should Rhosts and RhostsRSA fail. This is in contrast with the SSH-2 protocol which performs public-key authentication of the user prior to resorting to a trusted hosts mechanism. Furthermore, SSH2 supports more protocols, not just RSA-based, to authenticate the user using public-key cryptography.

   The SSH server authenticates the user using public-key cryptography if and only if the user's public key is included as an entry in the .ssh/authorized_keys file (if using SSH1) or .ssh/authorized_keys2 file (if using SSH2) on the server. It follows more or less the same procedure as described in the RSAhosts mechanism:

   1. User sends the SSH server his/her public key
   2. Server sends a challenge to the user, encrypted with the user's public key
   3. User decrypts message, adds the session key, and performs a hash on the result. This value is sent to the server as an authenticator
   4. The server also calculates the hash value of the combined message and session key, and compares the result to the authenticator
   5. User is authenticated to the server if authenticator and server- calculated hash match
5. Password authentication of the user

   If all other authentication methods fail, the user is prompted by the SSH server for his/her password on the remote machine. Because the password is transmitted to the remote host in encrypted form, this option is much safer than the equivalent procedure in telnet whereby the plaintext password is transmitted in the clear. However, the public-key authentication is safer still because no password (or passphrase as will be seen later) is sent across the network.

---

Attacks SSH Protects Against

The following is a list of security threats that SSH renders ineffective:

1. Eavesdropping

   This refers to the process of listening in on the network using sniffer programs without detection. Theoretically, any person with access to the switch hardware or to a host connected to the network can read the traffic over that network without affecting the data. Encryption of the SSH session thwarts any attempts at eavesdropping or interception of network traffic.

2. Connection Hijacking

   In some instances, an eavesdropper can not only listen in but also insert his/her own packets over the wire to the intended destination, thus "hijacking" the connection from one end of the SSH session. SSH by itself is powerless against connection hijacking as this represents a weakness in the underlying TCP layer. Secure authentication is likewise ineffective, since the hijacker can always wait until the SSH session is established to mount an attack. SSH's integrity checking mechanism however, can easily detect modifications made to the transmitted data and closes the connection in such an event.

3. Name Service and IP Spoofing

   An attacker can impersonate a host two ways: by subverting the name service (e.g. DNS, NIS, etc.) or stealing the use of the host's IP address. The consequences can be disastrous: a user might connect to the wrong SSH server and have his/her password stolen in the process, if password authentication is used to validate the user. The SSH client is able to detect this in the process of host authentication, whereby the server host key is compared against a list of known hosts, their addresses, and corresponding keys. If the key so provided conflicts with a previous entry, then SSH issues a warning message.

4. Insertion and Replay Attacks

   Frequently, a snoop not only monitors the network connection, but actively observes keyboard activity, possibly through software that captures keystrokes. By comparing what is typed with the session byte stream, an attacker can identify the packet that contains a given command (e.g. "rm"). In a "replay" or insertion attack, the packet is re-sent during the session in order to execute or "replay" the command at a later time. Similar to connection hijacking, insertion attacks involve introduction of extraneous data into the network traffic. But unlike in the former case, data is inserted into the plaintext stream destined towards the client or server. This spurious addition is encrypted along with the legitimate data, and is designed to decrypt to the attacker's intended message. The attack itself is hard to mount, but it highlights a serious vulnerability in the CRC-32 integrity checking mechanism employed by SSH1. Fortunately, SSH2's stronger integrity checking renders it immune to insertion attacks.

5. "Man-in-the-Middle" Attacks

   In a "man-in-the-middle" attack, the interloper literally sits in the middle of a SSH connection between client and server, and is thus in a position to intercept messages and maybe add and delete transmitted data deliberately.

   A SSH connection could be intercepted by a malicious intruder, the so-called "man-in-the-middle". At one end, the SSH client could use password authentication to validate the user to the bogus SSH server operated by the attacker, giving away the user password in the process. With the password in hand, the intruder can then connect to the intended SSH server as the user. All of this is unbeknownst to the user and SSH server, both under the blithe assumption that they are connected to each other. At will, the attacker can both read and modify all transmitted messages because he/she shares separate session keys with both the user and the SSH server.

   This scenario is prevented by the host authentication mechanism in SSH (see a detailed description of this on the How SSH Works section). When the SSH client connects to the server, the server validates itself to the client by RSA authentication. Thus, the connection is allowed only if the server can demonstrate to the client that it has the correct private host key, insofar as its public host key is among those listed in the clients known_hosts file. So the only way the attacker can impersonate the SSH server is if he/she breaks into the server machine itself. Conceivably, the attack could still succeed if the known_hosts file on the client side does not contain an entry for the SSH server's public host key, as what happens during the first time a connection to the server is requested (or when the server host key changes in which case stern warning messages are issued by the client). Provided the private server host key is not stolen, the initial connection to the server compromised, or if a user terminates all subsequent connections whenever the "man-in-the-middle-attack" warnings are issued, then a man-in-the-middle attack is rendered ineffective.

   Another protection conferred by SSH is the use of the public-key authentication mechanism. To perform real damage, an attacker needs to capture the session key to be able to decrypt the communication between the SSH client and server. However, this is infeasible to do for two reasons:

   1. The Diffie-Hellman-group1-sha1 key-exchange mechanism in SSH2 is arranged in such a way as to ensure that neither the server nor the client "knows" the real key, but has shared knowledge of it. Thus, no session key is transmitted through the network.
   2. In SSH1, the server key is formulated by the client and sent to the server, but the key is double encrypted with the server public host key and the server key (in what is known as perfect- forward secrecy). Unless the intruder possesses both the server private host key and server key, the session key is invulnerable to detection.

   Public-key authentication also precludes the possibility of an attacker establishing separate connections to both client and server. At best, two keys can be obtained in this scenario, each corresponding to a separate SSH session. To connect to the server as the client, the attacker must authenticate himself/herself using trusted-host and public- key mechanisms. Both involve the transmission of data containing a session identifier (which binds the message uniquely to each SSH session) and signed with the session key. As a result, the attacker just can't forward the client-supplied authenticator to the server, as this authenticator was constructed with a different set of session key and identifier.

---

Attacks SSH Doesn't Protect Against

1. Password detection/guessing

   As mentioned in the previous section, a user's password is vulnerable to capture in a "man-in-the-middle" attack, because it is transmitted over the network. This threat can be easily prevented by using the more secure public-key authentication instead. This mechanism makes it doubly hard for a user's identity to be stolen, since both passphrase and private key are required by an attacker to break into a user's account.

   Another threat is posed by passwords that are easily guessed. Attackers often resort to what is known as a "dictionary attack" to crack passwords that are made up of words that can be looked up in a dictionary. The obvious countermeasure is to devise a memorable, but hard-to-guess password that is known only to the user and no one else.

2. IP and TCP attacks

   The fact that SSH works on top of TCP and IP renders it vulnerable to attacks that exploit weaknesses in these protocols. These security threats operate at the network-level and can lead to unpleasant side effects like denial of service, routing of sensitive data to unintended destinations, insertion of arbitrary information, etc. Fortunately, SSH can detect attacks involving alteration of TCP data (see insertion attack in the last section), or routing of TCP connections to other systems which are compromised (see "man-in-the-middle", IP spoofing, and connection hijacking attacks). However, SSH is powerless against attacks that prevent TCP connections from being setup properly. Only lower-level techniques like IPSEC (a security add-on to the IP standard) can thwart these threats that occur at the TCP/IP level.

3. Traffic analysis

   Plenty of useful information is available to the observer of network traffic even if that observer cannot read any of the transmitted data. Volume, as well as source and destination addresses can divulge important clues. For instance, a periodic increase or decrease in network activity at particular times might indicate some maintenance schedule (e.g. backups, system downtimes) that will provide the best (or worst) opportunity for launching a denial-of-service attack. Similarly, a quiescent state can signal the best time for performing a system break-in as it might be an indicator the system administrator is not busy.

   One way of thwarting network traffic analysis, and thus prevent correlation of activity, is to ensure a more or less constant volume of traffic even when the network is otherwise inactive. Unfortunately, there is nothing within the SSH framework that will render monitoring of network activity ineffective.

4. Compromise of root account

   Once an attacker has gained foothold on a system as root, there is nothing preventing the attacker from subverting SSH itself.

---

References

1. The official SSH site can be found at www.ssh.com. It has an FAQ and download sites for SSH-client and server programs on multiple platforms.
2. A very informative SSH FAQ page can be found here. The section on "Getting Secure Shell" has a comprehensive list of free and commercial downloads of SSH for different platforms.
3. "SSH The Secure Shell The Definitive Guide", by Barrett and Silverman (published by O'Reilly books).
4. A very basic introduction to cryptography is available on this page.