added some introduction and reorderd fingerprint chapters

Author: manfred-kaiser

doc/authentication.rst

@@ -1,6 +1,14 @@
 Authentication
 ==============
 
+The choice of the right authentication method against SSH-MITM can have a decisive influence on the success of a Man in the Middle attack.
+
+The most popular authentication methods are "password" and "publickey" authentication. However, there are others, such as "none" and "keyboard-interactive".
+
+To log in to an SSH server it is necessary to specify an existing user. There are systems that use a default username.
+This is most common with Git repositories. Examples of this are GitLab and GitHub, which use the username "git" and distinguish which
+resources a user is allowed to access based on the public key at login.
+
 
 none Authentication
 -------------------

doc/fingerprint.rst

@@ -14,22 +14,6 @@ In most cases, a new key is automatically generated during installation. When a
     For this reason, the fingerprint must always be compared against a trusted source.
 
 
-There are SSH clients that have a flawed fingerprint check and are thus vulnerable to man in the middle attacks. An example of this is the SFTP implementation of Midnight Commander.
-This vulnerability was discovered and fixed only after 9 years. See ref:`CVE-2021-36370`
-
-However, most programs do not have fingerprint verification vulnerabilities. As long as the fingerprint is checked, it is not possible to connect to an unknown server.
-
-In many cases, the vulnerability is not the program, but the user who does not properly check the fingerprint against a known value. There can be many reasons for this.
-
-Many users do not know what the fingerprint means. There are tutorials on the Internet that do not describe what the fingerprint is, but only write that you simply have to confirm this query with "yes" to establish the connection.
-
-It also often happens that the fingerprint is not known and cannot be checked against a trusted source. These could be new systems that generate a random key on first launch.
-
-Systems such as a development server may have it reinstalled frequently. This causes the fingerprints to change which leads to users being used to accepting unknown fingerprints.
-
-However, previous studies (Peter Gutmann, Do Users Verify SSH Keys? / Konrad Rieck (Fuzzy Fingerprints Attacking Vulnerabilities in the Human Brain, 2002) ) have shown that users verify a fingerprint in very few cases. In the study by Peter Gutmann, IT departments were asked how often the user asked the IT department for the new fingerprint after a new installation. The study showed that this was almost never the case.
-
-In cases where the fingerprint is checked, it is very efficient to generate an SSH key with a similar hash value as the one of the target computer.  The longer and more complex a fingerprint becomes, the more likely it is that only parts of the fingerprint are compared. This results in a fingerprint that is actually wrong being considered correct. This technique is known as fuzzy fingerprinting.
 
 
 Checking the fingerprint
@@ -99,9 +83,6 @@ So in the above example
     ssh-keygen -f "/home/tux/.ssh/known_hosts" -R 172.217.22.227
 
 
-
-
-
 Determine fingerprint of the server
 -----------------------------------
 
@@ -187,43 +168,30 @@ In this case, the fingerprint must still be checked against a trusted source.
 
 However, the fingerprint stored in the DNS is no longer considered trustworthy in this case. The reason for this is that the integrity of the DNS zone is no longer guaranteed due to an incorrect DNSSEC configuration.
 
-Recognizing clients with known fingerprints
--------------------------------------------
 
-If the client is already in possession of a fingerprint, the received fingerprint is compared with it. If the fingerprints do not match, a warning is issued and the connection is terminated.
+SSH-MITM - attacks on the fingerprint verification
+--------------------------------------------------
 
-However, a Man in the Middle attack should remain undetected for as long as possible. For this reason, it is necessary to prevent the warnings generated by the client.
+There are SSH clients that have a flawed fingerprint check and are thus vulnerable to man in the middle attacks. An example of this is the SFTP implementation of Midnight Commander.
+This vulnerability was discovered and fixed only after 9 years. See :ref:`CVE-2021-36370`
 
-RFC-4253 defines how the key exchange works. A list of supported algorithms is sent to the server. The first entry defines the preferred algorithm.
+However, most programs do not have fingerprint verification vulnerabilities. As long as the fingerprint is checked, it is not possible to connect to an unknown server.
 
-This behavior can be used to find out whether a client has already stored a fingerprint for the current connection or not.
+In many cases, the vulnerability is not the program, but the user who does not properly check the fingerprint against a known value. There can be many reasons for this.
 
-In a Man in the Middle attack, this knowledge can be used to not intercept clients that would issue a warning or to pass the connection through to the actual destination server.
+Many users do not know what the fingerprint means. There are tutorials on the Internet that do not describe what the fingerprint is, but only write that you simply have to confirm this query with "yes" to establish the connection.
 
-An exemplary key exchange with and without a known fingerprint could look as follows:
+It also often happens that the fingerprint is not known and cannot be checked against a trusted source. These could be new systems that generate a random key on first launch.
 
+Systems such as a development server may have it reinstalled frequently. This causes the fingerprints to change which leads to users being used to accepting unknown fingerprints.
 
-+------------------------+------------------------+
-| New Fingerprint        | Known Fingerprint      |
-+========================+========================+
-| ssh-ed25519            | ssh-rsa                |
-+------------------------+------------------------+
-| ecdsa-sha2-nistp256    | ssh-ed25519            |
-+------------------------+------------------------+
-| ecdsa-sha2-nistp384    | ecdsa-sha2-nistp256    |
-+------------------------+------------------------+
-| ecdsa-sha2-nistp521    | ecdsa-sha2-nistp384    |
-+------------------------+------------------------+
-| ssh-rsa                | ecdsa-sha2-nistp521    |
-+------------------------+------------------------+
-| ssh-dss                | ssh-dss                |
-+------------------------+------------------------+
+However, previous studies (Peter Gutmann, Do Users Verify SSH Keys? / Konrad Rieck (Fuzzy Fingerprints Attacking Vulnerabilities in the Human Brain, 2002) ) have shown that users verify a fingerprint in very few cases. In the study by Peter Gutmann, IT departments were asked how often the user asked the IT department for the new fingerprint after a new installation. The study showed that this was almost never the case.
+
+In cases where the fingerprint is checked, it is very efficient to generate an SSH key with a similar hash value as the one of the target computer.  The longer and more complex a fingerprint becomes, the more likely it is that only parts of the fingerprint are compared. This results in a fingerprint that is actually wrong being considered correct. This technique is known as fuzzy fingerprinting.
 
-If the fingerprint is not known, the list is sent to the server with a predefined sequence.
-However, if the client has already saved a fingerprint for the server, the last used algorithm used is put first.
 
 Fuzzy Fingerprints
-------------------
+""""""""""""""""""
 
 .. note::
 
@@ -276,6 +244,43 @@ Base64, which is used for SHA256 fingerprints, was not evaluated in this work, w
 
 
 
+
+Recognizing clients with known fingerprints
+"""""""""""""""""""""""""""""""""""""""""""
+
+If the client is already in possession of a fingerprint, the received fingerprint is compared with it. If the fingerprints do not match, a warning is issued and the connection is terminated.
+
+However, a Man in the Middle attack should remain undetected for as long as possible. For this reason, it is necessary to prevent the warnings generated by the client.
+
+RFC-4253 defines how the key exchange works. A list of supported algorithms is sent to the server. The first entry defines the preferred algorithm.
+
+This behavior can be used to find out whether a client has already stored a fingerprint for the current connection or not.
+
+In a Man in the Middle attack, this knowledge can be used to not intercept clients that would issue a warning or to pass the connection through to the actual destination server.
+
+An exemplary key exchange with and without a known fingerprint could look as follows:
+
+
++------------------------+------------------------+
+| New Fingerprint        | Known Fingerprint      |
++========================+========================+
+| ssh-ed25519            | ssh-rsa                |
++------------------------+------------------------+
+| ecdsa-sha2-nistp256    | ssh-ed25519            |
++------------------------+------------------------+
+| ecdsa-sha2-nistp384    | ecdsa-sha2-nistp256    |
++------------------------+------------------------+
+| ecdsa-sha2-nistp521    | ecdsa-sha2-nistp384    |
++------------------------+------------------------+
+| ssh-rsa                | ecdsa-sha2-nistp521    |
++------------------------+------------------------+
+| ssh-dss                | ssh-dss                |
++------------------------+------------------------+
+
+If the fingerprint is not known, the list is sent to the server with a predefined sequence.
+However, if the client has already saved a fingerprint for the server, the last used algorithm used is put first.
+
+
 Testing with SSH-MITM
 """""""""""""""""""""