This
section provides a brief overview of the client and server communication
process. For a detailed description, refer to the book recommended
in the Preface.
After the system manager installs and configures the SSH software
on all client and server hosts, the system manager (and perhaps
the user) customizes authentication methods on the clients and server,
creates and distributes key files, and uses TCP/IP commands to start
the SSH client and server.
During SSH client and server configuration, two configuration
files are installed: a client configuration file, which is read
by an SSH client process when the SSH command is invoked, and the
server configuration file, which is read by an SSH server process
when a connection request arrives from an SSH client. All configuration
files are
ASCII text files and have either STREAM_LF format (for
example, if copied directly from a UNIX® system), or variable-length
format (if
created with the TCPIP$CONFIG.COM command procedure or
with a text editor). Appendix B shows the SSH client and server
configuration files.
When the TCP/IP auxiliary server (inetd) starts on an SSH server host, it creates a listening
socket for SSH. The server is now ready to accept a remote connection
request. When you execute an SSH command on a remote client host,
the SSH client is initiated. The client reads the configuration
file and initiates a TCP connection to a server host using the specified
destination port. On an SSH server host, inetd creates a copy of the server process, which reads the
server's configuration file.
To establish a secure connection:
The SSH client
and server exchange information about supported protocol versions.
This enables different implementations to overcome incompatibilities.
The SSH server initiates
a host public key exchange with the client to prove its identity.
Each server host has a public and private key pair, which is created
during the SSH server configuration. This pair uniquely identifies
the server host. The first time an SSH client connects to a server,
SSH prompts the user to accept a copy of the server's public host
key with the following message: Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no) (Note that the user response is case sensitive. Be sure to
enter the response in lowercase letters.)
If the user response is yes, SSH copies the server's public host
key to the SSH client host. The client host uses this public host
key to authenticate the SSH server on subsequent connections.
If during subsequent connection attempts the SSH
client detects that the SSH server's host key differs from
the one stored on the client, the following message is displayed:WARNING: HOST IDENTIFICATION HAS CHANGED!...The message continues with text that warns of a possible "man-in-the-middle" attack.
Although this message may not mean that data has been compromised
(the host key may have been legitimately changed), the user should
copy the server's new key or contact the system manager.
The SSH client and server
negotiate session parameters by exchanging information about supported parameters,
including authentication methods, hash functions, and data compression
methods.
The SSH client and server
develop a shared (symmetric) session key to encrypt data using a
key exchange method. When both the client and server know the secret
data encryption key, a secure connection is established and the
client and server can exchange data securely. The session key expires
when the session ends.
After the SSH client and
server authenticate each other, the session is ready to authenticate
the user by applying one or more of the authentication methods.
Then SSH verifies the user's identity. The user or the system manager
on the client, and the system manager on the server coordinate authentication methods
by modifying information in the client and server configuration
files.
The SSH server checks the
user's identity. The user must have a valid user account and home
directory on the server. If the server fails to authenticate the
user, the server refuses the connection.
After SSH authenticates
the user's identity, the actual secure data transfer between
client and server occurs.
The SSH server runs in a
loop, accepting messages from the client, performing required actions,
and returning reply messages to the client.
When the user closes the
connection, the server process terminates. The auxiliary server
continues to listen for new SSH connection requests.
HP TCP/IP Services for OpenVMS Guide to SSH
Secure Shell Overview
