Understand Secure Shell Packet Exchange

Introduction

This document describes packet level exchange during Secure Shell (SSH) negotiation.

Prerequisites

Requirements

Cisco recommends that you have knowledge of basic security concepts:

• Authentication
• Confidentiality
• Integrity
• Key Exchange Methods

Components Used

This document is not restricted to specific hardware version.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. 

SSH Protocol

The SSH protocol is a method for secure remote login from one computer to another. SSH applications are based on a client–server architecture,connecting an SSH client instance with an SSH server.

SSH Exchange 

1. The first step of SSH is called  Identification String Exchange.

 a. The client constructs a packet and sends it to the server containing:

•  SSH-Protocol Version
•  Software Version

Client Protocol version is SSH2.0 and Software Version is Putty_0.76.

b. The server responds with its own Identification String Exchange, including its SSH protocol version and software version.

Server's protocol version is SSH2.0 and Software version is Cisco1.25

2. Next Step is  Algorithm Negotiation. In this step, both Client and Server negotiate these algorithms:

• Keyexchange
• Encryption
• HMAC (Hash-based Message Authentication Code)
• Compression

1. The client sends a Key Exchange Init message to the server, specifying the algorithms it supports. The algorithms are listed in order of preference.

Key Exchange Init

Client Supported Algorithms

b. The server responds with its own Key Exchange Init message, listing the algorithms it supports.

c. Since these messages are exchanged concurrently, both parties compare their algorithm lists. If there is a match in the algorithms supported by both sides, they proceed to the next step. If there is no exact match, the server selects the first algorithm from the client's list that it also supports.

d. If the client and server cannot agree on a common algorithm, the key exchange fails.

Server Key Exchange Init

3. After this, both sides enter the Key Exchange phase to generate shared secret using DH key exchange and authenticate the server:

a. The client generates a keypair,  Public and Private  and sends the DH Public key in the DH Group Exchange Init packet. This key pair is used for secret key calculation.

Client DH Public Key & Diffie-Hellman Group Exchange Init

b. The server generates its own Public and Private Key pair. It uses the client's public key and its own key pair to compute the shared secret.

c. The Server also computes an Exchange hash with these inputs:

• Clients Identification String
• Server Identification String
• Payload of Client KEXINIT
• Payload of Server KEXINIT
• Servers Public-key from Host keys ( RSA Key Pair )
• Clients DH Public key
• Servers DH Public key
• Shared Secret Key

d. After computing hash, server signs it with its RSA Private key.

e. The Server constructs a message DH_Exchange_Reply that includes:

•  RSA-Public Key of Sever (to help the client authenticate the Server)
•  DH-Public key of Server (for calculating the shared secret)
•  HASH (to authenticate the server and prove that the server has generated the shared secret, as the secret key is part of the hash computation)

Server DH Public Key & Diffie-Hellman Group Exchange Reply

f. After receiving the DH_Exchange_Reply, the client computes the hash in the same way and compares it with the received hash, decrypting it using the server's RSA Public Key.

g. Before decrypting the received HASH, the client must verify the server's public key. This verification is done through a digital certificate signed by a Certificate Authority (CA). If the certificate does not exist, it is up to the client to decide whether to accept the server's public key.

Note: When you first SSH into a device that doesn't use a digital certificate, you may encounter a pop-up asking you to manually accept the server's public key. To avoid seeing this pop-up every time you connect, you can choose to add the server's host key to your cache.

Server's RSA Key

4. Since the Shared secret is now generated, both endsl use it to derive these keys :

•  Encryption keys
•  IV Keys  - These are random numbers used as input to symmetrical algorithms to enhance security
•  Integrity keys

The end of the key exchange is signaled by the exchange of the  NEW KEYS' message, which informs each party that all future messages will be encrypted and protected using these new keys . 

Client & Server New Keys

5. The final step is the Service Request. The client sends an SSH Service Request packet to the server to initiate user authentication. The server responds with an SSH Service Accept message, prompting the client to log in. This exchange occurs over the established secure channel.

Related Information

• https://www.cisco.com/c/en/us/support/docs/security-vpn/secure-shell-ssh/4145-ssh.html
• https://datatracker.ietf.org/doc/html/rfc4253
• Cisco Technical Support & Downloads