Was ist SSH und wie funktioniert es?

Was ist SSH?

SSH (Secure Shell) ist ein Protokoll, mit dem Sie sich über eine verschlüsselte Verbindung an einem anderen Computer anmelden und dort Befehle ausführen. Ihre Eingaben werden an das entfernte System übertragen, dessen Ausgaben kommen zurück. Niemand, der den Netzwerkverkehr dazwischen überwacht, kann die Eingaben oder Ausgaben lesen. Ein gemieteter Linux-Server hat keinen angeschlossenen Bildschirm und keine Tastatur. SSH ist daher die Grundlage für seine Nutzung.

Der Name bezeichnet zwei Dinge. SSH ist das Protokoll, das in RFC 4251 bis RFC 4254 beschrieben ist. OpenSSH ist das Programm, das dieses Protokoll implementiert. Es läuft auf fast jedem Linux-Server und fast jedem Laptop. Wenn jemand sagt, dass er sich „per SSH mit dem Server verbindet“, bedeutet das, dass das Clientprogramm ssh auf seinem Computer mit dem Serverprogramm sshd auf der anderen Seite kommuniziert.

Das Problem, das SSH ersetzen sollte

Remote-Anmeldungen sind wesentlich älter als SSH. Telnet öffnete eine unverschlüsselte TCP-Verbindung zu Port 23 und übertrug jedes Byte genau so, wie es eingegeben wurde. Nichts war verschlüsselt, auch Ihr Passwort nicht. Jeder, der den Netzwerkverkehr sehen konnte, konnte ihn lesen: eine Person im selben Büronetzwerk oder der Betreiber eines Routers entlang des Übertragungswegs. Die rlogin-Familie hatte dieselbe Schwachstelle. Außerdem vertraute sie dem Namen des Client-Rechners. Damit vertraute sie darauf, dass das Netzwerk diesen Namen korrekt angab.

Tatu Ylönen entwickelte das erste SSH 1995 an der Helsinki University of Technology, nachdem das Universitätsnetzwerk durch einen Angriff zum Mitschneiden von Passwörtern kompromittiert worden war. Das Design behält den nützlichen Teil von Telnet bei: einen Bytestrom zwischen Ihrem Terminal und einer entfernten Shell. Zusätzlich bietet es die beiden Funktionen, für die Telnet keine Lösung hat: die Verschlüsselung des Datenstroms und den Nachweis, dass der Server am anderen Ende tatsächlich der Server ist, den Sie erreichen wollten.

Der zweite Teil wird leicht übersehen, macht aber die Hälfte von SSH aus. Verschlüsselung allein würde Sie nicht schützen. Ein Rechner in der Mitte könnte Ihre Verbindung annehmen, sie vollständig verschlüsseln, alles von Ihnen Gesendete lesen und an den echten Server weiterleiten. SSH verhindert das, indem es jedem Server eine dauerhafte Identität gibt, den sogenannten Host-Key, und diese bei jeder einzelnen Verbindung prüft.

Funktionsweise des Client-Server-Modells

Es gibt zwei Programme. Auf dem Server läuft sshd dauerhaft und wartet auf Verbindungen. Auf Ihrem Rechner stellt ssh diese Verbindungen her. Es handelt sich um getrennte Programme mit eigenen Konfigurationsdateien. Eine Verwechslung der beiden Programme ist der häufigste Grund dafür, dass eine Änderung keine Wirkung hat.

• Der Server liest /etc/ssh/sshd_config. Dort wird die Anmeldung per Passwort deaktiviert und der Listening-Port festgelegt.
• Der Client liest zunächst /etc/ssh/ssh_config für systemweite Standardeinstellungen und anschließend ~/.ssh/config für Ihre eigenen Host-spezifischen Einstellungen.

Unter Debian und Ubuntu heißt die Service-Unit ssh. Unter RHEL, Rocky und Fedora heißt sie sshd. Neuere Ubuntu-Versionen installieren sie mit Socket-Aktivierung. Daher kann systemctl status ssh inactive (dead) melden, obwohl der Rechner problemlos erreichbar ist. In diesem Fall übernimmt ssh.socket das Listening und startet den Dienst bei Bedarf.

Der Client muss nicht OpenSSH sein. PuTTY unter Windows, Termius auf einem Smartphone und die in Editoren integrierte Remote-Unterstützung verwenden dasselbe Protokoll mit demselben sshd. Windows 10 und 11 enthalten ebenfalls den OpenSSH-Client. Daher funktioniert ssh you@server in PowerShell, ohne dass etwas installiert werden muss.

Warum verwendet SSH Port 22?

Ein Port ist eine Nummer, die dem Kernel mitteilt, zu welchem auf Verbindungen wartenden Programm eine eingehende Verbindung gehört. Ports unter Linux funktionieren bei jedem Dienst nach demselben Prinzip. SSH verwendet Port 22, weil IANA ihn 1995 zugewiesen hat. Ylönen beantragte eine freie Nummer neben den Protokollen, die SSH ersetzen sollte: Port 21 war FTP, Port 23 war telnet und Port 22 war nicht belegt.

Weil Port 22 der Standard ist, gehen alle davon aus. Ihr Git-Remote, Ihr Backup-Skript und das Control Panel Ihres Providers versuchen zuerst Port 22. Das gilt auch für jeden automatisierten Scanner im Internet. Ein neuer Server mit aktiviertem Passwort-Login empfängt innerhalb weniger Minuten nach dem Booten Zeilen wie diese in /var/log/auth.log:

Failed password for invalid user admin from 203.0.113.55 port 43122 ssh2

Dieser Netzwerkverkehr ist konstant und richtet sich nicht persönlich gegen Sie. Wenn Sie sshd auf Port 2222 verschieben, verschwinden die meisten dieser Zeilen, weil die Scanner das gesamte Internet auf Port 22 durchsuchen und nicht Ihren Server gezielt analysieren. Für jemanden, der den Server tatsächlich untersucht, wird der Rechner dadurch nicht schwerer angreifbar. Betrachten Sie eine Portänderung ausschließlich als Maßnahme zur Reduzierung von Hintergrundrauschen.

Sie können beobachten, wie der Server antwortet, noch bevor Sie sich anmelden:

nc 203.0.113.10 22

Unter Ubuntu 24.04 gibt das ungefähr SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13 aus. Das Banner wird im Klartext gesendet, bevor eine Verschlüsselung besteht, weil beide Seiten die Protokollversion vereinbaren müssen. Drücken Sie Ctrl+C, um die Verbindung zu schließen.

Was bei einer Verbindung über das Netzwerk passiert

Die folgende Abfolge durchläuft jeder ssh you@server, bevor Sie eine Eingabeaufforderung sehen.

1. Der Client löst den Hostnamen in eine IP-Adresse auf und öffnet anschließend eine TCP-Verbindung zu Port 22.
2. Beide Seiten senden ihr Versionsbanner im Klartext.
3. Beide Seiten senden die Listen der unterstützten Algorithmen: Schlüsselaustausch, Verschlüsselung, Nachrichtenauthentifizierung und Komprimierung. Auch diese Daten werden noch im Klartext übertragen. Gewählt wird die stärkste Option, die beide Seiten unterstützen.
4. Der Schlüsselaustausch wird durchgeführt. Aktuelle Versionen von OpenSSH bevorzugen curve25519-sha256. Beide Enden verfügen anschließend über dasselbe gemeinsame Geheimnis. Dieses Geheimnis wird zu keinem Zeitpunkt über das Netzwerk übertragen. Wer die gesamte Kommunikation aufgezeichnet hat, kann es daher nachträglich nicht berechnen.
5. Der Server signiert das Ergebnis des Austauschs mit seinem privaten Hostschlüssel. Ihr Client prüft die Signatur anhand des öffentlichen Hostschlüssels, den er gespeichert hat. Dieser Schritt verhindert, dass sich ein Rechner in der Mitte als Ihr Server ausgibt.
6. Die Verschlüsselung beginnt. chacha20-poly1305@openssh.com ist die Standardverschlüsselung in aktuellen Versionen von OpenSSH.
7. Erst jetzt authentifiziert der Client Sie mit einem Passwort oder einem Schlüssel. Ihr Benutzername und Ihr Passwort werden innerhalb des verschlüsselten Kanals übertragen.
8. Der Client öffnet einen Kanal und fordert eine Shell an.

Die Reihenfolge in dieser Liste ist der wesentliche Unterschied zu telnet. Die Authentifizierung erfolgt erst, nachdem der Kanal verschlüsselt wurde und der Server seine Identität bestätigt hat. Ihr Passwort wird daher zu keinem Zeitpunkt ungeschützt über das Netzwerk übertragen.

Wer den Netzwerkverkehr beobachtet, erhält dennoch einige Informationen. Er sieht Ihre IP-Adresse, die IP-Adresse des Servers, Port 22, die beiden Klartext-Versionsbanner sowie den Zeitpunkt und die ungefähre Größe jedes Pakets. Ihren Benutzernamen, Ihr Passwort, Ihre Befehle und deren Ausgabe sieht er nicht. Die Namensauflösung in Schritt 1 gehört nicht zu SSH und ist normalerweise nicht geschützt. Daher kann die DNS-Abfrage, die den Namen Ihres Servers auflöst verraten, welchen Rechner Sie gleich erreichen, obwohl die Sitzung selbst geschützt bleibt.

Der Hostschlüssel und die Fingerabfrage bei der ersten Verbindung

Wenn openssh-server installiert wird, erzeugt es für den Rechner Hostschlüsselpaare und schreibt sie nach /etc/ssh/, zum Beispiel ssh_host_ed25519_key und ssh_host_ed25519_key.pub. Der private Teil verlässt den Server nie. Der öffentliche Teil ist die Identität des Servers. Gegen ihn wird die Signatur in Schritt 5 geprüft.

Wenn Sie zum ersten Mal eine Verbindung zu einem neuen Server herstellen, kann Ihr Client den Schlüssel nicht vergleichen. Er fragt Sie daher:

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:E9nVQ5Sm2oQ3nGm5Zf1tOaU7Xh0k2p8bWc4dLrTvYxA.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Der Fingerabdruck ist ein SHA256-Hash des öffentlichen Hostschlüssels, der in base64 ausgegeben wird. Dadurch ist er kurz genug für einen manuellen Vergleich. Mit yes schreiben Sie diesen Schlüssel auf Ihrem eigenen Rechner nach ~/.ssh/known_hosts. Bei jeder späteren Verbindung zu derselben Adresse vergleicht der Client den vom Server angebotenen Schlüssel mit dem gespeicherten Schlüssel. Stimmen sie überein, wird nichts ausgegeben und Sie gelangen direkt zur Eingabeaufforderung.

Dieses Modell wird als Trust on First Use bezeichnet. Sie sollten sich über die damit verbundenen Einschränkungen im Klaren sein. Die erste Verbindung ist der Moment, in dem Sie nicht geschützt sind, weil Sie einen bisher unbekannten Schlüssel akzeptieren. Um diese Lücke zu schließen, rufen Sie den Fingerabdruck über einen anderen Weg ab und vergleichen Sie ihn. Die meisten Anbieter geben ihn in der Boot-Ausgabe ihrer Webkonsole aus. Sie können ihn auch direkt auf dem Server ausgeben:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Damit wird dieselbe Zeichenfolge SHA256: ausgegeben, die auch in der Abfrage angezeigt wurde. Die Auswahl [fingerprint] in der Abfrage ist genau dafür vorgesehen: Fügen Sie den erwarteten Fingerabdruck ein. Der Client fährt nur fort, wenn er mit dem vom Server präsentierten Fingerabdruck übereinstimmt.

Unter Debian und Ubuntu wird known_hosts standardmäßig gehasht. Die Datei enthält daher Zeilen, die mit |1| beginnen, statt lesbare Hostnamen zu enthalten. Führen Sie ssh-keygen -F 203.0.113.10 aus, um den Eintrag für einen Host zu finden.

Warum meldet SSH, dass sich der Hostschlüssel geändert hat?

Früher oder später sehen Sie diese Textwand:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Die Ausgabe endet mit Host key verification failed., und der Client verweigert die Verbindung. Außerdem wird Password authentication is disabled to avoid man-in-the-middle attacks. ausgegeben, weil genau diese Prüfung verhindern soll, dass Sie Ihr Passwort in eine unbekannte Maschine eingeben.

Die Meldung klingt nach einem Notfall. Meistens ist sie das nicht. Häufige Ursachen sind:

• Sie haben den Server neu erstellt oder neu installiert. Daher hat sshd beim ersten Start neue Hostschlüssel erzeugt. Das ist mit Abstand der häufigste Grund.
• Sie haben einen VPS gelöscht und einen anderen erstellt. Der Anbieter hat der neuen Maschine dieselbe IP-Adresse zugewiesen.
• Sie stellen die Verbindung über einen Forwarder oder einen Load Balancer her, der jetzt eine andere Backend-Maschine erreicht.
• Jemand fängt die Verbindung tatsächlich ab.

Klären Sie die Ursache, bevor Sie Einträge löschen. Wenn Sie die Maschine vor zehn Minuten neu installiert haben, ist die Ursache offensichtlich. Wenn sich auf Ihrer Seite nichts geändert hat, halten Sie an und untersuchen Sie den Vorgang. Die Warnung zeigt, dass die Prüfung ordnungsgemäß funktioniert. Sobald Sie sicher sind, löschen Sie den veralteten Eintrag und stellen die Verbindung erneut her:

ssh-keygen -R 203.0.113.10

Bei der nächsten Verbindung wird die Eingabeaufforderung für den Fingerabdruck erneut angezeigt. Dadurch können Sie ihn erneut mit der Konsole des Anbieters vergleichen.

Passwortanmeldung im Vergleich zur Schlüsselanmeldung

Bei der Passwortauthentifizierung wird Ihr Passwort innerhalb des bereits verschlüsselten Kanals übertragen. sshd prüft es gegen die Kontodatenbank, normalerweise über PAM (Pluggable Authentication Modules). Dafür ist keine Vorbereitung erforderlich. Deshalb kann ein Provider Ihnen einen neuen Server bereitstellen, der zunächst nur über ein root-Passwort verfügt.

Die Schwachstelle ist nicht die Verschlüsselung. Das Problem ist, dass ein Passwort ein kurzes Geheimnis ist, bei jeder Anmeldung an den Server übertragen wird und Port 22 rund um die Uhr von Maschinen geraten wird, die nie müde werden.

Die Authentifizierung mit öffentlichen Schlüsseln funktioniert anders. Sie erstellen ein Schlüsselpaar auf Ihrem eigenen Rechner. Der öffentliche Teil wird in ~/.ssh/authorized_keys innerhalb Ihres Kontos auf dem Server abgelegt. Der private Teil bleibt auf Ihrem Laptop und wird niemals übertragen. Für die Anmeldung signiert der Client Daten, die den Sitzungsbezeichner aus dem Schlüsselaustausch enthalten. Der Server prüft diese Signatur mit dem öffentlichen Schlüssel, den er bereits gespeichert hat. Da die signierten Daten an genau diese Sitzung gebunden sind, ist eine abgefangene Signatur für andere Verbindungen wertlos.

Achten Sie auf die Richtung. Eine Verwechslung ist häufig und kann Schäden verursachen: Der öffentliche Schlüssel wird auf dem Server abgelegt, der private Schlüssel bleibt bei Ihnen. Ein privater Schlüssel, der auf einen Server kopiert wurde, ist ein privater Schlüssel, dem Sie nicht mehr vertrauen können.

Auch die Schlüsselanmeldung kann fehlschlagen. sshd ignoriert Schlüssel, wenn die Dateiberechtigungen zu weit gefasst sind, und weist im Server-Log darauf hin:

Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh

Der Client zeigt Ihnen nur Permission denied (publickey) an. Diese Meldung kann ein Dutzend verschiedene Ursachen haben. Daher lohnt es sich, den Fehler bei öffentlichen Schlüsseln richtig zu lesen, bevor Sie sich aussperren. Das Erstellen von Schlüsseln, ihr Schutz mit einer Passphrase und das Laden in einen Agenten werden unter SSH-Schlüsselverwaltung beschrieben. Wie Sie die Passwortanmeldung deaktivieren, ohne sich selbst auszusperren, wird unter SSH auf einem VPS härten beschrieben.

SFTP, scp und Portweiterleitung nutzen dieselbe Verbindung

Hier liegt das grundlegende Konzept, das den Rest der SSH-Welt verständlich macht. Die Authentifizierung öffnet eine verschlüsselte Verbindung. Diese Verbindung kann gleichzeitig mehrere unabhängige Kanäle übertragen. Eine Shell ist nur eine von mehreren Kanalarten.

• Eine Remote-Shell. ssh you@server öffnet einen Sitzungskanal und fordert eine interaktive Shell an.
• Ein einzelner Befehl. ssh you@server uptime öffnet einen Kanal, führt einen Befehl aus, gibt die Ausgabe aus und beendet sich.
• SFTP. Der Client fordert sshd auf, sein sftp-Subsystem zu starten. Die Dateiübertragung läuft innerhalb derselben Verbindung. SFTP ist ein Dateiübertragungsprotokoll, das SSH nutzt, und hat keine gemeinsame technische Grundlage mit FTP. Das Protokoll, bei dem FTP um Verschlüsselung erweitert wird, heißt FTPS und ist davon unabhängig.
• scp. Kopiert Dateien mit derselben Anmeldung. Seit OpenSSH 9.0, veröffentlicht im Jahr 2022, verwendet scp standardmäßig im Hintergrund das SFTP-Protokoll.
• Portweiterleitung. ssh -L 8080:localhost:80 you@server macht Port 8080 auf Ihrem Laptop zu einem Zugang zu Port 80 auf dem Server. Die Weiterleitung läuft innerhalb der verschlüsselten Verbindung. -R leitet in die andere Richtung weiter, und -D 1080 wandelt die Sitzung in einen SOCKS-Proxy um.
• Git. Ein Remote wie git@github.com:user/repo.git ist eine SSH-Anmeldung, bei der die Gegenstelle anstelle einer Shell einen Befehls-Handler ausführt.
• rsync und Ansible sind ebenfalls SSH-Clients. Sie öffnen einen Kanal, führen etwas aus und lesen die Ausgabe zurück.

Jedes Element dieser Liste verwendet denselben Port, dieselbe Prüfung des Hostschlüssels und dieselben Anmeldedaten. Deshalb lohnt sich die einmalige Einrichtung der schlüsselbasierten Authentifizierung sofort: Jedes dieser Tools übernimmt sie. Das ist auch der Grund, warum dieselbe ~/.ssh/config-Datei, die Ihre Anmeldungen verkürzt, beim Verwalten mehrerer Linux-Server von einem Laptop aus mitwächst.

Was SSH nicht leistet

• SSH macht Ihren Server nicht sicher. SSH schützt den Weg zur Tür. Die Tür ist weiterhin vorhanden, und Angreifer versuchen weiterhin, den Türgriff zu betätigen. Wiederholte Anmeldeversuche mit fail2ban blockieren begrenzt die Anzahl dieser Versuche. Die Authentifizierung ausschließlich mit Schlüsseln entfernt das Ziel der geratenen Passwörter.
• SSH schützt Sie nicht vor Ihrem eigenen Rechner. Jeder mit Zugriff auf Ihren Laptop hat Zugriff auf Ihren privaten Schlüssel und Ihren geladenen Agent.
• SSH verbirgt nicht, dass Sie SSH verwenden. Die Portnummer und das Klartext-Versionsbanner machen dies sichtbar.
• SSH deckt nicht ab, was vor dem Aufbau der Verbindung geschieht. Die Namensauflösung und Ihre Entscheidung, welcher Adresse Sie vertrauen, erfolgen zuerst.

Wohin Sie von hier aus gehen

Wenn Sie gerade einen neuen Server in der Konsole eines Providers geöffnet haben, ist die sinnvolle Reihenfolge festgelegt. Melden Sie sich an, erstellen Sie einen normalen Benutzer, installieren Sie Ihren Schlüssel und schließen Sie anschließend die einfachen Zugangswege. Die ersten zehn Minuten auf einem neuen VPS führt Sie von Anfang bis Ende durch diese Reihenfolge. Was ein VPS tatsächlich ist erklärt die zugrunde liegende Maschine, falls die Begriffe noch neu für Sie sind. Danach sollten Sie zuerst die beiden Artikel zu Schlüsseln und zur Absicherung lesen.

FAQ

Wofür steht SSH?

SSH steht für Secure Shell. Es ist ein Protokoll, mit dem Sie sich über eine verschlüsselte Verbindung an einem entfernten Computer anmelden und dort Befehle ausführen können. Es ist in RFC 4251 bis RFC 4254 definiert. OpenSSH ist die Implementierung, die fast alle verwenden: der ssh-Client auf Ihrem Rechner und der sshd-Server auf dem entfernten Rechner. SSH hat Telnet ersetzt, das sämtliche Daten einschließlich Passwörtern unverschlüsselt über das Netzwerk übertragen hat.

Warum verwendet SSH Port 22?

Die IANA hat SSH 1995 Port 22 zugewiesen, neben FTP auf Port 21 und Telnet auf Port 23. Diese Protokolle sollte SSH ersetzen. Nichts zwingt Sie, diese Portnummer zu verwenden: Port in /etc/ssh/sshd_config ändert sie auf dem Server, und ssh -p wählt auf dem Client eine andere. Da 22 der Standard ist, greifen automatisierte Scanner ständig darauf zu. Deshalb füllt sich /var/log/auth.log eines neuen Servers mit Failed password for invalid user-Zeilen. Eine Änderung des Ports reduziert dieses Rauschen, bietet aber keinen echten Schutz.

Was sollte ich tun, wenn SSH meldet, dass sich der Host-Key geändert hat?

Ermitteln Sie zuerst die Ursache, bevor Sie etwas löschen. Der häufigste Grund ist harmlos: Der Server wurde neu aufgebaut, sodass sshd neue Host-Keys erzeugt hat, oder eine neue Maschine hat die alte IP-Adresse erhalten. Wenn Sie wissen, dass die Maschine neu aufgebaut wurde, führen Sie ssh-keygen -R <host> aus, um den gespeicherten Key zu löschen. Verbinden Sie sich anschließend erneut und vergleichen Sie den angezeigten Fingerabdruck mit dem Fingerabdruck in der Konsole Ihres Providers. Wenn sich auf Ihrer Seite nichts geändert hat, stellen Sie keine Verbindung her und geben Sie Ihr Passwort nicht ein. OpenSSH verweigert die Passwortauthentifizierung in diesem Zustand aus genau diesem Grund bereits.

Unterscheiden sich SFTP und scp von SSH?

Sie laufen darauf auf. Nach der Authentifizierung kann die SSH-Verbindung mehrere Kanäle übertragen. Eine Shell ist nur einer davon. SFTP ist ein Dateiübertragungsprotokoll, das das sftp-Subsystem von sshd über dieselbe Verbindung verwendet. Auch scp verwendet seit OpenSSH 9.0 im Hintergrund das SFTP-Protokoll. Portweiterleitungen und Git über SSH sind ebenfalls Kanäle derselben Verbindung. Alle verwenden denselben Port, dieselbe Host-Key-Prüfung und dieselbe Anmeldung. SFTP ist nicht FTP mit zusätzlicher Verschlüsselung. Dieses Protokoll heißt FTPS und ist ein separates Protokoll.

Ist die Schlüsselauthentifizierung wirklich besser als ein Passwort?

Ja, für jeden Server, der aus dem Internet erreichbar ist. Ein Passwort ist ein kurzes Geheimnis, das Sie dem Server bei jeder Anmeldung übermitteln. Außerdem wird Port 22 fortlaufend von automatisierten Clients erraten. Bei einem Schlüsselpaar verlässt der private Teil niemals Ihren Rechner: Der Client signiert Daten, die an die aktuelle Sitzung gebunden sind, und der Server prüft diese Signatur gegen den öffentlichen Schlüssel in ~/.ssh/authorized_keys. Eine aufgezeichnete Signatur kann nicht gegen einen anderen Server wiederverwendet werden. Schützen Sie den privaten Schlüssel mit einer Passphrase. Eine Schlüsseldatei ohne Passphrase ermöglicht jedem, der sie kopiert, die Anmeldung.