(Der ursprüngliche Titel des Artikels "SSH Protocol Operation Algorithm" wurde gemäß den Empfehlungen von Vindicar , Karroplan und anderen Mitgliedern der Habro-Community geändert.)Während ich regelmäßig Artikel über SSH las, bemerkte ich, dass ihre Autoren manchmal keine Ahnung haben, wie dieses Protokoll funktioniert. In den meisten Fällen beschränken sie sich darauf, das Thema der Schlüsselgenerierung zu betrachten und die Optionen der Hauptbefehle zu beschreiben. Selbst erfahrene Systemadministratoren machen bei der Erörterung von SSH-Problemen häufig Unsinn und geben Opus mit Stil heraus: Die übertragenen Daten werden mit dem öffentlichen SSH-Schlüssel des Clients verschlüsselt und mit dem privaten Schlüssel entschlüsselt, oder: Der RSA-Algorithmus wird zum Verschlüsseln von Daten während der Übertragung verwendet.
Ich werde versuchen, die Funktionsweise des SSH-Protokolls klarer zu gestalten und gleichzeitig die Rolle des RSA-Algorithmus und der Benutzerautorisierungsschlüssel zu berücksichtigen ...
Der SSH-Protokollalgorithmus kann in drei Ebenen unterteilt werden, von denen sich jede über der vorherigen befindet: Transport (Öffnen eines sicheren Kanals), Authentifizierung, Verbindung. Aus Gründen der Bildintegrität werde ich auch eine Netzwerkverbindungs-Setup-Ebene hinzufügen, obwohl diese Ebene offiziell unter SSH liegt.
1. Stellen Sie eine TCP-Verbindung her
Ich werde nicht auf das Prinzip des TCP / IP-Stacks eingehen, da dieses Thema in Runet gut dokumentiert ist. Bei Bedarf finden Sie leicht Informationen.
Zu diesem Zeitpunkt stellt der Client über den TCP-Port, der in der Option Port (Standard: 22) in der Serverkonfigurationsdatei / etc / ssh / sshd_config angegeben ist, eine Verbindung zum Server her.
2. Öffnen eines sicheren Kanals
2.1 IdentitätsaustauschNachdem die TCP-Verbindung hergestellt wurde, tauschen der Client und der Server (im Folgenden als Parteien bezeichnet) die SSH-Protokollversionen und andere unterstützende Daten aus, die zur Bestimmung der Protokollkompatibilität und zur Auswahl von Betriebsalgorithmen erforderlich sind.
2.2 Auswahl der Algorithmen: Schlüsselaustausch, Verschlüsselung, Komprimierung usw.Bei der Arbeit mit SSH werden einige Algorithmen verwendet, einige davon zur Verschlüsselung, der zweite zum Schlüsselaustausch, der dritte zur Komprimierung übertragener Daten usw. In diesem Schritt senden sich die Parteien gegenseitig Listen unterstützter Algorithmen. Die Algorithmen oben in jeder Liste haben die höchste Priorität. Dann werden die Algorithmen in den erhaltenen Listen mit den im System verfügbaren Algorithmen verglichen, und der erste, der in jeder Liste übereinstimmt, wird ausgewählt.
Eine Liste der verfügbaren clientseitigen Schlüsselaustauschalgorithmen (zum Abrufen eines Sitzungsschlüssels) kann mit dem folgenden Befehl angezeigt werden:
ssh -Q kex
Liste der im System verfügbaren symmetrischen Algorithmen (zur Kanalverschlüsselung verwendet):
ssh -Q cipher
Liste der Schlüsseltypen für die Autorisierung beim Kunden:
ssh -Q key-cert
Aktualisiert durch Bemerkung onix74 :Alle in der Veröffentlichung verwendeten Befehle sind für OpenSSH Version 7.6 von Ubuntu 18.04 LTS relevant.
2.3 Abrufen eines SitzungsverschlüsselungsschlüsselsDer Prozess zum Abrufen eines Sitzungsschlüssels kann je nach Version des Algorithmus unterschiedlich sein, läuft jedoch im Allgemeinen auf Folgendes hinaus:
Ein Sitzungsschlüssel wird ausschließlich für die Lebensdauer des Kanals erstellt und beim Schließen der Verbindung zerstört.
3. Client-Authentifizierung
Und erst jetzt, wenn Client und Server einen Kanal für die verschlüsselte Datenübertragung eingerichtet haben, können sie sich mit einem Kennwort oder Schlüsseln authentifizieren.
Im Allgemeinen erfolgt die Schlüsselauthentifizierung wie folgt:
- Der Client sendet dem Server einen Benutzernamen (Benutzernamen) und seinen öffentlichen Schlüssel.
- Der Server überprüft die Datei /home/username/.ssh/authorized_keys auf den vom Client gesendeten öffentlichen Schlüssel. Wenn der öffentliche Schlüssel gefunden wird, generiert der Server eine Zufallszahl und verschlüsselt sie mit dem öffentlichen Schlüssel des Clients. Anschließend wird das Ergebnis an den Client gesendet.
- 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 er ursprünglich mit dem öffentlichen Schlüssel des Clients verschlüsselt hat. Wenn dies übereinstimmt, betrachtet er die Authentifizierung als erfolgreich.
4. Verbindungsebene
Nach dem Ausführen aller oben genannten Verfahren hat der Benutzer die Möglichkeit, Befehle an den Server zu senden oder Dateien zu kopieren.
Auf dieser Ebene wird Folgendes bereitgestellt: Multiplikation von Kanälen (die Fähigkeit, mehrere Kanäle zu einem Server zu betreiben, indem sie zu einem Kanal kombiniert werden), Tunneln usw.
Von der Theorie zur Praxis
Nun, ich denke, die Leser haben eine völlig logische Frage: Warum müssen Sie all diese Details des SSH-Protokolls kennen, wenn für die tägliche Arbeit genügend Kenntnisse über die Schlüsselerstellungsbefehle (ssh-keygen), das Öffnen einer Terminalsitzung (ssh) und die Dateiübertragung ( scp)?
Als Antwort können wir uns an das Thema erinnern, den Standard-SSH-Port auf einen anderen zu ändern, der auf Habr ständig zur Ursache von Holivar wird ...
In meiner eigenen Praxis erinnere ich mich nicht an einen einzelnen Server, der das externe Netzwerk betrachtet und nicht täglich an Port 22 abgehört wird. In einer Situation, in der SSH für Sie an einem Standardport funktioniert (und durch nichts geschützt ist), ist der Server aufgrund ständig lügender Anfragen von unehrlichen Clients immer noch gezwungen, viele nutzlose Arbeiten auszuführen, selbst wenn die Authentifizierung durch Schlüssel und keine Kennwortschätzungen beängstigend sind: Stellen Sie eine TCP-Verbindung her, wählen Sie Algorithmen aus, generieren Sie einen Sitzungsschlüssel, senden Sie Authentifizierungsanforderungen und schreiben Sie eine Protokolldatei.
In einer Situation, in der sich am 22. Port nichts befindet oder der Port durch iptables (oder Add-Ons wie fail2ban) geschützt ist, wird der Angreifer beim Aufbau einer TCP-Verbindung fallen gelassen.
Das interessanteste beschrieben sieht aus wie eine Tabelle *
| Konfiguration | Hacking Chance | Hochwasserverluste ** |
|---|
22 Port
Passwortautorisierung,
ohne Schutz | hoch | hoch |
22 Port
Schlüsselautorisierung,
ohne Schutz | Durchschnitt *** | hoch |
22 Port
Schlüsselautorisierung,
Schutz basierend auf der Einschränkung fehlgeschlagener Autorisierungsversuche | niedrig | mittel **** |
Nicht standardmäßiger Port,
Passwortautorisierung,
ohne Schutz | hoch | niedrig |
Nicht standardmäßiger Port,
Schlüsselautorisierung,
ohne Schutz | Durchschnitt *** | niedrig |
Nicht standardmäßiger Port,
Schlüsselautorisierung,
Schutz basierend auf der Einschränkung fehlgeschlagener Autorisierungsversuche | niedrig | niedrig |
* - Parameterwerte (hoch, mittel, niedrig) sind relativer Natur und dienen nur zum Vergleich von Indikatoren.
** - Dies bedeutet den Ressourcenverbrauch des Servers (Prozessor, Festplatte, Netzwerkkanal usw.) für die Verarbeitung einer Lawine von Anforderungen, die normalerweise an Port 22 gesendet werden.
*** - Das Hacken, 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, der Server muss sie jedoch noch von einer großen Anzahl von Eindringlingen verarbeiten.
Zusätzliche Materialien