Der Prozess des SSH-Dienstes basierend auf der Schlüsselauthentifizierung im Linux-System

Wie wir alle wissen, ist SSH derzeit das zuverlässigste Protokoll, das für die Sicherheit von Remote-Anmeldesitzungen und anderen Netzwerkdiensten entwickelt wurde. Es funktioniert standardmäßig auf TCP-Port 22. Die spezifische Implementierungssoftware umfasst: OpenSSH (standardmäßig auf CentOS installiert) und DropBear. Das SSH-Protokoll hat derzeit zwei Versionen, v1 und v2. v1 basiert auf CRC-32 für MAC und ist nicht sicher. v2 verwendet den DH-Algorithmus für den Schlüsselaustausch und RSA oder DSA zur Identitätsauthentifizierung. Daher verwenden die meisten gängigen Linux-Versionen derzeit die Version V2.

Nach einem kurzen Verständnis von SSH sprechen wir über die beiden Authentifizierungsmethoden für die Benutzeranmeldung. Die erste basiert auf Benutzername und Passwort. Ich glaube, jeder sollte diese Authentifizierungsmethode kennen. Wenn wir uns beim Remote-Linux-System anmelden möchten, müssen wir den entsprechenden Benutzernamen und das entsprechende Passwort eingeben, um uns beim Remote-Linux-System anzumelden. Diese Methode ist eine interaktive Anmeldung. Die zweite ist die schlüsselbasierte Authentifizierungsmethode, über die wir heute sprechen werden.

Lassen Sie uns zunächst den Prozess der SSH-verschlüsselten Kommunikation verstehen

Wie aus der obigen Abbildung ersichtlich ist, muss auf dem Client ein Schlüsselpaar vorhanden sein. Wir alle wissen, dass Schlüssel paarweise auftreten und nur der private Schlüssel von A das entschlüsseln kann, was mit dem öffentlichen Schlüssel von A verschlüsselt ist. Gerade aufgrund dieser Eigenschaft der asymmetrischen Verschlüsselung ist es für uns nicht schwer zu verstehen, dass auch die SSH-Kommunikation diese Eigenschaft nutzt, um die Datensicherheit zu gewährleisten. Auf der Serverseite gibt es außerdem ein Paar aus öffentlichen und privaten Schlüsseln, dessen Zweck ebenfalls das Verschlüsseln und Entschlüsseln von Daten ist. Der Prozess der verschlüsselten SSH-Kommunikation läuft ungefähr so ​​ab: Wenn der Client die Kommunikation mit dem Server verschlüsseln möchte, muss der Client zunächst den öffentlichen Schlüssel des Servers erhalten. Nachdem er den öffentlichen Schlüssel des Servers erhalten hat, kann er die zu sendenden Daten mit dem öffentlichen Schlüssel des Servers verschlüsseln und dann an den Server senden. Wenn der Server die verschlüsselten Daten empfängt, verwendet er seinen eigenen privaten Schlüssel, um sie zu entschlüsseln, wodurch die Datenverschlüsselung vom Client zum Server realisiert wird. Ebenso ist der Vorgang, mit dem der Server Daten an den Client sendet, derselbe. Er erhält den öffentlichen Schlüssel des Clients, verschlüsselt sie mit dem öffentlichen Schlüssel des Clients und sendet sie dann an den Client. Der Client entschlüsselt sie mit seinem eigenen privaten Schlüssel und erreicht so eine verschlüsselte Kommunikation zwischen Ihnen und mir.

Bedenken wir, dass Server und Client bei der Kommunikation den öffentlichen Schlüssel des jeweils anderen verwenden, um Daten zu verschlüsseln. Wie erhält also der Client den öffentlichen Schlüssel des Servers? Wie erhält der Server den öffentlichen Schlüssel des Clients?

Sehen wir uns den Prozess des öffentlichen Schlüsselaustauschs an, wenn Server und Client zum ersten Mal eine Verbindung herstellen.

Zuerst sendet der Client eine SSH-Verbindungsanforderung an den Server. Nach Erhalt der Anforderung sendet der Server seinen öffentlichen Schlüssel und seine Sitzungs-ID an den Client. Nachdem der Client den öffentlichen Schlüssel vom Server erhalten hat, führt er eine XOR-Operation für seinen eigenen öffentlichen Schlüssel mit der vom Server gesendeten Sitzungs-ID durch, verschlüsselt das Ergebnis mit dem öffentlichen Schlüssel des Servers und sendet dann den verschlüsselten Geheimtext über das Netzwerk an den Server. Nachdem der Server den vom Client gesendeten Geheimtext erhalten hat, entschlüsselt er ihn mit seinem eigenen privaten Schlüssel und führt dann eine XOR-Operation für das Ergebnis mit der vorherigen Sitzungs-ID durch, um schließlich den öffentlichen Schlüssel des Clients zu erhalten. Nach einem solchen Vorgang verfügt der Client über den öffentlichen Schlüssel des Servers und der Server über den öffentlichen Schlüssel des Clients. Nachdem beide Parteien die öffentlichen Schlüssel des anderen haben, können sie den öffentlichen Schlüssel der anderen Partei später zum Verschlüsseln von Daten verwenden.

Jeder, der schon einmal Linux verwendet hat, weiß, dass wir beim ersten Herstellen einer SSH-Remoteverbindung mit dem Server eine Bestätigung erhalten, in der wir gefragt werden, ob wir die Verbindung fortsetzen möchten. Erst nachdem wir „yes“ eingegeben haben, können wir das Passwort eingeben. Warum mache ich das? Wenn der Server seinen eigenen öffentlichen Schlüssel an den Client sendet, kann der Client nicht bestätigen, ob der empfangene öffentliche Schlüssel vom anderen Server gesendet wurde. Daher führt er MD5 und SHA256 für den empfangenen öffentlichen Schlüssel aus, extrahiert den Fingerabdruck des öffentlichen Schlüssels und fordert uns dann auf, zu sagen, dass ich einen öffentlichen Schlüssel mit MD5 als xxx erhalten habe. Bestätigen Sie diesen öffentlichen Schlüssel? Wenn wir bestätigen, bedeutet dies, dass wir davon ausgehen, dass dieser öffentliche Schlüssel vom Server gesendet wurde. Auf diese Weise können wir Folgendes tun: XOR unseres eigenen öffentlichen Schlüssels und unserer Sitzungs-ID und das Ergebnis mit dem gerade empfangenen öffentlichen Schlüssel verschlüsseln. Wir stellen uns vor, dass der öffentliche Schlüssel nicht vom Server, sondern vom Hacker gesendet wird und wir dies bestätigen. Nachdem der Hacker den nachfolgenden Geheimtext erhalten hat, verwendet er seinen eigenen privaten Schlüssel, um ihn zu entschlüsseln und den öffentlichen Schlüssel und die Daten des Clients zu erhalten. Nachdem er die tatsächlichen Daten erhalten hat, kann der Hacker sie nach Belieben ändern und sie dann mit dem öffentlichen Schlüssel des Servers verschlüsseln und an den Server senden. Auf diese Weise sind die vom Server erhaltenen Daten die vom Hacker geänderten Daten und nicht die vom Client gesendeten tatsächlichen Daten. Dies wird als Man-in-the-Middle-Angriff bezeichnet, bei dem der eigene öffentliche Schlüssel verwendet wird, um abwechselnd die Server- und Client-Rollen zu übernehmen.

Nachdem wir nun den Prozess der verschlüsselten SSH-Kommunikation und des Schlüsselaustauschs verstehen, werfen wir einen Blick auf den Prozess der SSH-Anmeldeüberprüfung basierend auf Benutzername, Passwort und Schlüssel.

Der Anmeldevorgang basierend auf Benutzername und Passwort läuft wie folgt ab: Zuerst initiiert der Client eine SSH-Verbindungsanforderung, und der Server sendet seinen öffentlichen Schlüssel an den Client. Nachdem der Client den öffentlichen Schlüssel des Servers erhalten hat, verschlüsselt er das Passwort mit dem öffentlichen Schlüssel des Servers und sendet es an den Server. Der Server empfängt das verschlüsselte Passwort und entschlüsselt es mit seinem eigenen privaten Schlüssel, um das vom Client gesendete Passwort zu erhalten. Anschließend verwendet er dieses Passwort zur Überprüfung, verschlüsselt das Überprüfungsergebnis mit dem öffentlichen Schlüssel des Clients und sendet es an den Client. Nachdem der Client das Ergebnis erhalten hat, entschlüsselt er es mit seinem eigenen privaten Schlüssel und schließt so den Überprüfungsprozess ab. Wenn die Überprüfung erfolgreich ist, meldet sich der Client erfolgreich an, andernfalls schlägt die Client-Anmeldung fehl.

Der Prozess der Schlüsselanmeldeverifizierung ist: Erstens muss der Kunde ein Schlüsselpaar generieren (dieses Schlüsselpaar ist für den Benutzer, nicht der öffentliche Schlüssel und der private Schlüssel des Hosts /Autorized_Keys Datei im Home -Verzeichnis dieses Benutzers) Der Server empfängt die vom Client gesendeten zufälligen Zeichen und vergleichen sie.

Aus der obigen Einführung lässt sich leicht erkennen, dass wir, wenn wir uns basierend auf der Schlüsselüberprüfung anmelden möchten, ein Paar Benutzerschlüsselpaare auf dem Client generieren und den generierten öffentlichen Benutzerschlüssel in die Datei .ssh/authorized_keys im Stammverzeichnis eines Benutzers auf dem Server legen müssen. Diesen Benutzer werden wir in Zukunft zur Schlüsselüberprüfung verwenden, um uns beim Server anzumelden. Lassen Sie uns als Nächstes ein wenig experimentieren.

1. Generieren Sie ein Benutzerschlüsselpaar auf dem Client

[qiuhom@docker ~]$ssh-keygen -t rsa
Generieren eines öffentlichen/privaten RSA-Schlüsselpaars.
Geben Sie die Datei ein, in der der Schlüssel gespeichert werden soll (/home/qiuhom/.ssh/id_rsa):
Passphrase eingeben (leer, wenn keine Passphrase vorhanden ist):
Geben Sie dieselbe Passphrase erneut ein:
Ihre Identifikation wurde in /home/qiuhom/.ssh/id_rsa gespeichert.
Ihr öffentlicher Schlüssel wurde in /home/qiuhom/.ssh/id_rsa.pub gespeichert.
Der Schlüsselfingerabdruck ist:
SHA256:CbICoBfN3670ucEBjhDR/ltyYoe/jJMIWCkCK5Lt5eA qiuhom@docker
Das Randomart-Bild des Schlüssels ist:
+---[RSA 2048]----+
|. += |
|+ o+ |
|++oo..o. |
|Bo=.o=.o.. |
|+*.+o..oS |
|. E.. B.=. |
| . + %o. |
| . =o+. |
| ..+o |
+----[SHA256]-----+
[qiuhom@docker ~]$ll .ssh/
Gesamtdosis 8
-rw------- 1 qiuhom qiuhom 1675 2. November 16:54 id_rsa
-rw-r--r-- 1 qiuhom qiuhom 395 2. November 16:54 id_rsa.pub
[qiuhom@docker ~]$

Hinweis: Unter Linux verwenden wir den Befehl ssh-keygen, um ein Benutzerschlüsselpaar zu generieren. Die Option -t gibt den Verschlüsselungsalgorithmus an, der zum Generieren des Schlüssels verwendet wurde. Das generierte Schlüsselpaar wird standardmäßig im Verzeichnis .ssh/ im Home-Verzeichnis des aktuellen Benutzers abgelegt. Sie heißen id_rsa bzw. id_rsa.pub. Anhand der Namen können wir erkennen, dass id_rsa der private Schlüssel und id_rsa.pub der öffentliche Schlüssel ist. Wenn Sie vorsichtig sind, müssen Sie bemerkt haben, dass wir gefragt werden, wo die Schlüsseldatei gespeichert werden soll, wenn wir ssh-keygen zum Generieren eines Schlüssels verwenden. Standardmäßig ist dies das Verzeichnis .ssh im Stammverzeichnis des aktuellen Benutzers. Natürlich können wir auch die Option -f verwenden, um den Speicherort anzugeben. Darüber hinaus werden wir aufgefordert, ein Kennwort einzugeben. Das Kennwort stellt hier das Kennwort zum Verschlüsseln des privaten Schlüssels dar. Wir alle wissen, dass es sehr gefährlich ist, an den privaten Schlüssel der anderen Partei zu gelangen, daher fordert uns das System standardmäßig dazu auf. Wenn Sie die Eingabetaste drücken, bedeutet dies, dass der generierte private Schlüssel nicht verschlüsselt ist. Natürlich können wir auch die Option -P (Großbuchstaben) verwenden, um das Kennwort zum Verschlüsseln des privaten Schlüssels anzugeben.

2. Legen Sie den vom Benutzer generierten öffentlichen Schlüssel in .ssh/authorized_keys im Stammverzeichnis des Benutzers auf dem Server ab. Wir können den Befehl scp verwenden, um ihn auf dem Server abzulegen, oder ihn über einen USB-Stick kopieren, aber das ist zu mühsam. Hier verwenden wir ein spezielles Tool, ssh-copy-id, um die Informationen zur öffentlichen Schlüsseldatei des Benutzers in das entsprechende Benutzer-Home-Verzeichnis auf dem Server zu kopieren.

[qiuhom@docker ~]$ssh-copy-id -i .ssh/id_rsa.pub [email protected]
/usr/bin/ssh-copy-id: INFO: Quelle des/der zu installierenden Schlüssel: „.ssh/id_rsa.pub“
Die Authentizität des Hosts „192.168.0.151 (192.168.0.151)“ kann nicht festgestellt werden.
Der RSA-Schlüsselfingerabdruck ist SHA256:GuKvtBmWnYyxogf1nyNvp02ccon/doAKhVdF7Qy7PvA.
Der RSA-Schlüsselfingerabdruck lautet MD5:88:cf:f9:df:37:16:d7:e2:c4:99:a4:97:ab:49:f0:8e.
Möchten Sie die Verbindung wirklich fortsetzen (ja/nein)? ja
/usr/bin/ssh-copy-id: INFO: Versuch, sich mit den neuen Schlüsseln anzumelden, um alle bereits installierten herauszufiltern
/usr/bin/ssh-copy-id: INFO: 1 Schlüssel muss noch installiert werden -- wenn Sie jetzt dazu aufgefordert werden, installieren Sie die neuen Schlüssel
Passwort von [email protected]:
 
Anzahl hinzugefügter Schlüssel: 1
 
Versuchen Sie nun, sich mit „ssh ‚[email protected]‘“ beim Computer anzumelden.
und überprüfen Sie, ob nur die gewünschten Schlüssel hinzugefügt wurden.
 
[qiuhom@docker ~]$

Hinweis: Die Option -i gibt den Speicherort der öffentlichen Schlüsseldatei an. Der Standardwert ist .ssh/public key im Home-Verzeichnis des aktuellen Benutzers. Da der Server den öffentlichen Schlüssel des Client-Benutzers nicht hat, bevor wir den öffentlichen Schlüssel kopieren, müssen wir beim Kopieren des öffentlichen Schlüssels des Benutzers das Kennwort zur Überprüfung eingeben. Zu beachten ist hierbei, dass der SSHD-Dienst auf der Serverseite unseres Experiments standardmäßig auf Port 22 funktioniert. Wenn er auf dem Standardport nicht funktioniert, müssen Sie die Option -p (Kleinbuchstaben) verwenden, um den Port anzugeben.

An diesem Punkt haben wir die kennwortfreie, SSH-schlüsselbasierte Anmeldeauthentifizierung abgeschlossen.

Die oben erwähnte Schlüsselgenerierung und -ausgabe erfolgt komplett manuell, sodass mit einem oder zwei Servern kein Problem besteht. Was aber, wenn mehr Server vorhanden sind? Wenn wir viele Server verwalten müssen, müssen wir ein Skript schreiben, um dies zu erledigen. Das Folgende ist ein Skript, das ich geschrieben habe. Die darin implementierte Funktion besteht darin, automatisch einen Schlüssel zu generieren und ihn automatisch an den angegebenen Host zu senden.

[qiuhom@docker ~]$cat ssh_keygen.sh
#!/bin/bash
 
remote_host_ip=$1
remote_host_user=$2
remote_host_port=$3
remote_host_passwd=$4
local_rsa_file=~/.ssh/id_rsa
local_rsa_pub_file=~/.ssh/id_rsa.pub
 
[ $# -ne 4 ] && echo "Verwendung: sh $0 RemotehostIp RemotehostUser RemotehostPort RemotehostPasswd" && exit 5
 
[ ! -e ${local_rsa_file} ] && ssh-keygen -t rsa -P '' -f ${local_rsa_file} >/dev/null 2>&1
 
erwarten << EOF
Zeitüberschreitung einstellen 10
spawn ssh-copy-id -i ${local_rsa_pub_file} $remote_host_user@$remote_host_ip -p $remote_host_port
erwarten {
 "(ja/nein)?" {send "yes\n";exp_continue}
 "Passwort: " {send "$remote_host_passwd\n"}
}
Erwarte EOF
Ende der Laufzeit

Hinweis: Dieses Skript erfordert, dass Sie die IP des Remote-Servers, den Remote-Host-Benutzer, den SSH-Port des Remote-Hosts und das Passwort übergeben. Dieses Skript generiert automatisch Schlüssel und sendet sie an den angegebenen Server. Wenn Sie sie an mehrere Server senden müssen, können Sie ein weiteres Skript schreiben, um dieses Skript aufzurufen und die Funktion der Stapelerstellung und -verteilung von Schlüsseldateien zu erreichen.

prüfen:

Verwenden Sie das Skript, um eine Schlüsseldatei zu generieren und diese an den angegebenen Server zu senden

[qiuhom@docker ~]$ll .ssh/
Gesamtverbrauch 0
[qiuhom@docker ~]$ssh [email protected]
Die Authentizität des Hosts „192.168.0.151 (192.168.0.151)“ kann nicht festgestellt werden.
Der RSA-Schlüsselfingerabdruck ist SHA256:GuKvtBmWnYyxogf1nyNvp02ccon/doAKhVdF7Qy7PvA.
Der RSA-Schlüsselfingerabdruck lautet MD5:88:cf:f9:df:37:16:d7:e2:c4:99:a4:97:ab:49:f0:8e.
Möchten Sie die Verbindung wirklich fortsetzen (ja/nein)? ja
Warnung: „192.168.0.151“ (RSA) wurde dauerhaft zur Liste der bekannten Hosts hinzugefügt.
Passwort von [email protected]:
[root@test ~]#ll .ssh/
Gesamtdosis 4
-rw------- 1 root root 0 2. Nov. 17:43 autorisierte Schlüssel
-rw-r--r-- 1 root root 1202 Okt 31 21:25 known_hosts
[root@test ~]#rm -rf .ssh/*
[root@test ~]#ll .ssh/
Gesamtverbrauch 0
[root@test ~]#Beenden
ausloggen
Verbindung zu 192.168.0.151 geschlossen.
[qiuhom@docker ~]$rm -rf .ssh/*
[qiuhom@docker ~]$sh ssh_keygen.sh 192.168.0.151 root 22 Administrator
spawn ssh-copy-id -i /home/qiuhom/.ssh/id_rsa.pub [email protected] -p 22
/usr/bin/ssh-copy-id: INFO: Quelle des/der zu installierenden Schlüssel: „/home/qiuhom/.ssh/id_rsa.pub“
Die Authentizität des Hosts „192.168.0.151 (192.168.0.151)“ kann nicht festgestellt werden.
Der RSA-Schlüsselfingerabdruck ist SHA256:GuKvtBmWnYyxogf1nyNvp02ccon/doAKhVdF7Qy7PvA.
Der RSA-Schlüsselfingerabdruck lautet MD5:88:cf:f9:df:37:16:d7:e2:c4:99:a4:97:ab:49:f0:8e.
Möchten Sie die Verbindung wirklich fortsetzen (ja/nein)? ja
/usr/bin/ssh-copy-id: INFO: Versuch, sich mit den neuen Schlüsseln anzumelden, um alle bereits installierten herauszufiltern
/usr/bin/ssh-copy-id: INFO: 1 Schlüssel muss noch installiert werden -- wenn Sie jetzt dazu aufgefordert werden, installieren Sie die neuen Schlüssel
Passwort von [email protected]:
 
Anzahl hinzugefügter Schlüssel: 1
 
Versuchen Sie nun, sich mit „ssh -p ‚22‘ ‚[email protected]‘“ beim Computer anzumelden.
und überprüfen Sie, ob nur die gewünschten Schlüssel hinzugefügt wurden.
 
[qiuhom@docker ~]$ll .ssh/
Gesamtdosis 12
-rw------- 1 qiuhom qiuhom 1675 2. November 17:53 id_rsa
-rw-r--r-- 1 qiuhom qiuhom 395 2. November 17:53 id_rsa.pub
-rw-r--r-- 1 qiuhom qiuhom 395 2. November 17:53 known_hosts
[qiuhom@docker ~]$ssh [email protected]
[root@test ~]#ll .ssh/
Gesamtdosis 4
-rw------ 1 root root 395 2. Nov. 17:53 autorisierte Schlüssel
[root@test ~]#cat .ssh/autorisierte_schlüssel
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC6yfNtYfGtwyZLKuffYgFoMZfEnKhpsp1pH3Mky1UGBsUNRGHIhNZzbtVNERWkAV/NndasfHss/vEnDSHVOXRScRfH7pPCNdVdy887WlSgshG6U5UIsQnlxlkUxf0ciVlc9VEw/IIg8eXrlOmcuezadxGc32yHB7o+zkEcg7UBYClDtjp5xqzrHyLDMd5OhGqMPJO+d+OFKqhOOYAUYsUi00aM1qNbf+KHFhYbQQj96UbWRTNQYFnqIJltvDPxqq7W5GGVl0xma6PSgGYMFNwIy9PhJJ8Lxaiaw3FjC8iCWrjzRONbnaqMPqrS8wQXs95vRDi2M0egKUuRlzFjGAGB qiuhom@docker
[root@test ~]#Beenden
ausloggen
Verbindung zu 192.168.0.151 geschlossen.
[qiuhom@docker ~]$cat .ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC6yfNtYfGtwyZLKuffYgFoMZfEnKhpsp1pH3Mky1UGBsUNRGHIhNZzbtVNERWkAV/NndasfHss/vEnDSHVOXRScRfH7pPCNdVdy887WlSgshG6U5UIsQnlxlkUxf0ciVlc9VEw/IIg8eXrlOmcuezadxGc32yHB7o+zkEcg7UBYClDtjp5xqzrHyLDMd5OhGqMPJO+d+OFKqhOOYAUYsUi00aM1qNbf+KHFhYbQQj96UbWRTNQYFnqIJltvDPxqq7W5GGVl0xma6PSgGYMFNwIy9PhJJ8Lxaiaw3FjC8iCWrjzRONbnaqMPqrS8wQXs95vRDi2M0egKUuRlzFjGAGB qiuhom@docker
[qiuhom@docker ~]$

Hinweis: Sie können sehen, dass Sie vor der Ausführung unseres Skripts das Kennwort manuell eingeben müssen, um sich beim Server anzumelden. Nachdem wir das Skript ausgeführt haben, wird die Benutzerschlüsseldatei erstellt und die öffentliche Benutzerschlüsseldatei an den entsprechenden Server gesendet.

Zusammenfassung: Die schlüsselbasierte SSH-Authentifizierung bietet folgende Vorteile

1. Sicherer und bequemer. Wir müssen uns weder umständliche Benutzerkennwörter merken, noch müssen wir uns über Kennwortlecks Gedanken machen. (Wir können den SSHD-Dienst so konfigurieren, dass er nur die Anmeldung basierend auf der KEY-Authentifizierung zulässt.)

2. Die passwortlose Anmeldung basierend auf der Schlüsselüberprüfung ermöglicht den Remote-Batch-Betrieb von Servern, was für das Schreiben von Skripten praktisch ist und es so einfach macht, wie Befehle lokal auszuführen, wenn wir Remote-Betriebsbefehle (wie scp, ssh) ausführen.

3. Verhindern Sie effektiv die Gefahr des Erratens von Passwörtern mit Brute-Force-Methoden.

Zusammenfassen

Oben ist der vom Herausgeber vorgestellte Prozess der Schlüsselauthentifizierungspraxis des SSH-Dienstes im Linux-System. Ich hoffe, er wird für alle hilfreich sein!