Secure Shell
SSH provides support for secure remote login, secure file transfer, and secure TCP/IP and X11 forwarding. It can automatically encrypt, authenticate, and compress transmitted data.
The main idea of SSH is to establish a common key between a client and a server using secure key exchange technique. The
followed communications are then encrypted and authenticated. So the main idea is not very complicated. However, as a real
SSH consists of three major components:
• The Transport Layer Protocol provides server authentication, confidentiality and integrity with perfect forward secrecy.
• The User Authentication Protocol authenticates the client to the server.
SSH was described in Internet-Draft written by secsh group. Recently, SSH has been published as RFC 4251-4256 (January 2006).
The Transport Layer Protocol can be described as follows. In SSH, the server listens for connections (on port 22). The client initiates a connection. When the connection has been established, both sides do the following. In what follows, C denote the client and S denote the server.
• Send an identification string to each other. The main contents of the string is the version of SSH and the version of software they used. An example is as follows.
In this example, the user uses protocol version 2.0 and a
software billsSSH 3.6.3q3. The identification string must be terminated by a single Carriage Return (CR) and a single Line Feed (LF) character (ASCII 13 and 10, respectively).
• Both side send out a KEXINIT packet. This packet includes: cookie (random bytes), list of algorithms supported by the machine such as key exchange algorithms, encryption
algorithms, MAC algorithms, compression algorithms,
• Run key exchange program. For example the following Diffie-Hellman key exchange can be used.
1. C generates a random number x, (1 < x < q) and sends the value e = αx mod p to S.
2. S generates a random value y, (0 < y < q) and computes f = αy mod p, K = ey = αxy mod p and
H = hash(VC||VS||IC||IS||KS||e||f ||K),
where VC, VS are the version strings for C and S respectively,
IC (IS) is the payload of C’s (respectively S’s) KEXINIT, KS is
S’s public key used to verify the signature. A payload means the useful contents of the packet. Then S computes the
3. C checks KS from a local database or some trusted certification
authority. C computes K = fx mod p and
H = hash(VC||VS||IC||IS||KS||e||f ||K).
Then C verifies the signature s.
K is the session key. A session key should be re-changed after some time. It is recommended that the keys are changed after each gigbyte of transmitted data or after each hour of
• User Authentication protocol and connection protocol may start after the key exchange.
• C requests a service from S and S provides the service. In this stage, all the communications should be encrypted and
authenticated.
• Either party sends out a disconnection message.
All packets following the identification string use the following binary packet protocol.
PKL PDL Payload Padding MAC
The fields of the packet is as follows. The total size of the packet is 35, 000 bytes or less.
• PKL (32 bits): The length of the packet (in bytes), not including MAC and PKL field itself.
• Payload (n1 bytes): The useful contents of the packet. If
compression has been negotiated, this field is compressed. n1 =
PKL-PDL - 1.
• Padding (PDL bytes): Added random padding bytes, such that the total length of the packet is a multiple of the cipher block size or 8, whichever is larger. The length of the padding (PDL) is between 4 bytes to 255 bytes.
• MAC: If message authentication has been negotiated, this field contains the MAC bytes. Initially, the MAC algorithm is
The encryption method required in SSH is 3-DES (3 keys) of CBC mode. Other method recommended for SSH are AES-128,
AES-192, AES-256. Optional encryption algorithms can be used in SSH such as: Blowfish, Twofish, Serpend, IDEA, CAST.
The compression method currently defined is zlib.
The message authentication used in SSH is HMAC. The hash function used is SHA-1, but the MD5 is still an option.
SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH
connection protocol. The service name for this protocol is
“ssh-userauth”. Basically, the server sends authentication requests using the following format:
SSH-MSG-USERAUTH-RQUEST (code 50) user name
service name method name
The server should have a timeout for authentication, and
disconnect if the authentication has not been accepted within the timeout period. If the authentication is successful, then the server sends out a response:
SSH-MSG-USERAUTH-SUCCESS (code 52) Otherwise the server responds:
There are three authentication methods used in SSH. One is the public key authentication method. In this method, the user uses a public key signature scheme to sign on a message that contains
session identifier, user name, public key algorithm name, public key to be used for authentication etc. When the server receives this
message, it checks whether the supplied key is acceptable for authentication, and if so, it then check whether the signature is correct.
The second method is password authentication method. In this method, the user needs to transmit the password to server. Since this transmitted packet is on the transport layer, it is encrypted. In this case, both the server and the client should check whether the underlying transport layer provides confidentiality (i.e., if
The third method is host-based authentication. This form of
authentication is optional, since it is not suitable for high-security sites. It is similar to the UNIX rhosts and hosts.equiv styles of authentication, except that the identity of the client host is checked more rigorously. In this method, the client sends a public key
signature with the key of the client host. The message signed
contains session identifier, user name, public key algorithm for host key, public host key and certificates for client host, client host
name, etc. The server verifies that the host key actually belongs to the client host name in the message, that the given user on that host is allowed to log in, and that the signature is a valid signature on the appropriate value by the given host key. If it is possible, the server performs additional checks to verify that the network
The SSH connection protocol has been designed to run on top of the SSH transport layer and user authentication protocols. It
provides interactive login session, remote execution of commands, forward TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encryption tunnel. We will omit the details of this protocol, since the most security considerations are addressed in transport layer protocol and user authentication protocol.
