The Architecture of an SSH System

SSH has about a dozen distinct, interacting components that produce the features we’ve covered. [3.1] Figure 3-1 illustrates the major components and their relationships to one another.

SSH architecture

Figure 3-1. SSH architecture

By “component” we don’t necessarily mean “program”: SSH also has keys, sessions, and other fun things. In this section we provide a brief overview of all the components, so you can begin to get the big picture of SSH:

Server

A program that allows incoming SSH connections to a machine, handling authentication, authorization, and so forth. In most Unix SSH implementations, the server is sshd.

Client

A program that connects to SSH servers and makes requests, such as “log me in” or “copy this file.” In OpenSSH and Tectia, the major clients are ssh, scp, and sftp.

Session

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

Key

A relatively small amount of data, generally from tens of to 1,000 or 2,000 bits, used as a parameter to cryptographic algorithms such as encryption or message authentication. 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 you to verify later that the key holder actually signed the message. There are two kinds of keys : symmetric or secret key, and asymmetric or public key. [3.2.2] An asymmetric key has two parts: the public and private components. SSH has several types of keys, as summarized in Table 3-1.

Table 3-1. Keys, keys, keys

Name

Lifetime

Created by

Type

Purpose

User key

Persistent

User

Public

Identify a user to the server

Host key

Persistent

Administrator

Public

Identify a server/machine

Session key

One session

Client (and server)

Secret

Protect communications

User key

A persistent, asymmetric key used by clients as proof of a user’s identity. (A single user may have many keys/identities.)

Host key

A persistent, asymmetric key used by a server as proof of its identity, as well as by a client when proving its host’s identity as part of hostbased authentication. [3.4.3.6] If a machine runs a single SSH server, the host key also uniquely identifies the machine. (If a machine is running multiple SSH servers, each may have a different host key, or they may share.)

Session key

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

Tip

An SSH connection has several session keys: each direction (server to client, and client to server) has keys for encryption and others for integrity checking. In our discussions we treat all the session keys as a unit and speak of “the session key” for convenience; they are all derived from a single master secret, anyway. If the context requires it, we identify the individual key we mean.

Key generator

A program that creates persistent keys (user keys and host keys) for SSH. OpenSSH and Tectia have 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 needn’t keep retyping 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. OpenSSH and Tectia have the agent ssh-agent, and the program ssh-add loads and unloads the key cache.

Signer

A program that signs hostbased authentication packets. We explain this in our discussion of hostbased authentication. [3.4.3.6]

Random seed

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

Configuration file

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

Not all these components are required in an implementation of SSH. Certainly servers, clients, and keys are mandatory, but many implementations don’t have an agent, and some don’t even include a key generator.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.221.187.121