SSH secures your data while it passes over a network, but how exactly
does it work ? In this chapter, we move firmly
onto technical ground and explain the inner workings of SSH.
Let's roll up our sleeves and dive into the bits and bytes.
This chapter is written for system administrators, network
administrators, and security professionals. Our goal is to teach you
enough about SSH to make an intelligent, technically sound decision
about using it. We cover the SSH-1 and SSH-2 protocols separately
since they have important differences.
Of course, the ultimate references on SSH
are the protocol standards and the source code of an implementation.
We don't completely analyze the protocols or recapitulate every
step taken by the software. Rather, we summarize them to provide a
solid, technical overview of their operation. If you need more
specifics, you should refer to the standards documents. The SSH
Version 2 protocol is in draft status on the IETF standards track; it
is available at:
The older protocol implemented in SSH1 and OpenSSH/1 is Version 1.5
and is documented in a file named RFC included
in the SSH1 source package.
3.1. Overview of Features
features and guarantees of the SSH protocol are:
Privacy of your data, via strong encryption
Integrity of communications, guaranteeing they
haven't been altered
Authentication, i.e., proof of identity of
senders and receivers
Authorization, i.e., access control to accounts
Forwarding or tunneling to
encrypt other TCP/IP-based sessions
3.1.1. Privacy (Encryption)
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 regularly
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 ARCFOUR, Blowfish, DES, IDEA, and triple-DES (3DES).
Integrity means assuring that data
transmitted from one end of a network connection arrives unaltered on
the other side. 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 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-2 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. SSH-2 uses
keyed hash algorithms based on MD5 and SHA-1 for this purpose: well
known and widely trusted algorithms. SSH-1, on the other hand, uses a
comparatively weak method: a 32-bit cyclic redundancy check (CRC-32)
on the unencrypted data in each packet. [Section 3.9.3, "Hash Functions"]
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
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!
There is difference of opinion as to the granularity of server
authentication: should it be distinguish between different server
hosts, or between individual instances of the SSH server? That is,
must all SSH servers running on a particular host have the same
host key, or might they
have different ones? The term "host key," of course,
reflects a bias towards the first interpretation, which SSH1 and
OpenSSH follow: their known-hosts lists can only associate a single
key with any particular hostname. SSH2, on the other hand, uses the
second approach: "host keys" are actually associated with
individual listening sockets, allowing multiple keys per host. This
may reflect a pragmatic need rather than a considered change in
principle. When SSH2 first appeared, it supported only DSA host keys,
whereas SSH-1 supports only RSA keys. It was therefore impossible, as
a matter of implementation, for a single host to run both SSH-1 and
SSH2 servers and have them share a host key.
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
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
Modules (PAM) system. An SSH client and server negotiate to determine
which authentication mechanism to use, based on their configurations.
SSH2 can even require multiple forms of authentication.
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/sshd_config file for
SSH1), or per account, depending on the authentication method used
(e.g., each user's files
3.1.5. Forwarding ( Tunneling)
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. General TCP
forwarding operates as described earlier for any TCP-based service.
[Section 9.2, "Port Forwarding"] X forwarding comprises additional
features for securing the X protocol (i.e., X windows). [Section 9.3, "X Forwarding"] The third type, agent forwarding, permits SSH clients
to access SSH public keys on remote machines. [Section 6.3.5, "Agent Forwarding"]