Verbindungsalgorithmus in SSH

Published on October 09, 2018

Verbindungsalgorithmus in SSH

    (Der anfängliche Titel des Artikels "Algorithmus des SSH-Protokolls" wurde gemäß den Empfehlungen von Vindicar , Karroplan und anderen Mitgliedern des Habrosobshchestvo geändert.) Beim

    regelmäßigen Lesen von Artikeln über SSH fiel mir auf, dass ihre Autoren manchmal nicht wissen , wie dieses Protokoll funktioniert. In den meisten Fällen können sie nur das Thema der Schlüsselerzeugung und die Beschreibung der Optionen für die Hauptbefehle berücksichtigen. Selbst erfahrene Systemadministratoren sind bei der Diskussion von SSH-Betriebsproblemen oft völlig unsinnig und geben Opus in einem Stil aus: Die übertragenen Daten werden mit dem offenen SSH-Schlüssel des Clients verschlüsselt und mit einem privaten Schlüssel entschlüsselt, oder: Der RSA-Algorithmus wird verwendet, um Daten während der Übertragung zu verschlüsseln.

    Ich werde versuchen, die Arbeit des SSH-Protokolls etwas Klarheit zu bringen, und gleichzeitig die Rolle des RSA-Algorithmus und der Benutzerautorisierungsschlüssel berücksichtigen.

    Bild

    Der SSH-Protokollalgorithmus kann in drei Ebenen unterteilt werden, von denen sich jede über der vorherigen befindet: Transport (Öffnen eines sicheren Kanals), Authentifizierung, Verbindung. Für die Integrität des Bildes füge ich auch die Netzwerkverbindungseinstellungsstufe hinzu, obwohl diese Stufe offiziell unter SSH liegt.

    1. Stellen Sie eine TCP-Verbindung her


    Ich werde mich nicht mit dem Funktionsprinzip des TCP / IP-Stacks beschäftigen, da dieses Thema in RuNet gut dokumentiert ist. Bei Bedarf können Sie leicht Informationen finden.

    In diesem Stadium stellt der Client eine Verbindung zum Server an dem TCP-Port her, der in der Port-Option (Standard: 22) in der Serverkonfigurationsdatei / etc / ssh / sshd_config angegeben ist.

    2. Einen sicheren Kanal öffnen


    2.1 Identitätsaustausch

    Nachdem die TCP-Verbindung hergestellt wurde, tauschen der Client und der Server (im Folgenden als Parteien bezeichnet) die SSH-Protokollversionen und andere Hilfsdaten aus, die erforderlich sind, um die Kompatibilität der Protokolle zu bestimmen und die Betriebsalgorithmen auszuwählen.

    2.2 Auswahl der Algorithmen: Schlüsselaustausch, Verschlüsselung, Komprimierung usw.

    Bei der Verwendung von SSH werden einige Algorithmen verwendet, von denen einige für die Verschlüsselung verwendet werden, der zweite für den Schlüsselaustausch, der dritte für die Komprimierung der übertragenen Daten usw. In diesem Schritt senden die Parteien einander Listen unterstützter Algorithmen, wobei den Algorithmen am oberen Rand jeder Liste die höchste Priorität eingeräumt wird. Dann vergleichen sie die Algorithmen in den empfangenen Listen mit den im System verfügbaren Algorithmen und wählen in jeder Liste den ersten übereinstimmenden aus.

    Die Liste der verfügbaren clientseitigen Schlüsselaustauschalgorithmen (zum Abrufen eines Sitzungsschlüssels) kann mit dem Befehl angezeigt werden:

    ssh -Q kex

    Die Liste der im System verfügbaren symmetrischen Algorithmen (zur Verschlüsselung des Kanals):

    ssh -Q cipher

    Die Liste der Schlüsseltypen für die Autorisierung beim Kunden:

    ssh -Q key-cert

    Hinzugefügt am Hinweis onix74 :
    Alle in der Veröffentlichung verwendeten Befehle sind für die Version von OpenSSH 7.6 von Ubuntu 18.04 LTS relevant.

    2.3 Abrufen eines Sitzungsverschlüsselungsschlüssels

    Das Abrufen eines Sitzungsschlüssels kann sich je nach Version des Algorithmus unterscheiden. Allgemein gilt jedoch Folgendes:

    • Der Server sendet seinen Schlüssel an den Client (DSA, RSA oder Ähnliches gemäß der in Klausel 2.2 vorgelegten Vereinbarung zwischen den Parteien).
    • Wenn der Client zum ersten Mal eine Verbindung zu diesem Server herstellt (was durch das Fehlen eines Eintrags in der Datei /home/username/.ssh/known_hosts des Clients angezeigt wird), wird der Benutzer aufgefordert, dem Serverschlüssel zu vertrauen. Wenn die Verbindung zu diesem Server bereits hergestellt wurde, vergleicht der Client den gesendeten Schlüssel mit dem in /home/username/.ssh/known_hosts aufgezeichneten Schlüssel. Wenn die Schlüssel nicht übereinstimmen, erhält der Benutzer eine Warnung vor einem möglichen Hacking-Versuch. Sie können diese Prüfung jedoch überspringen, wenn Sie ssh mit der Option StrictHostKeyChecking aufrufen:
      ssh -o StrictHostKeyChecking=no username@servername
      Wenn der Benutzer den alten Serverschlüssel löschen muss (wenn beispielsweise die Gewissheit besteht, dass der Schlüssel auf dem Server geändert wurde), wird der Befehl verwendet:
      ssh-keygen -R servername

    • Sobald der Client über den Serverschlüssel mit einer der Implementierungen des Diffie-Hellman-Algorithmus (die Version ist in Abschnitt 2.2 definiert) entscheidet, generieren Client und Server einen Sitzungsschlüssel, der für die symmetrische Kanalverschlüsselung verwendet wird.

    Der Sitzungsschlüssel wird ausschließlich für die Lebensdauer des Kanals erstellt und beim Schließen der Verbindung zerstört.

    3. Client-Authentifizierung


    Erst wenn Client und Server einen Kanal für die verschlüsselte Datenübertragung eingerichtet haben, können sie sich per Kennwort oder Schlüssel authentifizieren.

    Im Allgemeinen erfolgt die Authentifizierung mithilfe von Schlüsseln wie folgt:

    • Der Client sendet dem Server einen Benutzernamen (Benutzernamen) und seinen öffentlichen Schlüssel.
    • Der Server überprüft in der Datei /home/username/.ssh/authorized_keys das Vorhandensein des vom Client gesendeten öffentlichen Schlüssels. Wenn der öffentliche Schlüssel gefunden wird, generiert der Server eine Zufallszahl und verschlüsselt diese mit dem öffentlichen Schlüssel des Clients, woraufhin das Ergebnis an den Client gesendet wird.
    • Der Client entschlüsselt die Nachricht mit seinem privaten Schlüssel und sendet das Ergebnis an den Server.
    • Der Server überprüft das Ergebnis auf Übereinstimmung mit der Nummer, die ursprünglich mit dem öffentlichen Schlüssel des Clients verschlüsselt wurde. Wenn eine Übereinstimmung gefunden wird, wird die Authentifizierung als erfolgreich eingestuft.

    4. Verbindungsebene


    Nachdem Sie alle oben genannten Vorgänge ausgeführt haben, kann der Benutzer Befehle an den Server senden oder Dateien kopieren.

    Auf dieser Ebene wird Folgendes bereitgestellt: Kanalvervielfachung (die Fähigkeit mehrerer Kanäle, auf einem einzelnen Server zu arbeiten, indem sie zu einem Kanal zusammengefasst werden), Tunneling usw.

    Von der Theorie zur Praxis


    Nun, ich denke, die Leser haben eine berechtigte Frage: Warum müssen wir all diese Feinheiten des SSH-Protokolls kennen, wenn für die tägliche Arbeit ausreichend Kenntnisse über die Befehle zur Schlüsselerstellung (ssh-keygen) vorhanden sind, eine Terminalsitzung (ssh) öffnen, Dateiübertragung ( scp)?

    Als Antwort können Sie sich an das Thema erinnern, dass der Standard-SSH-Port in einen anderen Port geändert wird, der auf Habria ständig zur Ursache von Holivar wird.

    In meiner eigenen Praxis erinnere ich mich nicht an einen einzelnen Server, der auf das externe Netzwerk zugreift und nicht täglich auf Port 22 geklickt würde. In einer Situation, in der SSH an einem Standardport für Sie arbeitet (und nicht zusätzlich durch irgendetwas geschützt ist), auch wenn die Authentifizierung nur mit Schlüsseln und keine Kennwortauswahl Sie nicht erschreckt, ist der Server aufgrund ständiger Anforderungen von skrupellosen Clients immer noch zu einer unnötigen Arbeit gezwungen: TCP-Verbindung herstellen, Algorithmen auswählen, Sitzungsschlüssel generieren, Authentifizierungsanfragen senden, Protokolldatei schreiben.

    In einer Situation, in der sich an Port 22 nichts befindet oder der Port mit iptables (oder Add-Ons vom Typ fail2ban) geschützt ist, wird der Angreifer beim Herstellen einer TCP-Verbindung verworfen.

    Das am interessantesten beschriebene sieht aus wie ein Tisch
    Konfiguration Hacking-Wahrscheinlichkeit Verluste durch Überschwemmungen **
    Port 22,
    Passwortauthentifizierung,
    ohne Schutz
    hoch hoch
    Port 22,
    Autorisierung durch Schlüssel,
    ohne Schutz
    Durchschnitt *** hoch
    Port 22,
    Schlüsselberechtigung,
    Schutz basierend auf der Begrenzung fehlgeschlagener Berechtigungsversuche
    niedrig Durchschnitt ****
    Nicht-Standard-Port,
    Kennwortauthentifizierung,
    ungeschützt
    hoch niedrig
    Nicht-Standard-Port,
    Autorisierung durch Schlüssel,
    ohne Schutz
    Durchschnitt *** niedrig
    Benutzerdefinierter Port,
    Schlüsselberechtigung,
    Schutz basierend auf der Einschränkung fehlgeschlagener Berechtigungsversuche
    niedrig niedrig

    * - Die Werte der Parameter (hoch, mittel, niedrig) sind relativ und dienen nur zum Vergleich von Indikatoren.
    ** - bedeutet den Verbrauch von Serverressourcen (Prozessor, Datenträger, Netzwerkkanal usw.) zur Verarbeitung einer Lawine von Anforderungen, die normalerweise an Port 22 gehen.
    *** - Hacking, wenn RSA-Schlüssel für die Autorisierung verwendet werden, ist sehr schwierig, aber eine unbegrenzte Anzahl von Autorisierungsversuchen macht dies möglich.
    **** - Die Anzahl der Autorisierungsversuche ist begrenzt, aber der Server muss sie immer noch von einer großen Anzahl von Eindringlingen verarbeiten.

    Zusätzliche Materialien