Was ist SSH? Verständlich erklärt (2026)

SSH ist ein Netzwerkprotokoll, mit dem du dich über ein unsicheres Netz sicher auf einem entfernten Computer anmeldest und dort Befehle ausführst. Die Abkürzung steht für Secure Shell. Alles, was zwischen deinem Rechner und dem Server hin und her geht — Tastendrücke, Ausgaben, übertragene Dateien, Passwörter — ist verschlüsselt und gegen Manipulation geschützt.

Das ist die kurze Antwort. Die längere ist interessanter, weil die meisten Erklärungen an derselben Stelle aufhören: Sie zeigen, wie man einen Schlüssel erzeugt, und nennen Schlüssel dann eine „bequemere” Alternative zum Passwort. Diese Formulierung ist nicht nur ungenau, sie ist gefährlich — denn sie stellt eine Sicherheitsentscheidung als Komfortfrage dar.

Dieser Artikel erklärt SSH von Grund auf und belegt die wichtigen Stellen mit Zahlen aus dem eigenen Betrieb. Wir haben für diesen Text das Journal unseres Hauptservers ausgewertet: 26.753 fehlgeschlagene Anmeldeversuche von 2.874 verschiedenen IP-Adressen in 22 Tagen — und darin einen Befund gefunden, der das Kapitel „Schlüssel vs. Passwort” nicht als Empfehlung, sondern als Messung lesbar macht.

Was ist SSH? Das Problem, das es gelöst hat

Um zu verstehen, was SSH ist, hilft ein Blick darauf, was es ersetzt hat. Vor SSH meldete man sich mit Telnet, rlogin oder rsh an entfernten Rechnern an. Diese Protokolle funktionierten — sie übertrugen nur alles im Klartext. Das Passwort, das du eintipptest, lief als lesbarer Text durchs Netz. Jeder, der an irgendeiner Stelle der Strecke mithören konnte, hatte es.

1995 baute Tatu Ylönen an der Technischen Universität Helsinki die erste Version von SSH, nachdem sein Netzwerk Ziel eines Passwort-Schnüffelangriffs geworden war. Das Protokoll wurde später überarbeitet und liegt heute als SSH-2 vor, standardisiert in den RFCs 4251 bis 4254 aus dem Jahr 2006. Die weit überwiegende Zahl aller Installationen nutzt OpenSSH, eine freie Implementierung aus dem OpenBSD-Projekt.

Auf unserem Server sieht das so aus:

OpenSSH_9.6p1 Ubuntu-3ubuntu13.19, OpenSSL 3.0.13

SSH löst dabei drei Probleme gleichzeitig, und diese Dreiteilung ist der Schlüssel zum Verständnis:

1. Vertraulichkeit — niemand unterwegs kann mitlesen, weil die Verbindung verschlüsselt ist.
2. Integrität — niemand unterwegs kann unbemerkt etwas verändern, weil jedes Paket eine kryptografische Prüfsumme trägt.
3. Authentizität — und zwar in beide Richtungen: Der Server prüft, ob du der bist, der du zu sein behauptest. Und dein Client prüft, ob der Server der ist, mit dem du letztes Mal gesprochen hast.

Der dritte Punkt wird beim Lernen fast immer übergangen, weil er sich als lästige Warnmeldung tarnt. Er ist derjenige, der einen Angriff verhindert, gegen den Verschlüsselung allein machtlos wäre. Dazu später mehr.

Wie eine SSH-Verbindung tatsächlich zustande kommt

Wenn du ssh benutzer@server eintippst, passieren in wenigen hundert Millisekunden vier Dinge nacheinander. Die Reihenfolge ist wichtig, weil sie erklärt, warum bestimmte Fehlermeldungen kommen, bevor du überhaupt ein Passwort eingeben konntest.

Schritt 1: Versionsaustausch. Beide Seiten sagen sich, welche Protokollversion sie sprechen. Das ist der einzige Teil, der im Klartext läuft.

Schritt 2: Schlüsselaustausch (Key Exchange, kurz KEX). Client und Server einigen sich auf ein Verfahren und leiten daraus einen gemeinsamen geheimen Sitzungsschlüssel ab — ohne diesen Schlüssel jemals über die Leitung zu schicken. Das ist die eigentliche Magie der modernen Kryptografie. Ab hier ist alles verschlüsselt.

Schritt 3: Server-Authentifizierung. Der Server beweist mit seinem Host-Key, dass er der ist, für den er sich ausgibt. Dein Client vergleicht das mit dem, was in ~/.ssh/known_hosts steht.

Schritt 4: Client-Authentifizierung. Erst jetzt weist du dich aus — per Schlüssel oder Passwort.

Was dabei ausgehandelt wird, kannst du dir selbst ansehen. ssh -v zeigt die Verhandlung. Auf unserem Server:

debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com
debug1: Server host key: ssh-ed25519 SHA256:KtZdIhCO3vbjDpSfd/oermLTrfODaOGjVUc1VyEg0EM

Die erste Zeile verdient einen Moment Aufmerksamkeit. sntrup761x25519 ist ein hybrides, post-quantensicheres Verfahren: Es kombiniert das klassische X25519 mit Streamlined NTRU Prime. Der Hintergrund ist eine Angriffsklasse namens harvest now, decrypt later — jemand zeichnet heute verschlüsselten Verkehr auf und entschlüsselt ihn, sobald leistungsfähige Quantencomputer existieren. OpenSSH hat dieses Verfahren mit Version 9.0 zum Standard gemacht. Das heißt: Wer ein aktuelles OpenSSH benutzt, hat diesen Schutz bereits — ohne etwas konfiguriert zu haben.

Wie lange das alles dauert, haben wir gemessen. Fünf Verbindungsaufbauten mit anschließendem sofortigem Beenden:

Rund 190 Millisekunden für Verbindungsaufbau, Schlüsselaustausch, beidseitige Authentifizierung und Verbindungsabbau. Das ist der Preis für jede neue SSH-Sitzung — und der Grund, warum es sich lohnt, Verbindungen wiederzuverwenden, wenn ein Skript hundertmal hintereinander etwas auf demselben Server tut. Dazu gibt es weiter unten eine konkrete Einstellung.

Schlüssel und Passwort: keine Komfortfrage, sondern zwei verschiedene Sicherheitsmodelle

Hier ist der Abschnitt, um den es eigentlich geht.

Ein SSH-Schlüsselpaar besteht aus zwei zusammengehörigen Dateien. Der private Schlüssel bleibt auf deinem Rechner und verlässt ihn nie. Der öffentliche Schlüssel wird auf den Server kopiert, in die Datei ~/.ssh/authorized_keys. Beim Anmelden schickt der Server dir eine zufällige Aufgabe, die du nur mit dem privaten Schlüssel lösen kannst. Du schickst die Lösung zurück — nicht den Schlüssel.

Der entscheidende Unterschied ist genau das: Bei der Passwort-Anmeldung überträgst du das Geheimnis selbst. Es ist zwar verschlüsselt unterwegs, aber der Server bekommt es zu sehen. Bei der Schlüssel-Anmeldung überträgst du nur einen Beweis, dass du das Geheimnis besitzt. Der private Schlüssel verlässt deine Festplatte nie — auch nicht in verschlüsselter Form, auch nicht kurz.

Daraus folgen drei Konsequenzen, die nichts mit Bequemlichkeit zu tun haben:

• Ein kompromittierter oder gefälschter Server kann dein Passwort einsammeln. Deinen privaten Schlüssel kann er nicht einsammeln.
• Ein Passwort, das ein Mensch sich merken kann, ist ratbar. Ein Ed25519-Schlüssel ist es nicht.
• Dasselbe Passwort wird oft auf mehreren Systemen benutzt. Ein Schlüssel wird typischerweise pro Gerät erzeugt und ist einzeln widerrufbar.

Der Beleg aus dem eigenen Journal

Und jetzt die Messung, die diesen Abschnitt von einer Meinung in einen Befund verwandelt. Wir haben das SSH-Journal unseres Hauptservers über den gesamten verfügbaren Zeitraum ausgewertet — vom 24. August bis zum 15. September 2026, also 22 Tage:

Die letzte Zeile ist die interessante, und sie hat mich beim Messen kurz stutzen lassen. Null fehlgeschlagene Passwort-Versuche bei 26.753 Angriffen — das sah zuerst nach einem Fehler im Messgerät aus. Ist es aber nicht. Die Erklärung steht in der Konfiguration:

passwordauthentication no
kbdinteractiveauthentication no
permitrootlogin without-password
pubkeyauthentication yes

Weil die Passwort-Anmeldung abgeschaltet ist, kommt es gar nicht erst zu einem Passwort-Versuch. Der Server bietet das Verfahren nicht an, der Angreifer kann es nicht nutzen, die Verbindung endet vorher. Im Log sieht das dann so aus:

Invalid user prueba from 160.187.247.119 port 49052
Connection closed by invalid user prueba 160.187.247.119 port 49052 [preauth]

[preauth] heißt: abgebrochen, bevor eine Authentifizierung stattfand.

🔑 Das ist der eigentliche Punkt: Eine abgeschaltete Passwort-Anmeldung macht 26.753 Angriffsversuche nicht schwerer, sondern gegenstandslos. Kein Ratespiel, das man gewinnen kann. Kein Passwort, das lang genug sein muss. Die gesamte Angriffsklasse fällt weg. Das ist etwas grundsätzlich anderes als ein gutes Passwort — und der Grund, warum „Schlüssel sind bequemer” die Sache falsch beschreibt.

⚠️ Ehrlich dazugesagt: Diese Zahl beweist, dass diese Angriffsart bei uns ins Leere läuft. Sie beweist nicht, dass unser Server sicher ist. Die 85 erfolgreichen Schlüssel-Anmeldungen wären genauso erfolgreich, wenn ein privater Schlüssel in falsche Hände geriete. SSH-Härtung verschiebt das Risiko von „Passwort erraten” zu „Schlüsseldatei schützen” — sie löscht es nicht.

Wonach die Angreifer suchen

Ein Blick auf die geratenen Benutzernamen der letzten sieben Tage zeigt, wie automatisiert das Ganze ist:

Drei der zehn häufigsten Namen — wallet, crypto, bitcoin, dazu blockchain — zielen auf Kryptowährungs-Software. Das sind keine gezielten Angriffe auf uns, sondern flächendeckendes Abklopfen des gesamten Internets nach lohnenden Zielen. Weiter unten in der Liste standen mit heynyx (69 Versuche) und praxisfix (49) allerdings zwei Namen, die aus unseren eigenen Domains abgeleitet sind. Die stehen in öffentlichen Zertifikatsprotokollen. Wer eine Domain mit HTTPS betreibt, liefert damit Kandidaten für Benutzernamen mit — ein Detail, das wir schon in unserem Leitfaden zum Linux-Server-Einrichten ausführlicher belegt haben.

Die Verteilung über die Tage ist außerdem alles andere als gleichmäßig:

Der 10. September hat das Sechsfache des Vortags. Angriffslast kommt in Wellen, nicht als konstanter Hintergrund — was beim Interpretieren jeder Momentaufnahme wichtig ist.

Welchen Schlüsseltyp solltest du nehmen?

Die Antwort ist kurz: Ed25519. Der Befehl dazu:

ssh-keygen -t ed25519 -C "laptop-2026"

Ed25519 basiert auf Kurve-25519-Kryptografie, erzeugt sehr kurze Schlüssel, ist schnell und gilt als robust gegen mehrere Implementierungsfehler, die RSA in der Vergangenheit anfällig gemacht haben. Alle vier auf unserem Server hinterlegten Schlüssel sind Ed25519:

256 SHA256:9y//ran6kYeH… root@Nyx (ED25519)
256 SHA256:mDBO/DgtbDcA… konta@FaBudde (ED25519)
256 SHA256:IMuoPt8+Szqm… kiro@helsinki (ED25519)
256 SHA256:nm9B0YsIB2x5… fabian-handy-laptop-2026 (ED25519)

RSA funktioniert weiterhin, sollte aber mindestens 3072 Bit haben (unser Server hält aus Kompatibilitätsgründen noch einen RSA-Host-Key vor). ECDSA ist nicht kaputt, aber unbeliebt, weil seine Kurven auf Vorgaben der NIST zurückgehen und die Signaturberechnung empfindlich auf schlechte Zufallszahlen reagiert. DSA ist tot — OpenSSH hat die Unterstützung mit Version 9.8 (2024) abgeschaltet.

Der wichtigste Zusatz ist unabhängig vom Typ: Vergib eine Passphrase. Ein privater Schlüssel ohne Passphrase ist eine Datei, die sofort funktioniert, sobald jemand sie kopiert. Mit Passphrase ist sie zusätzlich verschlüsselt. Und damit du sie nicht bei jedem Verbindungsaufbau eintippen musst, gibt es den ssh-agent, der den entschlüsselten Schlüssel für die Dauer deiner Sitzung im Arbeitsspeicher hält:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Der Schlüsselkommentar ist eine Behauptung, das Log ist der Beweis

Dieser Abschnitt existiert, weil wir aus einem eigenen Beinahe-Fehler gelernt haben.

Am Ende jedes öffentlichen Schlüssels steht ein Kommentar — oben etwa kiro@helsinki oder fabian-handy-laptop-2026. Standardmäßig setzt ssh-keygen dort benutzer@rechnername ein. Es sieht damit aus wie eine verlässliche Angabe darüber, wem der Schlüssel gehört.

Ist es nicht. Das Feld ist freier Text. Es wird beim Erzeugen gesetzt, von niemandem geprüft und kann jederzeit geändert werden, ohne dass sich am Schlüssel etwas ändert. Der Kommentar sagt, was sich jemand beim Erzeugen gedacht hat — nicht, wer den Schlüssel heute besitzt oder benutzt.

Was der Kommentar nicht sagt, sagt das Log. OpenSSH protokolliert bei jeder erfolgreichen Anmeldung den Fingerabdruck des verwendeten Schlüssels. Damit lässt sich jeder hinterlegte Schlüssel gegen die Wirklichkeit prüfen:

# Fingerabdrücke aller hinterlegten Schlüssel
ssh-keygen -lf ~/.ssh/authorized_keys

# Wer hat diesen Schlüssel tatsächlich benutzt — und von wo?
journalctl -u ssh --no-pager | grep <FINGERABDRUCK> \
  | grep -oE "from ([0-9]{1,3}\.){3}[0-9]{1,3}" | sort | uniq -c

Für unsere vier Schlüssel ergab das:

Zwei der vier Schlüssel wurden im gesamten Journal-Zeitraum nie benutzt. Und die beiden benutzten zeigen ein aufschlussreiches Muster: Der Schlüssel mit helsinki im Namen kommt tatsächlich ausschließlich von einer festen Server-IP — das passt. Der Schlüssel mit handy-laptop im Namen kommt von fünf verschiedenen IP-Adressen, wie man es bei einem Mobilgerät mit wechselnden Anschlüssen erwartet — das passt ebenfalls.

🔑 Die Lehre: Herkunfts-IP ist Besitz, Kommentar ist Absicht. Wer einen SSH-Zugang löschen will, sollte vorher ins Log sehen statt auf das Namensfeld zu vertrauen. Ein selten genutzter Schlüssel kann an einem stillen Cronjob hängen, dessen Ausfall erst Wochen später auffällt. Und ein Schlüssel mit fremd klingendem Kommentar kann trotzdem der eigene sein.

⚠️ Grenze dieser Messung, ehrlich benannt: Das Journal reichte nur 22 Tage zurück. „Null Anmeldungen” heißt hier nicht „nie benutzt”, sondern „nicht in diesem Fenster”. Das ist ein Unterschied, der beim Löschen eines Zugangs über Erfolg oder Ausfall entscheidet. Wer aufräumen will, braucht ein längeres Fenster — oder muss die Abwesenheit anders belegen.

known_hosts: die Warnung, die niemand liest

Erinnerst du dich an Schritt 3 des Verbindungsaufbaus — den Teil, in dem sich der Server ausweist? Hier wird er wichtig.

Beim ersten Verbinden mit einem unbekannten Server fragt SSH:

The authenticity of host 'server.example.com' can't be established.
ED25519 key fingerprint is SHA256:KtZdIhCO3vbjDpSfd/oermLTrfODaOGjVUc1VyEg0EM.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Fast alle tippen yes. Damit wird der Fingerabdruck des Servers in ~/.ssh/known_hosts gespeichert. Auf unserem Client stehen dort 34 Einträge — in gehashter Form, sodass die Datei selbst keine Liste aller Server preisgibt, zu denen wir Verbindung haben:

|1|ZeZF6VBOlnAvU0K0R/od3oBUOgI=|6OpraSurwSaqN8Dl2mwEwE4dAjc=

Bei jeder weiteren Verbindung vergleicht dein Client den präsentierten Host-Key mit dem gespeicherten. Stimmt er nicht überein, kommt die Meldung, die viele reflexhaft wegräumen:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!      @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Der übliche Umgang damit ist, den alten Eintrag zu löschen (ssh-keygen -R server) und weiterzumachen. Meistens ist das auch richtig — der Server wurde neu aufgesetzt, die IP neu vergeben, das Host-Key-Paar neu erzeugt.

Aber genau diese Warnung ist das Einzige, was zwischen dir und einem Man-in-the-Middle-Angriff steht. Verschlüsselung allein schützt nicht davor: Wer sich in die Verbindung setzt, baut einfach zwei verschlüsselte Verbindungen auf — eine zu dir, eine zum echten Server — und liest in der Mitte alles mit. Was ihm fehlt, ist der private Host-Key des echten Servers. Deshalb ändert sich der Fingerabdruck. Deshalb die Warnung.

Der praktische Rat: Wenn du weißt, warum sich der Schlüssel geändert hat (du hast den Server gerade neu installiert), lösch den Eintrag. Wenn du es nicht weißt, prüf den neuen Fingerabdruck über einen anderen Weg — aus der Konsole deines Hosters oder direkt auf dem Server mit:

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

~/.ssh/config: der am meisten unterschätzte Teil

Die meisten SSH-Benutzer tippen jahrelang lange Befehle mit -p, -i und Benutzernamen. Dabei gibt es eine Konfigurationsdatei, die all das ein für alle Mal festhält: ~/.ssh/config.

Aus unserer eigenen:

Host pastaclean-new
    HostName 128.140.88.82
    Port 52200
    User root
    IdentityFile ~/.ssh/id_ed25519

Statt ssh -p 52200 -i ~/.ssh/id_ed25519 root@128.140.88.82 genügt danach ssh pastaclean-new. Das ist nicht nur kürzer, es ist auch weniger fehleranfällig: Der richtige Schlüssel wird automatisch gewählt, statt dass der Client alle vorhandenen der Reihe nach durchprobiert (was bei mehr als sechs Schlüsseln zu einem Too many authentication failures führen kann, obwohl der richtige dabei war).

Ein paar Einstellungen, die den Alltag spürbar verändern:

Host *
    # Verbindungen wiederverwenden statt jedes Mal neu aufzubauen
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h:%p
    ControlPersist 10m

    # Verbindung am Leben halten, tote Verbindungen erkennen
    ServerAliveInterval 30
    ServerAliveCountMax 3

    # Nur den explizit angegebenen Schlüssel anbieten
    IdentitiesOnly yes

ControlMaster ist die Einstellung mit dem größten messbaren Effekt. Wir haben oben 190 Millisekunden pro Verbindungsaufbau gemessen. Mit einer wiederverwendeten Verbindung entfällt der komplette Schlüsselaustausch — bei einem Deploy-Skript mit zwanzig aufeinanderfolgenden SSH-Aufrufen sind das knapp vier Sekunden, die schlicht verschwinden.

ProxyJump löst außerdem das Sprungserver-Problem elegant:

Host intern
    HostName 10.0.0.5
    ProxyJump bastion

Damit verbindest du dich mit ssh intern auf eine Maschine, die vom Internet aus gar nicht erreichbar ist — der Weg über den Bastion-Host passiert automatisch und ohne dass dein privater Schlüssel jemals auf dem Sprungserver landet.

Port-Forwarding: SSH als Tunnel

SSH kann mehr als eine Kommandozeile transportieren. Es kann beliebige TCP-Verbindungen durch seinen verschlüsselten Kanal leiten. Das ist eine der nützlichsten und am seltensten verstandenen Funktionen.

Lokales Forwarding (-L) — bringt einen Dienst vom Server zu dir:

ssh -L 8080:127.0.0.1:5432 server

Danach erreichst du unter localhost:8080 auf deinem Rechner die PostgreSQL-Datenbank, die auf dem Server nur auf 127.0.0.1 lauscht. Der Datenbank-Port muss dafür nicht ins Internet geöffnet werden — und genau das ist der Punkt. In unserem Artikel über IT-Sicherheitslücken steht der Anlass für diese Regel: Ein Docker-Container mit dem Standard-Mapping 5432:5432 bindet an alle Schnittstellen und macht die Datenbank öffentlich erreichbar. Richtig ist 127.0.0.1:5432:5432 — und der Zugriff von außen dann per SSH-Tunnel.

Remote Forwarding (-R) — bringt einen Dienst von dir zum Server:

ssh -R 9000:localhost:3000 server

Dynamisches Forwarding (-D) — macht SSH zum SOCKS-Proxy:

ssh -D 1080 server

Danach kann jede Anwendung, die SOCKS5 versteht, ihren Verkehr über den Server leiten. Das ist kein VPN — es routet nur, was die Anwendung explizit hindurchschickt — aber für einzelne Programme oft genau das Richtige.

Agent-Forwarding (-A) verdient eine Warnung. Es leitet deinen lokalen Schlüsselagenten auf den Server weiter, sodass du dich von dort aus weiterverbinden kannst. Praktisch — aber wer auf dem Zwischenserver Root-Rechte hat, kann deinen Agenten benutzen, solange die Verbindung offen ist. Nutze stattdessen ProxyJump, das dasselbe Problem löst, ohne den Agenten aus der Hand zu geben.

Häufige Fehlermeldungen im Klartext

Permission denied (publickey) — Der Server akzeptiert nur Schlüssel, und deiner passte nicht. Häufigste Ursachen: falscher Benutzername, der öffentliche Schlüssel liegt nicht in authorized_keys, oder der Client hat einen anderen Schlüssel angeboten. ssh -v zeigt in der Zeile Offering public key:, welcher probiert wurde.

Host key verification failed — Der gespeicherte Fingerabdruck passt nicht zum präsentierten. Siehe den Abschnitt zu known_hosts — nicht blind mit ssh-keygen -R wegräumen, sondern erst verstehen, warum.

Too many authentication failures — Dein Client hat zu viele Schlüssel nacheinander angeboten und der Server hat nach MaxAuthTries (bei uns: 6) abgebrochen. Lösung: IdentitiesOnly yes plus expliziter IdentityFile.

WARNING: UNPROTECTED PRIVATE KEY FILE! — Deine Schlüsseldatei ist für andere Benutzer lesbar. chmod 600 ~/.ssh/id_ed25519 behebt es. SSH verweigert hier absichtlich den Dienst statt nur zu warnen.

Connection closed by … [preauth] — Die Verbindung endete, bevor eine Anmeldung stattfand. In deinen eigenen Logs ist das fast immer ein Bot. Von 26.753 Einträgen dieser Art in unserem Journal war kein einziger ein echter Anmeldeversuch eines Menschen.

kex_exchange_identification: Connection closed by remote host — Oft ein fail2ban oder eine Firewall, die deine IP gesperrt hat, bevor überhaupt verhandelt wurde.

Die fünf Einstellungen, die wirklich zählen

In /etc/ssh/sshd_config (bzw. einer Datei unter /etc/ssh/sshd_config.d/):

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes
MaxAuthTries 3

Die erste Zeile ist die, die in unserer Messung 26.753 Angriffe gegenstandslos gemacht hat. Die zweite schließt einen Umweg, den viele Anleitungen vergessen: Ohne sie kann die Passwort-Abfrage über das Keyboard-Interactive-Verfahren zurückkommen, obwohl PasswordAuthentication no gesetzt ist.

⚠️ Bevor du die Passwort-Anmeldung abschaltest, teste in einer zweiten Sitzung, dass dein Schlüssel funktioniert. Konfiguration prüfen und neu laden:

sshd -t                      # Syntaxprüfung, meldet Fehler ohne Neustart
systemctl reload ssh

Was die tatsächlich aktive Konfiguration ist — nicht das, was in der Datei steht, sondern was der Dienst wirklich anwendet — zeigt:

sshd -T | grep -iE "passwordauth|permitroot|pubkeyauth|maxauthtries"

Dieser Unterschied ist wichtiger, als er klingt. Eine Einstellung kann in der Datei stehen und trotzdem nicht wirken — etwa weil sie nach einem Match-Block steht oder von einer eingebundenen Datei überschrieben wird. sshd -T fragt den Dienst, nicht den Text.

Was kein Sicherheitsgewinn ist: den Port von 22 auf etwas anderes zu legen. Es reduziert das Rauschen in den Logs erheblich — mehr aber nicht. Ein Portscan findet den neuen Port in Sekunden. Wenn du es tust, dann wegen der Log-Ruhe, nicht wegen der Sicherheit.

Häufige Fragen zu SSH

Was ist SSH einfach erklärt?

SSH (Secure Shell) ist ein Protokoll, mit dem du dich über ein unsicheres Netz verschlüsselt auf einem entfernten Computer anmelden und dort arbeiten kannst. Alles zwischen deinem Rechner und dem Server ist verschlüsselt und gegen Veränderung geschützt. Zusätzlich prüfen beide Seiten gegenseitig ihre Identität: Der Server prüft dich, und dein Client prüft, ob der Server derselbe ist wie beim letzten Mal.

Wofür braucht man SSH?

Vor allem für die Verwaltung von Servern, auf denen keine grafische Oberfläche läuft — Webserver, Datenbanken, Container-Hosts. Außerdem für Dateiübertragung (scp, sftp, rsync über SSH), für Git-Zugriff auf Repositories, für automatisierte Deployments und als Tunnel, um Dienste zu erreichen, die absichtlich nicht im Internet stehen.

Ist SSH sicher?

Das Protokoll selbst gilt als sicher, wenn eine aktuelle Version eingesetzt wird. Aktuelle OpenSSH-Versionen verwenden ab Version 9.0 sogar standardmäßig ein hybrides post-quantensicheres Schlüsselaustauschverfahren. Die praktischen Risiken liegen fast immer woanders: schwache Passwörter, ungeschützte private Schlüssel und weggeklickte Host-Key-Warnungen. Wer die Passwort-Anmeldung abschaltet, entfernt die häufigste Angriffsart vollständig — in unserem Journal liefen dadurch 26.753 Versuche ins Leere.

Was ist der Unterschied zwischen SSH-Schlüssel und Passwort?

Beim Passwort überträgst du das Geheimnis selbst zum Server; er bekommt es zu sehen. Beim Schlüssel überträgst du nur einen Beweis, dass du das Geheimnis besitzt — der private Schlüssel verlässt deinen Rechner nie. Deshalb kann ein kompromittierter oder gefälschter Server ein Passwort einsammeln, einen privaten Schlüssel aber nicht. Das ist keine Komfortfrage, sondern ein anderes Sicherheitsmodell.

Welchen SSH-Schlüsseltyp sollte ich verwenden?

Ed25519, erzeugt mit ssh-keygen -t ed25519. Er ist kurz, schnell und robust. RSA funktioniert weiterhin, sollte dann aber mindestens 3072 Bit haben. ECDSA ist unbeliebt, DSA wurde von OpenSSH mit Version 9.8 im Jahr 2024 entfernt. Wichtiger als der Typ ist eine Passphrase auf dem privaten Schlüssel plus ssh-agent, damit du sie nicht ständig eintippen musst.

Was bedeutet „Host key verification failed”?

Der Fingerabdruck des Servers stimmt nicht mehr mit dem überein, den dein Client in ~/.ssh/known_hosts gespeichert hat. Meistens ist die Ursache harmlos: Der Server wurde neu aufgesetzt oder die IP-Adresse neu vergeben. Es kann aber auch ein Man-in-the-Middle-Angriff sein. Wenn du den Grund nicht kennst, prüfe den neuen Fingerabdruck über einen zweiten Weg, bevor du den alten Eintrag mit ssh-keygen -R löschst.

Sollte ich den SSH-Port von 22 ändern?

Es reduziert die Menge an Bot-Anfragen in den Logs deutlich, erhöht die Sicherheit aber kaum — ein Portscan findet jeden Port in Sekunden. Als Argument für weniger Log-Rauschen ist es in Ordnung, als Sicherheitsmaßnahme nicht. Die Abschaltung der Passwort-Anmeldung bringt um Größenordnungen mehr.

Was ist SSH-Port-Forwarding?

Die Möglichkeit, beliebige TCP-Verbindungen durch den verschlüsselten SSH-Kanal zu leiten. Mit -L holst du dir einen Dienst vom Server auf deinen Rechner (etwa eine Datenbank, die nur lokal lauscht), mit -R stellst du umgekehrt einen lokalen Dienst auf dem Server bereit, und mit -D wird SSH zu einem SOCKS-Proxy. So erreichst du Dienste, die absichtlich nicht ins Internet geöffnet sind.

Fazit

SSH ist der Zugang zu praktisch jedem Server, der irgendwo etwas ausliefert. Was dabei am meisten unterschätzt wird, ist nicht die Verschlüsselung — die läuft automatisch und ist mit aktuellen Versionen sogar bereits gegen zukünftige Quantencomputer gewappnet. Unterschätzt werden die zwei Stellen, an denen ein Mensch entscheidet.

Die erste ist die Wahl zwischen Schlüssel und Passwort. Sie wird meist als Bequemlichkeitsfrage präsentiert und ist in Wahrheit eine Entscheidung darüber, ob eine ganze Angriffsklasse existiert oder nicht. 26.753 Versuche, 2.874 IP-Adressen, 22 Tage — und null Passwort-Fehlversuche, weil es kein Passwort zu raten gab.

Die zweite ist die Host-Key-Warnung. Sie sieht aus wie ein Hindernis und ist der einzige Schutz gegen einen Angriff, den Verschlüsselung allein nicht abwehrt.

Und eine dritte Lehre, die uns dieser Artikel selbst beigebracht hat: Ein Schlüsselkommentar ist eine Behauptung, ein Login-Log ist ein Beweis. Zwei der vier auf unserem Server hinterlegten Schlüssel wurden in 22 Tagen kein einziges Mal benutzt. Hätten wir nach dem Namensfeld aufgeräumt statt nach der Herkunfts-IP, hätten wir vermutlich den falschen gelöscht.

Wenn du danach weitermachen willst: Unser Leitfaden zum Linux-Server einrichten zeigt die Härtung Schritt für Schritt mit Firewall und fail2ban, IT-Sicherheitslücken ordnet SSH in die größeren Angriffsklassen ein, und wie unser Server fünf Tage lang gekapert wurde zeigt, was passiert, wenn der Einbruch gar nicht über SSH kommt. Wer sich noch für die passende Distribution entscheidet, findet in Debian vs. Ubuntu die Unterschiede, und Was ist ein Reverse Proxy erklärt den zweiten Baustein, der auf fast jedem dieser Server läuft.