Gastbeitrag von Manfred Kaiser
In den letzten Monaten wurden mehrere Sicherheitslücken in unterschiedlichen Applikationen gefunden, die einen Man in the Middle Angriff auf SSH ermöglichen.
Eine der aktuellsten Sicherheitslücken betrifft Cargo, den Package Manager von Rust. Durch eine fehlende Fingerprint-Überprüfung wird die Authentizität des Hosts nicht verifiziert und beim Abrufen von Abhängigkeiten über SSH kann es zu sogenannten Supply-Chain-Angriffen kommen.
Solche Supply-Chain-Angriffe ermöglichen es, eine Software bereits bei der Entwicklung bzw. beim Deployment zu kompromittieren und Ransomware oder anderen Schadcode in eine Applikation einzuschleusen.
Aus diesem Grund wird in einer dreiteiligen Artikelserie beschrieben, wie Man-in-the-Middle-Angriffe auf SSH funktionieren und welche Techniken von Angreifern verwendet werden.
Diese Artikelserie beginnt mit der Fingerprint-Überprüfung, weil diese die erste Sicherheitsfunktion von SSH darstellt, mit dem die Anwender in Kontakt kommen. Im zweiten Teil werden die Authentifizierungsmethoden aus Sicht eines Man in the Middle Angriffs beschrieben. Der abschließende dritte Teil beschäftigt sich mit Szenarien für Man-in-the-Middle-Angriffe und zeigt auch Maßnahmen zur Abwehr auf.
SSH Fingerprint Überprüfung
SSH verwendet eine asymmetrische Verschlüsselung, bei der ein öffentlicher Schlüssel und ein privater Schlüssel verwendet. Dies ist der sogenannte Host-Key des Servers.
Die Fingerprints werden aus dem öffentlichen Schlüssel des Host-Keys generiert und stellen das primäre Sicherheitsmerkmal bei SSH Verbindungen dar. Jeder Server besitzt ein eigenes Schlüsselpaar, das nicht bei anderen Servern wiederverwendet werden darf.
Bei den Fingerprints handelt es sich in den meisten Fällen um den SHA256 Hash Wert des öffentlichen Schlüssels. Ältere Clients verwenden MD5 als Hash-Verfahren, was jedoch aufgrund der erhöhten Kollisionsgefahr nicht mehr verwendet werden sollte. Vereinzelt sind auch andere Hash Verfahren, wie z. B. SHA512 anzutreffen, welche in der Praxis jedoch keine Relevanz haben.
Nur durch die Überprüfung des Fingerprints kann sichergestellt werden, dass sich der Client mit dem richtigen Server verbindet. Entfällt die Überprüfung bzw. wird diese nicht richtig durchgeführt, besteht das Risiko eines Man in the Middle Angriffs.
Die Überprüfung kann manuell durch den Anwender oder automatisch durch den Client erfolgen. Bei den meisten Clients erfolgt die erste Überprüfung durch den Anwender. Sofern ein Fingerprint bekannt ist, werden bei zukünftigen Verbindungen diese automatisch überprüft. Sollten sich diese geändert haben, wird eine Warnung ausgegeben und die Verbindung wird beendet.
Verbindet man sich zum ersten Mal mit einem Server, wird der Fingerprint angezeigt und man wird gefragt, ob man diesem vertraut oder nicht. Neuere OpenSSH Versionen bieten in solchen Fällen die Möglichkeit einen bekannten Fingerprint einzugeben, um Fehler bei der manuellen Überprüfung auszuschließen.
Folgendes Beispiel zeigt einen Verbindungsaufbau zu „github.com“.
tux@devbox:~$ ssh github.com
The authenticity of host 'github.com (140.82.121.3)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
Der Fingerprint selbst sollte immer über eine vertrauenswürdige Quelle bereitgestellt werden. Im Falle von Github wird dieser auf der Webseite selbst zur Verfügung gestellt. Dadurch, dass die Webseite mittels HTTPS gesichert ist und ein gültiges Zertifikat aufweist, ist sicheres Abrufen des SSH Fingerprints für jeden möglich.
Ist der Fingerprint jedoch bekannt, wird dem Anwender eine Warnung vor einem möglichen Man in the Middle Angriff angezeigt, falls sich der Fingerprint geändert hat.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:2iJAHZZHlYMrlrBGw3t7Ma62TuZ0p7p+av3O4W+cpHY.
Please contact your system administrator.
Add correct host key in /home/tux/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/tux/.ssh/known_hosts:6
remove with:
ssh-keygen -f "/home/tux/.ssh/known_hosts" -R 140.82.121.3
ED25519 host key for 140.82.121.3 has changed and you have requested strict checking.
Host key verification failed.Bei SSH wird oft argumentiert, dass es sich um einen Anwenderfehler handelt, wenn der Fingerprint nicht entsprechend geprüft wird. Jedoch kann eine Applikation Sicherheitslücken besitzen, mit denen selbst ein sorgsamer Anwender von einem Man in the Middle Angriff betroffen sein kann.
Fehlerhafte Fingerprint Überprüfung im Client
In den letzten Monaten wurden bei Audits mehrere SSH-Clients identifiziert, die aufgrund von Sicherheitslücken anfällig für Man-in-the-Middle-Angriffe sind. Insbesondere, wenn ein Client eine Fehlfunktion bei der Überprüfung des Fingerprints aufweist, kann dies gravierende Auswirkungen auf die Sicherheit haben.
Package Manager “Cargo” – CVE-2022-46176
Der aktuellste Fall betrifft den Package Manager Cargo von Rust. Cargo besitzt die Möglichkeit, Abhängigkeiten aus einem Git Repository über SSH zu beziehen.
Ein Entwickler, der zum Beispiel ein Git Repository auf Github für sein Projekt verwendet, muss beim ersten Verbindungsaufbau mittels Git über SSH den Fingerprint von Github überprüfen und akzeptieren. Wurde der Fingerprint das erste Mal ordnungsgemäß überprüft, geht man davon aus, dass in Zukunft die Verbindung zu Github sicher ist.
Durch die fehlende Fingerprint-Überprüfung in Cargo bemerkt der Entwickler jedoch nicht, wenn er von einem Man in the Middle Angriff betroffen ist und dass die Abhängigkeiten von einem fremden Server bezogen werden.
SSH Client von MobaXterm – CVE-2022-38336
Der SSH Client MobaXterm ist durch eine unsichere Fingerprint-Überprüfung anfällig für Man-in-the-Middle-Angriffe. Die Fingerprint-Überprüfung ist standardmäßig deaktiviert, wodurch der Fingerprint beim ersten Verbindungsaufbau nicht überprüft, sondern automatisch akzeptiert wird. Bei zukünftigen Verbindungen werden jedoch bereits bekannten Fingerprints überprüft.
Erschwerend kommt bei MobaXterm hinzu, dass der SSH-Agent standardmäßig an den Server durchgereicht wird. Dieser kann somit bei einem Man in the Middle Angriff für die Anmeldung an andere Server verwendet werden.
Midnight Commander – CVE-2021-36370
Bei der SFTP Implementierung des Midnight Commanders wurde zwar der Fingerprint berechnet, es fehlte aber die konkrete Prüfung, ob der Fingerprint auch bekannt ist. Diese Sicherheitslücke wurde erst nach 9 Jahren entdeckt und behoben.
Ein weiteres Problem war unter anderem auch, weil der Midnight Commander mit FISH (file transfer over shell protocol) eine weitere Methode für Dateitransfers unterstützt, die im Hintergrund den OpenSSH Client benutzt.
Wurde eine Verbindung mittels FISH hergestellt, wurde wie erwartet der Fingerprint überprüft und bei unbekannten Fingerprints der Anwender gefragt. Verbindet man sich jedoch anschließend mit dem integrierten SFTP Client, könnte man davon ausgehen, dass der Fingerprint in diesem Fall gegen den bereits bekannten Fingerprint überprüft wird. Durch die fehlende Überprüfung wurde jedoch keine Warnung ausgegeben, falls sich der Fingerprint geändert haben sollte.
Ignorieren des Fingerprints durch den Anwender
Der Verwendung von Fingerprints bei der Überprüfung von SSH-Verbindungen stellt für viele Anwender eine Herausforderung dar. Es ist leider häufig der Fall, dass Anwender die Bedeutung von Fingerprints nicht verstehen und entsprechende Überprüfungen nicht durchführen. Studien, wie die von Peter Gutmann (Do Users Verify SSH Keys?) und Konrad Rieck (Fuzzy Fingerprints Attacking Vulnerabilities in the Human Brain, 2002), zeigen, dass Anwender den Fingerprint in den meisten Fällen nicht überprüfen.
Eine weitere Schwierigkeit besteht darin, dass es nicht immer eine vertrauenswürdige Quelle gibt, gegen die der Fingerprint verglichen werden kann. Auch die Verfügbarkeit von Fingerprints über sichere Kanäle kann eine Herausforderung darstellen, selbst wenn ein Anwender den Fingerprint überprüfen möchte.
Eine weit verbreitete Fehlannahme ist, dass bei SSH-Servern innerhalb eines internen Netzes keine Fingerprint-Überprüfung erforderlich ist. Dies ist jedoch ein falscher Ansatz, da eine Kompromittierung eines solchen Services weitreichende Folgen für die gesamte Infrastruktur haben kann. Es ist daher wichtig, auch bei internen Services die Überprüfung von Fingerprints sorgfältig durchzuführen.
Fuzzy Fingerprints – Ähnlichen Fingerprints
Eine Überprüfung des Fingerprints eines Servers ist wichtig, um sicherzustellen, dass keine unautorisierten Zugriffe auf den Server stattfinden. Konrad Rieck beschreibt in seiner Arbeit “Fuzzy Fingerprints Attacking Vulnerabilities in the Human Brain” (2002), wie Angreifer dazu verleitet werden können, einen falschen Fingerprint zu akzeptieren.
Während ältere Clients noch die Verwendung von MD5 für Fingerprints nutzen, ist dies aufgrund von Hash-Kollisionen nicht länger sicher. Aus diesem Grund wird SHA256 als sicherere Alternative immer häufiger eingesetzt. Obwohl SHA256 kollisionsresistenter ist, führt es zu längeren und komplexeren Fingerprints, die von Anwendern schwieriger zu überprüfen sind.
Laut Konrad Riecks Arbeit vergleichen die meisten Anwender nur den Anfang und das Ende eines Hash-Wertes, während erfahrene Anwender auch Teile in der Mitte überprüfen. Nur wenige vergleichen den kompletten Hash-Wert. Basierend auf diesen Beobachtungen ist es möglich, Fingerprints zu generieren, die dem Original-Fingerprint ähnlich sind, indem das beobachtete Verhalten der Anwender in die Generierung des Fingerprints einbezogen wird.
Da viele Anwender nur den Anfang und das Ende des Fingerprints überprüfen, ist es besonders wichtig, dass diese Teile der gleichen Bytefolge wie das Original entsprechen. Teile in der Mitte werden weniger oft überprüft und müssen daher nicht zwingend gleich sein.
Um den Fingerprint zu verbessern, können zusätzlich noch ähnliche Zeichen verwendet werden, die in der Confusion Map gewichtet werden. Je umfangreicher der Zeichensatz ist, desto einfacher ist es, einen optisch ähnlichen Fingerprint zu finden. Je höher die Verwechslungsgefahr ist, desto höher ist die Gewichtung des ähnlichen Zeichens als Ersatz für das richtige Zeichen in einem Fingerprint.
Eine Studie von Sergey Dechand et al, namens “An Empirical Study of Textual Key-Fingerprint Representations” von 2016, zeigte, dass bei Verwendung einer hexadezimalen Darstellung in über 10% der Angriffe der falsche Fingerprint nicht erkannt wurde. Andere Darstellungsmethoden, wie Base32, weisen eine geringfügig bessere Fehlerrate von 8,5% auf.
Es wurde jedoch nicht untersucht, wie sich Base64, das bei SHA256 Fingerprints verwendet wird, auswirkt, weshalb hierzu keine Aussage getroffen werden kann.
Erkennen von Clients, mit bekannten Fingerprints
Ein Angreifer kann bereits vor der Fingerprint-Überprüfung herausfinden, ob ein Client für einen Man in the Middle Angriff anfällig ist oder nicht. Dies ermöglicht es, Verbindungen nur von Clients anzunehmen, die keine entsprechende Fingerprint-Überprüfung durchführen.
Ist der Client bereits im Besitz eines Fingerprints, wird der empfangene Fingerprint mit diesem verglichen. Stimmen die Fingerprints nicht überein, wird eine Warnung ausgegeben und die Verbindung wird abgebrochen. Es muss in weiterer Folge davon ausgegangen werden, dass der Man in the Middle Angriff aufgeflogen ist.
Ein Man in the Middle Angriff sollte jedoch so lange wie möglich unerkannt bleiben. Aus diesem Grund ist es notwendig, die vom Client generierten Warnungen zu verhindern.
Im RFC-4253 wird definiert, wie der Schlüsselaustausch funktioniert. Es wird eine Liste der unterstützen Algorithmen an den Server gesandt. Der erste Eintrag definiert den bevorzugten Algorithmus.
Sofern der Client den RFC entsprechend umsetzt, kann dieses Verhalten dazu benutzt werden, um herauszufinden, ob bereits ein Fingerprint für die aktuelle Verbindung gespeichert ist oder nicht.
Bei einem Man in the Middle Angriff kann dieses Wissen dazu benutzt werden, um Clients, die eine Warnung ausgeben würden, zu ignorieren bzw. die Verbindung an den eigentlichen Zielserver durchzureichen ohne die Verbindung zu unterbrechen.
Ein exemplarischer Schlüsselaustausch mit und ohne bekannten Fingerprint könnte folgendermaßen aussehen.
| Unbekannter Fingerprint | Bekannter 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 |
Ist der Fingerprint nicht bekannt, wird die Liste mit einer vordefinierten Reihenfolge an den Server geschickt. Hat der Client jedoch bereits einen Fingerprint für den Server gespeichert, wird der zuletzt verwendete Algorithmus an erster Stelle gesetzt.
Testen mit SSH-MITM
SSH-MITM ist ein Audit Tool für SSH Verbindungen. Mit diesem Tool ist es möglich, Verbindungen mitzulesen und zu manipulieren. Es enthält auch entsprechende Checks, mit denen Clients auf bekannte Sicherheitslücken überprüft werden können.
Die aktuellste Version von SSH-MITM kann von Github bezogen werden. Es stehen Versionen für Linux als auch Windows zur Verfügung: https://github.com/ssh-mitm/ssh-mitm/releases/latest/
Unter Linux muss die Datei ssh-mitm-x86_64.AppImage verwendet werden.
Nach einem Download kann SSH-MITM mit folgenden Kommandos ausgeführt werden. Standardmäßig verbindet sich SSH-MITM zu einem lokal installierten SSH Server auf Port 22, was für viele Client Tests ausreichend ist.
tux@devbox:~$ chmod +x ssh-mitm-x86_64.AppImage
tux@devbox:~$ ssh-mitm server
SSH-MITM besitzt die Möglichkeit, bei einer eingehenden Verbindung zu prüfen zu prüfen, ob ein Client einen bekannten Fingerprint besitzt oder nicht. Dieses Wissen könnte von einem Angreifer dazu missbraucht werden die Verbindung zu beenden, bevor der Client eine entsprechende Warnung ausgibt. Für den Client sieht es anschließend so aus, als ob die Verbindung aufgrund eines Netzwerkfehlers abgebrochen ist.
Ein SSH Client, kann sich anschließend auf Port 10022 verbinden:
tux@devbox:~$ ssh -p 10022 localhost Wie in Abbildung 2 zu sehen, wird der Name des Clients ausgegeben. Dieser gibt Aufschluss darüber ,welche Version des Clients verwendet wird und es werden auch allgemeine Informationen zu dem Client ausgegeben.
Interessant ist der Hinweis „client connecting for the first time or using default key order!“ und dass der Client als Server Host-Key Algorithm „ssh-ed25519-cert-v01@openssh.com“ bevorzugt.
Verbindet sich der Client anschließend ein weiteres Mal mit SSH-MITM, sollte erkannt werden, dass der Client bereits einen Fingerprint für diesen Server gespeichert hat und SSH-MITM gibt eine entsprechende Meldung aus, wie in Abbildung 3 zu sehen ist. Darüber hinaus wird vom Client als Host-Key Algorithmus „rsa-sha2-512-cert-v01@openssh.com“ bevorzugt. Der Grund ist, dass SSH-MITM standardmäßig einen RSA Schlüssel generiert und diese Information beim ersten Verbindungsaufbau vom Client gespeichert wird.
Verhindern der Erkennung eines gespeicherten Fingerprints
Auch wenn die Information, ob der Client eine Warnung ausgeben wird oder nicht, bei einem Man in the Middle Angriff einen Vorteil bringt, ist es nicht empfehlenswert, dies für alle Verbindungen zu verhindern.
Das OpenSSH Team begründet dies damit, dass eine Änderung des Verhaltens mehr Sicherheitsprobleme verursachen kann als wenn ein Angreifer diese Information zu seinem Vorteil nutzen kann.
Seit OpenSSH 8.4 gibt es die Funktion, dass der Client bei mehreren Host-Keys immer den sichersten Algorithmus wählt und die Liste der gespeicherten Fingerprints wird automatisch aktualisiert. Eine Änderung der Standardkonfiguration kann dazu führen, dass dem Anwender eventuell eine unbegründete Warnung vor geänderten Host-Keys angezeigt wird, obwohl mit einem anderen Algorithmus dieser bereits bekannt gewesen wäre.
Falls es gewünscht ist, kann in OpenSSH und in PuTTY die Konfiguration entsprechend angepasst werden, damit die Erkennung eines gespeicherten Fingerprints verhindert wird.
Bei OpenSSH kann die bevorzugte Reihenfolge über die Konfigurationsdatei bei HostKeyAlgorithms angegeben werden.
In PuTTY kann die Option “Prefer algorithms for which a host key is known”, die unter “Connections -> SSH -> Host keys” zu finden ist, deaktiviert werden.
SSHFP Records – Der Fingerprint im DNS
OpenSSH unterstützt die Möglichkeit, die Fingerprints im DNS zu hinterlegen. Leider wird diese sehr sichere Variante der Fingerprint-Überprüfung von anderen SSH-Clients nur sehr selten unterstützt.
Eine wesentliche Voraussetzung für die Verwendung von SSHFP Records ist die Verwendung von DNSSEC. Mittels DNSSEC ist sichergestellt, dass durch einen Man in the Middle Angriff die DNS Einträge während der Übertragung nicht manipuliert werden können.
Auf dem Server können die entsprechenden DNS Records mit folgendem Befehl erstellt werden.
tux@devbox:~$ ssh-keygen -r examplehost.example.org
examplehost.example.org IN SSHFP 1 1 d004948e1d359f2a267f03a599c3efe5d8285ae1
examplehost.example.org IN SSHFP 1 2 f94a95111db1158903bc23e61f75843d029f9d3edabfd74c200f201d4b80b330
examplehost.example.org IN SSHFP 3 1 3b355dc1e3a508e4594e7f8aa30d315d820eb602
examplehost.example.org IN SSHFP 3 2 cacc4090df702522c977ea5dac7bb5d64b9b0968ca63879cc821f8b2b4b099d7
examplehost.example.org IN SSHFP 4 1 4a1923a588b2426b6353699dfe9a69102fd5a29d
examplehost.example.org IN SSHFP 4 2 67be5c3169884615436ec3068cb08d150466e1fae39c18cd4952d2594ad1d512Diese Einträge können anschließend in der Zonen-Datei der entsprechenden Domain hinterlegt werden.
Mit dem Kommando „dig“ kann anschließend überprüft werden, ob die neuen Einträge verfügbar sind.
Anmerkung: Je nach Konfiguration der Zone können Änderungen an DNS Records können bis zu 48 Stunden oder länger brauchen, bis diese verfügbar sind.
tux@devbox:~$ dig SSHFP examplehost.example.org +shortUnter OpenSSH kann die Verwendung von SSHFP Records mit folgender Konfiguration aktiviert werden. Diese Konfiguration fügt man am besten in die Datei “.ssh/config“ im Home-Verzeichnis ein.
VerifyHostKeyDNS yesSofern alles richtig konfiguriert wurde, sollte beim Verbindungsaufbau mittels SSH keine Fingerprint-Überprüfung mehr stattfinden.
Unterstützt die Domain kein DNSSEC, wird von OpenSSH eine entsprechende Meldung ausgegeben und der Fingerprint muss manuell bestätigt werden.
The authenticity of host 'examplehost.example.org (192.0.2.123)' can't be established.
ECDSA key fingerprint is SHA256:MH85JK0yq+JNl1lPKUlxit+dGFqWMS/MmohcINp/e9Q.
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no/[fingerprint])?Speziell bei Man in the Middle Angriffen, kann dieser Hinweis ein falsches Gefühl von Sicherheit vermitteln, weil dieser DNS Eintrag nicht manipulationssicher ist.
SSHFP Records können SSH Verbindungen sicherer machen, weil die manuelle Überprüfung des Fingerprints entfällt. Jedoch muss darauf geachtet werden, dass die Domain mittels DNSSEC abgesichert ist. Dies ist auch ein weiteres Problem. Sofern der Server nur über eine IP-Adresse erreichbar ist, können SSFP Records ebenfalls nicht verwendet werden.
Für einen Anbieter von VPS Systemen oder virtuellen Servern sind SSFP Records eine einfache Möglichkeit einen gesicherten Zugriff auf die Server der Kunden zu ermöglichen.
Ausblick: OpenSSH Zertifikate
OpenSSH Zertifikate sind eine sichere und effiziente Methode für die Authentifizierung bei SSH-Serververbindungen. Diese Zertifikate werden häufig verwendet, um sicherzustellen, dass Benutzer sich nur an legitimen Servern anmelden können, während gleichzeitig die Konfiguration für die Verwaltung von Benutzerrechten vereinfacht wird.
Die Verwendung von OpenSSH Zertifikaten erfordert jedoch ein gewisses Maß an Konfigurationsaufwand. Es müssen Zertifikate erstellt und signiert werden, bevor sie verwendet werden können. Die Konfiguration des Servers und des Clients muss ebenfalls angepasst werden, um die Verwendung dieser Zertifikate zu ermöglichen.
Wenn die Konfiguration abgeschlossen ist, bieten OpenSSH Zertifikate jedoch eine Vielzahl von Vorteilen. Zum Beispiel kann ein Root-Zertifikat verwendet werden, um die Authentizität von Servern zu überprüfen, wodurch das Risiko eines Man-in-the-Middle-Angriffs minimiert wird. Außerdem müssen berechtigte Benutzer keine öffentlichen Schlüssel auf dem Server hinterlegen, sondern können sich anhand eines Client-Zertifikats anmelden.
Administratoren können darüber hinaus Berechtigungen für den Server an das Client-Zertifikat binden. Auf diese Weise können unterschiedliche Benutzergruppen zentral verwaltet werden, ohne dass die Konfiguration der einzelnen Server angepasst werden muss. Dies spart Zeit und Aufwand bei der Verwaltung von Benutzerrechten und macht das System insgesamt effizienter.
Insgesamt ist die Verwendung von OpenSSH Zertifikaten für SSH-Serververbindungen eine sichere und effiziente Methode, die sich insbesondere für Unternehmen lohnt, die eine hohe Sicherheit und Verwaltbarkeit benötigen.
PuTTY unterstützt diese ab Version 0.78. Somit sollten in absehbarer Zeit auch andere Programme, wie z.B. WinSCP, Filezilla und andere Clients, die auf PuTTY basieren, diese unterstützen.
Es empfiehlt sich, bei neueren Versionen von Clients auf diese Methode umzusteigen, da sie ein höheres Maß an Sicherheit und Effizienz bietet.