Important Points: of RFC 4253 year 2006, SSH developed By Tatu Ylonen (Finland ) in 1995

The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over
an insecure network.
It provides strong encryption, server authentication, and integrity protection. It may also provide
compression.

Key exchange method, public key algorithm, symmetric encryption algorithm, message
authentication algorithm, and hash algorithm are all negotiated.

The SSH transport layer is a secure, low level transport protocol. It provides strong encryption,
cryptographic host authentication, and integrity protection.

Authentication in this protocol level is host-based; this protocol does not perform user
authentication

It is expected that in most environments, only 2 round-trips will be needed for full key exchange,
server authentication, service request, and acceptance notification of service request. The worst
case is 3 round-trips.

Connection Setup

SSH works over any 8-bit clean, binary-transparent transport. The underlying transport SHOULD
protect against transmission errors, as such errors cause the SSH connection to terminate.

The client initiates the connection.

SSH when used over TCP/IP, the server normally listens for connections on port 22

Protocol Version Exchange

When the connection has been established, both sides MUST send an identification string. This
identification string MUST be

SSH-protoversion-softwareversion SP comments CR LF

SP – space
CR – carriage Return
LF- Line Feed

The 'comments' string is OPTIONAL. If the 'comments' string is included, a 'space' character
(denoted above as SP, ASCII 32) MUST separate the 'softwareversion' and 'comments' strings. The
identification MUST be terminated by a single Carriage Return (CR) and a single Line Feed (LF)
character (ASCII 13 and 10, respectively).

The maximum length of the string is 255 characters, including the Carriage Return and Line Feed.

The part of the identification string preceding the Carriage Return and Line Feed is used in the Diffie-
Hellman key exchange

As such, an example of a valid identification string is

 SSH-2.0-billsSSH_3.6.3q3<CR><LF>

This identification string does not contain the optional 'comments' string and is thus terminated by
a CR and LF immediately after the 'softwareversion' string.

Key exchange will begin immediately after sending this identifier.

6.2. Compression

If compression has been negotiated, the 'payload' field (and only it) will be compressed using the
negotiated algorithm. The 'packet_length' field and 'mac'(Message Authentication Code) will be
computed from the compressed payload. Encryption will be done after compression.

-----------------------------------------------------------------------------------------------------------------------------------

6.3. Encryption

An encryption algorithm and a key will be negotiated during the key exchange. When encryption is
in effect, the packet length, padding length, payload, and padding fields of each packet MUST be
encrypted with the given algorithm.

All ciphers SHOULD use keys with an effective key length of 128 bits or more.

The ciphers in each direction MUST run independently of each other.

In practice however, it is RECOMMENDED that the same algorithm be used in both directions.

6.4. Data Integrity

Data integrity is protected by including with each packet a MAC that is computed from a shared
secret, packet sequence number, and the contents of the packet.

mac = MAC(key, sequence_number || unencrypted_packet)

6.5. Key Exchange Methods

The key exchange method specifies how one-time session keys are generated for encryption and
for authentication, and how the server authentication is done.

Two REQUIRED key exchange methods have been defined:

diffie-hellman-group1-sha1 REQUIRED

diffie-hellman-group14-sha1 REQUIRED
5.1. Old Client, New Server
The server can then determine whether the client is using an old protocol, and can revert to the
old protocol if required. Connection is setup.
5.2. New Client, Old Server
The connection fails. Since the new client MAY immediately send additional data after its
identification string (before receiving the server's identification string), the old protocol may already
be corrupt when the client learns that the server is old. When this happens, the client SHOULD
close the connection to the server, and reconnect using the old protocol.
--------------------------------------------------------------------------------------------------------------------------------------
HOW SSH WORKS

SSH comprises of three protocols that run on top of TCP protocol

1. SSH Transport layer protocol – it provides server authentication & data

confidentiality.
2. SSH user authentication protocol – it authenticates the user
3. SSH connection protocol – it multiplexes multiple communication channels over
single SSH connection

STEPS involved in Establishing SSH connection from Client to Server

1. TCP three way handshake is completed, with connection initiated from client to
server.
2. Identification String Exchange
a. In this SSH-Protocol Version Software Version is sent from client to server &
Server respond back with its Identification String Exchange .

3. Algorithm Negotiation
a. Both client & server will negotiate and come up with key exchange ,
Encryption, Message authentication code and compression algorithm.
b. The client sends KEXINIT message, where it tells the server about its
supported algorithm. The algorithms in client list are sorted in the order of
preferrance. The most top algorithm in the list is preferred algorithm by
client.
c. The server responds with KEXINIT message, telling the client its list of
supporting algorithms.
d. Since these exchanges are done at pretty much at same time, the client and
servers are guessing the algorithm. If both client & server have come up with
 same algorithm , they move to next step. Otherwise the server picks the
algorithm on the client list if it is supported by itself.
e. If the algorithm doesn’t match, then the connection fails & both disconnects.

4. KEY EXCHANGE PHASE

a. Both client and server use key exchange algorithm, such as diffie-hellman
algorithm, to calculate a secret key.
b. In this phase client generate an ephemeral key pair ( public & private key
pair). The ephemeral private key remains with client & The ephemeral
public key is sent to server in a message SSH_MSG_KEX_DH_INIT
c. As soon as server receives the clients ephemeral public key, the server
generates its ephemeral key pair ( public & private key pair). The server then
calculates a Secret Key , using clients ephemeral public key & its own
ephemeral key pair.
d. The server also computes an Exchange Hash. To generate this hash server
uses algorithm which has been agreed by both client and server. The inputs
to this hashing algorithm are
i. Clients Identification String (SSH-Protocol Version Software Version)
ii. Server Identification String(SSH-Protocol Version Software Version)
iii. Payload of clients KEXINIT
iv. Payload of servers KEXINIT
v. Servers public host key
vi. Servers ephemeral public key
vii. Clients ephemeral public key
viii. Shared secret key

( Note : Public & private Host keys are used in asymmetric algorithm such
as digital signature , digital certificate )

e. After the Hash calculation the server signs (encrypt) it with it private host
key. Why server signs the Hash value ? to prove its identity to clients. If
client can decrypt the hash using the server’s public host key, the client will
know that the hash was encrypted (signed) using servers private host key.
f. The hash value act as sessions identifier in each key exchange phase.
g. The server then sends the client with SSH_MSG_KEX_DH_REPLY, this
message includes the signed hash value , servers’ public host key &
ephemeral public key.
h. Once the client receive the message, it uses servers ephemeral public key,
and its ephemeral key pairs as input to calculate shared key.
i. Client generates the exchange hash from
i. Clients Identification String (protocol version, software version)
ii. Server Identification String
iii. Payload of clients KEXINIT
iv. Payload of servers KEXINIT
v. Servers public host key
vi. Servers ephemeral public key
vii. Clients ephemeral public key
viii. Shared secret key
 j. Client verifies the public host key of the server, this is done using digital
certificates sent by the server- if there was one Or a local database of public
keys. If neither of these exist ( ie no digital certificate signed by Cert Auth or
local database of public keys), then its upto the client to go ahead in
accepting the public key without any verification
i. If we get a alert message as shown below then no verification method
exist.

ii. The client now uses the server public host key to decrypt the servers
signed hash value, and compares it with the hash value it calculated. If
hash are same then server is authenticated.
k. For future communication server & clients are not going to use the share
secret key calculated using Diffie-Hellman algorithm. Instead they are using
the Secret key as base to derive Six new keys (3 for server , 3 for client)
i. Two keys for encryption from server to client & vice versa.
ii. Two Initialization Vectors (I V) keys from server to client & vice versa.
These keys are random numbers that are usually added to symmetric
algorithm, making it difficult to break the cipher text.
iii. Two for integrity of message from server to client & vice versa.

5. The end of Key exchange is signalled by sending SSH_MSG_NEWKEYS , informing

each other that all future communications are encrypted using these new keys.
6. The final step is client sending SSH_MSG_SERVICE_REQUEST, to request user
authentication from the server. The Server replies wit SSH_MSG_SERVICE_ACCEPT.
Now client can enter
Login as: username
Password: pwd

The End