Privacy means protecting data from disclosure. Typical computer networks don’t guarantee privacy ; anyone with access to the network hardware, or to hosts connected to the network, may be able to read (or sniff) all data passing over the network. Although modern switched networks have reduced this problem in local area networks, it is still a serious issue; passwords are easily stolen by such sniffing attacks.

SSH provides privacy by encrypting data that passes over the network. This end-to-end encryption is based on random keys that are securely negotiated for that session and then destroyed when the session is over. SSH supports a variety of encryption algorithms for session data, including such standard ciphers as AES, ARCFOUR, Blowfish, Twofish, IDEA, DES, and triple-DES (3DES).

Integrity means assuring that data transmitted from one end of a network connection arrives unaltered on the other end. The underlying transport of SSH, TCP/IP, does have integrity checking to detect alteration due to network problems (electrical noise, lost packets due to excessive traffic, etc.). Nevertheless, these methods are ineffective against deliberate tampering and can be fooled by a clever attacker. Even though SSH encrypts the data stream so that an attacker can’t easily change selected parts to achieve a specific result, TCP/IP’s integrity checking alone can’t prevent, say, an attacker’s deliberate injection of garbage into your session.

A more complex example is a replay attack. Imagine that Attila the Attacker is monitoring your SSH session and also simultaneously watching over your shoulder (either physically, or by monitoring your keystrokes at your terminal). In the course of your work, Attila sees you type the command rm -rf * within a small directory. He can’t read the encrypted SSH session data, of course, but he could correlate a burst of activity on that connection with your typing the command, and capture the packets containing the encrypted version of your command. Later, when you’re working in your home directory, Attila inserts the captured bits into your SSH session, and your terminal mysteriously erases all your files!

Attila’s replay attack succeeds because the packets he inserted are valid; he could not have produced them himself (due to the encryption), but he can copy and replay them later. TCP/IP’s integrity check is performed only on a per-packet basis, so it can’t detect Attila’s attack. Clearly, the integrity check must apply to the data stream as a whole, ensuring that the bits arrive as they were sent: in order and with no duplication.

The SSH protocol uses cryptographic integrity checking, which verifies both that transmitted data hasn’t been altered and that it truly comes from the other end of the connection. It uses keyed hash algorithms based on MD5 and SHA-1 for this purpose: well-known, widely trusted algorithms.

Authentication means verifying someone’s identity. Suppose I claim to be Richard Silverman, and you want to authenticate that claim. If not much is at stake, you might just take my word for it. If you’re a little concerned, you might ask for my driver’s license or other photo ID. If you’re a bank officer deciding whether to open a safe-deposit box for me, you might also require that I possess a physical key, and so on. It all depends on how sure you want to be. The arsenal of high-tech authentication techniques is growing constantly and includes DNA-testing microchips, retina and hand scanners, and voice-print analyzers.

Every SSH connection involves two authentications: the client verifies the identity of the SSH server (server authentication ), and the server verifies the identity of the user requesting access (user authentication ). Server authentication ensures that the SSH server is genuine, not an impostor, guarding against an attacker’s redirecting your network connection to a different machine. Server authentication also protects against man-in-the-middle attacks, wherein the attacker sits invisibly between you and the server, pretending to be the client on one side and the server on the other, fooling both sides and reading all your traffic in the process!

User authentication is traditionally done with passwords, which unfortunately are a weak authentication scheme. To prove your identity you have to reveal the password, exposing it to possible theft. Additionally, in order to remember a password, people are likely to keep it short and meaningful, which makes the password easier for third parties to guess. For longer passwords, some people choose words or sentences in their native languages, and these passwords are likely to be crackable. From the standpoint of information theory, grammatical sentences contain little real information (technically known as entropy): generally less than two bits per character in English text, far less than the 8 -16 bits per character found in computer encodings.

SSH supports authentication by password, encrypting the password as it travels over the network. This is a vast improvement over other common remote-access protocols (Telnet, FTP) which generally send your password in the clear (i.e., unencrypted) over the network, where anyone with sufficient network access can steal it! Nevertheless, it’s still only simple password authentication, so SSH provides other stronger and more manageable mechanisms: per-user public-key signatures, and an improved rlogin-style authentication with host identity verified by public key. In addition, various SSH implementations support some other systems, including Kerberos, RSA Security’s SecurID tokens, S/Key one-time passwords, and the Pluggable Authentication Modules (PAM) system. An SSH client and server negotiate to determine which authentication mechanism to use, based on their configurations, and a server can even require multiple forms of authentication.

Authorization means deciding what someone may or may not do. It occurs after authentication, since you can’t grant someone privileges until you know who she is. SSH servers have various ways of restricting clients’ actions. Access to interactive login sessions, TCP port and X Window forwarding , key agent forwarding, etc., can all be controlled, though not all these features are available in all SSH implementations, and they aren’t always as general or flexible as you might want. Authorization may be controlled at a serverwide level (e.g., the /etc/ssh/sshd_config file for OpenSSH), or per account, depending on the authentication method used (e.g., each user’s files ~/.ssh/authorized_keys, ~/.ssh2/authorization , ~/.shosts, ~/.k5login, etc.).

Forwarding or tunneling means encapsulating another TCP-based service, such as Telnet or IMAP, within an SSH session. This brings the security benefits of SSH (privacy, integrity, authentication, authorization) to other TCP-based services. For example, an ordinary Telnet connection transmits your username, password, and the rest of your login session in the clear. By forwarding telnet through SSH, all of this data is automatically encrypted and integrity-checked, and you may authenticate using SSH credentials.

SSH supports three types of forwarding:

From these basic facilities, some SSH products build more complex services, such as SOCKS proxies and special-purpose forwarders that can handle difficult protocols like FTP.