3r3-31. 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 a total 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 with a private one, or: the RSA algorithm is used to encrypt data during transmission.
 
 
I will try to bring some clarity to the operation of the SSH protocol, and at the same time consider the role of the RSA algorithm and user authorization keys
 
 

 
3r33333.
 
 
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.
 
 
3r3-3160. 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.
 
 
3r3-3160. 2. Open the secure channel 3r3161.
 
2.1 Identity Exchange
 
 
After the TCP connection is established, the client and the server (hereinafter referred to as the parties) exchange versions of the SSH protocol and other auxiliary data necessary for determining the compatibility of the protocols and for selecting the operation algorithms.
 
 
[b] 2.2 Selection of algorithms: key exchange, encryption, compression, etc. 3r3386.
 
 
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 they 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: 3r3326.  
3r31-10. ssh -Q kex 3r33112.
 
The list of symmetric algorithms available in the system (used to encrypt the channel): 3r3326.  
3r31-10. ssh -Q cipher 3r33112.
 
The list of key types for authorization at the client:
 
3r31-10. ssh -Q key-cert 3r33112.
 
 
[b] 2.3 Getting a session encryption key 3r3386.
 
 
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: 3r3326.  
 
 
The server sends its key to the client (DSA, RSA, or the like, according to the agreement between the parties made in clause 2.2). 3r33333.  
If the client connects to this server for the first time (as indicated by the absence of an entry in the /home/username/.ssh/known_hosts file at the client), then the user will be asked to trust the server key. If the connection with this server has already been established, then the client compares the sent key with the key recorded in /home/username/.ssh/known_hosts. If the keys do not match, the user will receive a warning about a possible hacking attempt. However, this check can be skipped if you call ssh with the StrictHostKeyChecking option:
 
3r31-10. ssh -o StrictHostKeyChecking = no username @ servername 3r33112. Also, if the user needs to delete the old server key (for example, when there is an exact certainty that the key has been changed on the server), the command is used:
 
3r31-10. ssh-keygen -R servername 3r33112.
 
3r33333.  
As soon as the client decides that the server key is trusted, using one of the implementations (the version is defined in clause 2.2) of the Diffie-Hellman algorithm, the client and server generate a session key that will be used for symmetric channel encryption.
 
3r33333.  
3r33333.
 
The session key is created exclusively for the period of the channel's life and is destroyed when the connection is closed.
 
 
3r3-3160. 3. Client Authentication
 
And only now, when the client and the server have established a channel for encrypted data transfer, can they authenticate with a password or key.
 
 
In general terms, authentication using keys is as follows:
 
 
 
The client sends the username (username) and its public key to the server. 3r33333.  
The server checks in the file /home/username/.ssh/authorized_keys the presence of the public key sent by the client. If the public key is found, the server generates a random number and encrypts it with the client's public key, after which the result is sent to the client. 3r33333.  
The client decrypts the message with its private key and sends the result to the server. 3r33333.  
The server checks the result for a match with the number that it originally encrypted with the client’s public key, and if a match occurs, it considers the authentication successful. 3r33333.  
3r33333.
 
 
3r3-3160. 4. Connection level 3r3161.
 
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 3r3-3325.
 
Well, now, I think, the 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 the key creation commands (ssh-keygen), opening a terminal session (ssh), file transfer ( 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 3r3326.  
 
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 2? or the port is protected using iptables (or add-ons of the fail2ban type), the attacker will be dropped at the stage of establishing a TCP connection.
 
 
The most interestingly described looks like a table *
 
3r3194.  
 
3r3204. Configuration 3r3205.  
3r3204. The probability of breaking
 
3r3204. Losses from flooding **
 
3r3309.  
 
3r3306. Port 2? 3r3326.  
password authentication,
 
without protection 3r3307.  
3r3306. high 3r3307.  
3r3306. high 3r3307.  
3r3309.  
 
3r3306. Port 2? 3r3326.  
key authorization,
 
without protection 3r3307.  
3r3306. average *** 3r3307.  
3r3306. high 3r3307.  
3r3309.  
 
3r3306. Port 2? 3r3326.  
key authorization,
 
protection based on limiting failed authorization attempts 3r3307.  
3r3306. low 3r3307.  
3r3306. average **** 3r3307.  
3r3309.  
 
3r3306. Custom port,
 
password authentication,
 
without protection 3r3307.  
3r3306. high 3r3307.  
3r3306. low 3r3307.  
3r3309.  
 
3r3306. Custom port,
 
key authorization,
 
without protection 3r3307.  
3r3306. average *** 3r3307.  
3r3306. low 3r3307.  
3r3309.  
 
3r3306. Custom port,
 
key authorization,
 
protection based on limiting failed authorization attempts 3r3307.  
3r3306. low 3r3307.  
3r3306. low 3r3307.  
3r3309.  
3r33311.
 
* - the values ​​of the parameters (high, medium, low) are of a relative nature 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 authentication attempts is limited, but the server still has to handle them from a large number of intruders.
 
 
Additional materials 3r3325.
 
 
3r33333. SSH sources
3r33333.  
3r33336. SSH protocol specifications (en)
3r33333.  
3r33333. Diffie-Hellman algorithm
3r33333.  
3r33333. Algorithm RSA
3r33333.  
3r33351. How SSH appeared on port 22 3rr3362. 3r33333.  
3r33356. What is written in the .ssh /known_hosts file
3r33333.  
3r33333. Memo to ssh users
3r33333.  
3r33333.
3r33333. ! function (e) {function t (t, n) {if (! (n in e)) {for (var r, a = e.document, i = a.scripts, o = i.length; o-- ;) if (-1! == i[o].src.indexOf (t)) {r = i[o]; break} if (! r) {r = a.createElement ("script"), r.type = "text /jаvascript", r.async =! ? r.defer =! ? r.src = t, r.charset = "UTF-8"; var d = function () {var e = a.getElementsByTagName ("script")[0]; e.parentNode.insertBefore (r, e)}; "[object Opera]" == e.opera? a.addEventListener? a.addEventListener ("DOMContentLoaded", d,! 1): e.attachEvent ("onload", d ): d ()}}} t ("//mediator.mail.ru/script/2820404/"""_mediator") () ();