✍🏻 👨‍👨‍👧 ⛔️ Sicherere SSH-Konnektivität mit DNSSEC 🧖🏼 👨🏾‍🚒 👨🏻

Jeder, der SSH verwendet, weiß, dass beim ersten Herstellen einer Verbindung zum Server eine Meldung angezeigt wird, die den Fingerabdruck des Schlüssels bestätigt. Außerdem wird der Schlüssel auf der Clientseite gespeichert, und diese Meldung wird erst wieder angezeigt, wenn der gespeicherte Schlüssel geändert wird. Aber was ist die praktische Bedeutung dieses Verfahrens?

Im wirklichen Leben überprüft fast niemand den Fingerabdruck des SSH-Schlüssels des Servers, ohne wirklich über die Möglichkeit von MiTM-Angriffen nachzudenken. Mit dem Aufkommen des SSHFP-DNS-Eintrags kann der Fingerabdruck des Serverschlüssels in DNS gespeichert und mit DNSSEC authentifiziert werden. In diesem Fall müssen Sie den Schlüssel bei der ersten Verbindung nicht einmal bestätigen. Dieser Artikel zeigt Ihnen, wie Sie einen SSHFP-Eintrag für Ihren SSH-Server konfigurieren.

Server testen

Zunächst benötigen wir einen Server. Im RuVDS-Bereich befinden sich die Details für den SSH-Zugriff sofort auf der Serverkarte. Wir speichern die IP-Adresse und das Passwort für die Verbindung.

Sie können die Firewall auch direkt über die Systemsteuerung konfigurieren, um den SSH-Zugriff nur für Ihre IP-Adresse zuzulassen.

Um SSHFP zu konfigurieren, muss eine Domäne an die IP-Adresse des Servers geleitet werden. Wir konfigurieren DNS-Einträge für diese Domäne.

Wie Schlüssel in SSH funktionieren

In den Beispielen wird nur das OpenSSH-Paket betrachtet, da dies die beliebteste Option ist.

Bei der Installation eines neuen Servers werden zufällige SSH-Schlüssel generiert. Dies geschieht normalerweise sofort bei der Installation des OpenSSH-Pakets oder beim ersten Start, wenn vorgefertigte Systemabbilder verwendet werden.

Schlüsseldateien befinden sich hier:

$ ls -la /etc/ssh/ssh_host_*_key*

/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_dsa_key.pub
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key.pub

In dieser Liste gibt es mehrere Schlüssel verschiedener Typen gleichzeitig: dsa, rsa, ecdsa, ed25519. Dies erfolgt aus Gründen der Kompatibilität mit verschiedenen SSH-Clients. In der Verbindungsphase vereinbaren Client und Server, welcher Schlüsselalgorithmus verwendet wird. Der Client kann den Server auffordern, einen anderen Algorithmus zu verwenden, wenn der vorgeschlagene nicht unterstützt wird. Der Server sendet den öffentlichen Teil seines Schlüssels an den Client und der Benutzer wird aufgefordert, seinen Fingerabdruck manuell zu überprüfen.

Der Server sendet den Fingerabdruck des öffentlichen Schlüssels zum Zeitpunkt der Verbindung an den Client.

Wenn dies die erste Verbindung ist, wird dem Client eine Meldung mit der Aufforderung angezeigt, den Fingerabdruck manuell zu überprüfen:

The authenticity of host 'example.com (123.45.67.89)' can't be established.
ECDSA key fingerprint is SHA256:7Q4nIqjuo/lSXWFkt9RaJYVHrT6LUAc6KWrdQ4/DDeA.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

In diesem Stadium klicken wir normalerweise alle ohne zu zögern auf Ja und der Fingerabdruck des Schlüssels wird in einer Datei gespeichert ~/.ssh/known_hosts. Wenn sich nun der Schlüssel auf dem Server ändert, wird dem Client eine Meldung über einen möglichen MiTM-Angriff angezeigt. Es wird davon ausgegangen, dass der Kunde zum ersten Mal selbst eine Schlüsselprüfung durchgeführt und deren Echtheit überprüft hat.

Dieser Ansatz ist ziemlich riskant, denn wenn es dem Angreifer gelungen ist, den Moment der ersten Verbindung zu nutzen, kann er seinen Schlüssel ablegen und die Verbindung abfangen. Im Fall von c HTTPS haben wir einen Dritten, der den Serverschlüssel mit einem Zertifikat bestätigt. Wenn der gleiche Ansatz wie bei SSH im Web verwendet würde, würden wir ständig von Schlüsselüberprüfungsnachrichten gequält und MiTM-Angriffe würden überall stattfinden, da niemand die Schlüssel überprüfen würde, sondern einfach immer zustimmen würde.

Wir speichern einen Schlüsseldruck in DNS. Was sind SSHFP-Einträge?

Wie kann man herausfinden, dass der vom Server vorgeschlagene SSH-Schlüssel wirklich echt ist und dies kein MiTM-Angriff ist? Um den Server zu betreten und den Schlüssel zu überprüfen, müssen Sie zuerst das Kennwort eingeben. Aber dann kann der Angreifer den Server sofort hacken und alle darauf befindlichen Daten ersetzen, so dass wir den Haken nicht bemerken. Daher benötigen wir eine Möglichkeit, die Authentizität des Schlüssels vor der tatsächlichen Verbindung zu überprüfen.

Lange Zeit bestand die einzige Möglichkeit, den SSH-Schlüssel des Servers vor dem Herstellen einer Verbindung zu überprüfen, darin, einen anderen Kanal zu verwenden. Bitten Sie beispielsweise den Serveradministrator, den Fingerabdruck des Serverschlüssels anzugeben. Dies ist unpraktisch, daher ist es einfacher, das Problem zu ignorieren und immer ohne zu zögern zuzustimmen.

SSHFP ermöglicht die Serverschlüsselauthentifizierung, bevor eine Verbindung über SSHFP- DNS hergestellt wird

- Art der DNS-Einträge zum Speichern von SSH-Schlüsseln. Der Fingerabdruck des SSH-Schlüssels wird wie ein TXT-Eintrag auf dem DNS-Server abgelegt und mit dem DNSSEC-Schlüssel signiert. Das heißt, wenn der Client zum ersten Mal unter Verwendung des Hostnamens eine Verbindung zum Server herstellt, kann er den Fingerabdruck des Serverschlüssels über DNS im Voraus erkennen. Wenn er mit dem vorgeschlagenen Server übereinstimmt, kann er ohne Vorwarnung eine Verbindung herstellen .

Konfigurieren Sie DNSSEC

Um SSHFP verwenden zu können, benötigen Sie einen Domänennamen mit konfiguriertem DNSSEC. Es gibt viele öffentliche DNS-Dienste, die mit der DNSSEC-Funktion sofort ein DNS-Kontrollfeld anbieten. Der beliebteste derartige Dienst ist CloudFlare. Betrachten Sie die Konfiguration anhand seines Beispiels. Für die folgenden Schritte muss die Domäne an den Cloudflare NS-Server delegiert werden.

▍Schritt 1 - Generieren Sie einen Schlüssel

Gehen Sie zum DNS-Bereich -> DNSSEC aktivieren.

Zu diesem Zeitpunkt werden Schlüssel generiert, um Ihre Domain-Zone zu signieren. Ihnen werden die öffentlichen Schlüssel angezeigt. Sie müssen auf der Seite des Domain-Registrars hinzugefügt werden.

▍Schritt 2 - Hinzufügen öffentlicher Schlüssel zum Registrar

Als Nächstes müssen Sie DS-Einträge mit dem öffentlichen Schlüssel vom Domain-Registrar erstellen.
Abhängig von Ihrem Registrar kann die DNSSEC-Schnittstelle zum Hinzufügen von Schlüsseln unterschiedlich aussehen. Es ist wichtig, die Werte nicht zu verwechseln, da sie unterschiedlich benannt werden können und sich von den in CloudFlare angezeigten Namen unterscheiden.

Das folgende Beispiel zeigt, wie sich die im CloudFlare-Bereich angezeigten Werte auf die Werte im Domänensteuerungsfeld des Uniregistry-Registrars beziehen.

▍Schritt 3 - Überprüfen Sie die hinzugefügten DS-Datensätze

Nachdem Sie DS-Datensätze auf der Seite des Registrars hinzugefügt haben, können Sie überprüfen, ob die Einstellungen korrekt sind. Auf der CloudFlare-Seite wird das Signieren von DNS-Einträgen nur aktiviert, wenn die Überprüfung der Richtigkeit des Hinzufügens von DS-Einträgen auf der Seite des Registrars bestanden wurde.

Warten auf das Hinzufügen von DS-Datensätzen

Wenn die Datensätze nach einigen Minuten oder Stunden korrekt hinzugefügt wurden, wird eine solche Meldung angezeigt. Dies bedeutet, dass DNS-Antworten jetzt mit DNSSEC signiert werden.

▍Schritt 4 - Überprüfen Sie den DNSSEC-Betrieb

Jetzt können Sie den Betrieb von DNSSEC auf unserer Domain mit Onlinediensten wie dnssec-analyzer.verisignlabs.com testen . Alle Häkchen sollten grün sein.

Ergebnis der DNSSEC-Validierung

Hinzufügen von SSHFP-Einträgen

Wir werden SSHFP-Datensätze auf dem Server generieren. In unserem Beispiel verwalten wir einen Server mit der Adresse myserver.com . Für diesen Domainnamen haben wir zuvor DNSSEC konfiguriert.

Führen Sie auf dem Server den folgenden Befehl aus:

#   SSHFP   SSH-
sudo ssh-keygen -r myserver.com

myserver.com IN SSHFP 1 1 057ecce168ace29d5a0099e3b63df2850e4c8e20
myserver.com IN SSHFP 1 2 52cd6099a304b9b8f57f2cd914e96a1b7477eb2f88c98c602
myserver.com IN SSHFP 2 1 42d677482e4450ee515d3aac94d96302a99bd4ec
myserver.com IN SSHFP 2 2 edda5fa445dc0da570c772a6df0d4012037e1a102840d29c4
...

Für alle Schlüssel werden Fingerabdrücke aus dem Ordner / etc / ssh / generiert . Sie können selektiv Fingerabdrücke für bestimmte Schlüssel generieren, indem Sie den Dateipfad angeben.

Jetzt müssen alle diese Einträge im DNS-Bereich hinzugefügt werden, in unserem Fall Cloudflare.

Hinzufügen eines SSHFP-Datensatzes zum Cloudflare-Bedienfeld

Sie müssen also alle im vorherigen Schritt erhaltenen Schlüssel hinzufügen. Jetzt können Sie überprüfen, ob die Schlüssel hinzugefügt wurden:

dig SSHFP myserver.com

In der Antwort sollten alle hinzugefügten Schlüssel angezeigt werden. Das Signieren neuer Einträge kann einige Zeit dauern, sodass die Schlüssel in der Antwort möglicherweise nicht sofort angezeigt werden. Dies dauert normalerweise nicht länger als 10-15 Minuten.

Stellen Sie eine Verbindung zum Server her

Damit der SSH-Client die Gültigkeit der Schlüssel über DNS überprüfen kann, müssen Sie dies in den Einstellungen aktivieren. Die Client-Konfiguration befindet sich im Home-Ordner des Benutzers. Fügen Sie dort eine Zeile hinzu.

#  
vi ~/.ssh/config

VerifyHostKeyDNS yes

Jetzt können Sie eine Verbindung zum Server herstellen. Für die Reinheit des Experiments können Sie die Zeile mit dem Fingerabdruck aus ~ / .ssh / unknown_hosts entfernen . Aus Gründen der Übersichtlichkeit können Sie die Option -v hinzufügen

#   
ssh -v root@myserver.com


# DNS  ,  SSHFP 
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
.....
DNS lookup error: data does not exist

# DNS  ,   
#    DNSSEC
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
....
debug1: found 8 insecure fingerprints in DNS
debug1: matching host key fingerprint found in DNS


# DNS  ,    DNSSEC
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
....
debug1: found 8 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
debug1: ssh_rsa_verify: signature correct

Wenn alles richtig konfiguriert ist, werden Sie beim ersten Herstellen einer Verbindung zum Server nicht aufgefordert, den Fingerabdruck des Schlüssels manuell zu überprüfen. Dies erfordert auch, dass der System-DNS-Resolver die DNSSEC-Validierung unterstützt.

Es ist wichtig zu beachten, dass SSHFP nur funktioniert, wenn über einen Domänennamen eine Verbindung zu einem Server hergestellt wird, und nicht, wenn eine Verbindung über IP oder eine andere Domäne ohne SSHFP-Einträge besteht.

Sicherere SSH-Konnektivität mit DNSSEC