⬆️ ⬇️

Algorithm for establishing a connection in the SSH protocol

(The initial title of the article “SSH protocol operation algorithm” was changed according to the recommendations of Vindicar , Karroplan and other members of the habrosocommunity)



Periodically reading articles on SSH, I noticed that their authors sometimes have no idea how this protocol works. In most cases, they are limited to considering the topic of key generation and the description of options for the main commands. Even experienced system administrators often carry complete nonsense when discussing SSH operation issues, giving out opus in the style: the transmitted data is encrypted with the client's open SSH key, and decrypted as a private one, or: the RSA algorithm is used to encrypt the data.



I will try to bring some clarity to the work of the SSH protocol, and at the same time consider the role of the RSA algorithm and user authorization keys ...

')

image



The SSH protocol algorithm can be divided into three levels, each of which is located above the previous one: transport (opening a secure channel), authentication, connection. For the integrity of the picture, I will also add the network connection setup level, although officially this level is below SSH.



1. Establish a TCP connection



I will not dwell on the principle of operation of the TCP / IP stack, since this topic is well documented in RuNet. If necessary, you can easily find information.



At this stage, the client connects to the server on the TCP port specified in the Port option (default: 22) in the server configuration file / etc / ssh / sshd_config.



2. Opening a secure channel



2.1 Identity Exchange



After the TCP connection is established, the client and the server (hereinafter referred to as the parties) exchange the versions of the SSH protocol and other auxiliary data necessary for determining the compatibility of the protocols and for selecting the operation algorithms.



2.2 Selection of algorithms: key exchange, encryption, compression, etc.



When SSH is used, quite a few algorithms are used, some of them are used for encryption, the second for key exchange, the third for compressing transmitted data, etc. At this step, the parties send each other lists of supported algorithms, the highest priority is given to the algorithms at the top of each list. Then compare the algorithms in the received lists with the algorithms available in the system, and select the first matched one in each list.



The list of available client-side key exchange algorithms (used to obtain a session key) can be viewed with the command:



ssh -Q kex 


The list of symmetric algorithms available in the system (used to encrypt the channel):



 ssh -Q cipher 


The list of key types for authorization at the client:



 ssh -Q key-cert 


Added by remark onix74 :

All the commands used in the publication are relevant for the version of OpenSSH 7.6 from Ubuntu 18.04 LTS.



2.3 Obtaining session encryption key



The process of obtaining a session key may differ depending on the version of the algorithm, but in general terms it comes down to the following:





The session key is created exclusively for the period of the channel's life and is destroyed when the connection is closed.



3. Client Authentication



And only now, when the client and the server have established a channel for encrypted data transfer, can they authenticate by password or key.



In general, authentication using keys is as follows:





4. Connection Level



After carrying out all the above procedures, the user is able to send commands to the server or copy files.



At this level, the following is provided: channel multiplication (the ability of multiple channels to work on a single server by combining them into one channel), tunneling, etc.



From theory to practice



Well, now, I think, readers have quite a legitimate question: why do we need to know all these subtleties of the SSH protocol, if for everyday work there is enough knowledge of key creation commands (ssh-keygen), opening a terminal session (ssh), transferring files ( scp)?



As a response, you can recall the topic of changing the standard SSH port to another one, which constantly becomes the cause of holivar on Habr ...



In my own practice, I don’t remember a single server looking to the external network that would not be daily slapped to port 22. In a situation if SSH works on a standard port for you (and is not additionally protected by anything), even if authentication using keys only and no password selections do not frighten you, the server is still forced to do a lot of useless work because of constant requests from unscrupulous clients: establish a TCP connection, select algorithms, generate a session key, send authentication requests, write a log file.



In a situation where there is nothing on port 22, or the port is protected using iptables (or add-ons of the fail2ban type), then the attacker will be dropped at the stage of establishing a TCP connection.



The most interestingly described looks like a table *

ConfigurationProbability of hackingLosses from flooding **
Port 22,

password authentication,

without protection
highhigh
Port 22,

key authorization

without protection
average ***high
Port 22,

key authorization

protection based on limiting failed authorization attempts
lowaverage ****
Custom port,

password authentication,

without protection
highlow
Custom port,

key authorization

without protection
average ***low
Custom port,

key authorization

protection based on limiting failed authorization attempts
lowlow


* - the values ​​of the parameters (high, medium, low) are relative and serve only to compare indicators.

** - meaning the consumption of server resources (processor, disk, network channel, etc.) for processing an avalanche of requests, usually going to port 22.

*** - hacking, if RSA-keys are used for authorization, is very difficult, but an unlimited number of authorization attempts makes this possible.

**** - the number of authorization attempts is limited, but the server still has to process them from a large number of intruders.



Additional materials



Source: https://habr.com/ru/post/425637/



All Articles