{"id":93,"date":"2026-06-14T16:21:52","date_gmt":"2026-06-14T16:21:52","guid":{"rendered":"https:\/\/shattered.io\/at\/2026\/06\/14\/ssh-key-einrichten\/"},"modified":"2026-06-14T16:23:23","modified_gmt":"2026-06-14T16:23:23","slug":"ssh-key-einrichten","status":"publish","type":"post","link":"https:\/\/shattered.io\/at\/ssh-key-einrichten\/","title":{"rendered":"SSH-Key einrichten: Server h\u00e4rten in 10 Schritten [2026]"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Passw\u00f6rter sind die schw\u00e4chste Stelle jedes Servers. Automatisierte Bots scannen rund um die Uhr das Internet nach offenen SSH-Diensten auf Port 22 und probieren in Sekunden tausende Standardpassw\u00f6rter durch. Ein einziger erfolgreicher Treffer reicht, und der Angreifer hat eine Shell auf Ihrem System. Die L\u00f6sung ist seit Jahren bekannt und in der Praxis kompromisslos wirksam: ein SSH-Key statt eines Passworts. Diese Anleitung f\u00fchrt Sie in 10 nachvollziehbaren Schritten von der Schl\u00fcsselerzeugung bis zum vollst\u00e4ndig geh\u00e4rteten OpenSSH-Server. Sie brauchen daf\u00fcr rund 30 Minuten und keine Vorkenntnisse \u00fcber Kryptographie.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wir arbeiten mit OpenSSH, dem De-facto-Standard auf Linux, macOS und seit Jahren auch Windows. Jeder Befehl ist getestet, jede Konfigurationszeile erkl\u00e4rt. Am Ende steht ein komplettes, kopierbares Beispielprojekt: ein Ubuntu- oder Debian-Server, der nur noch Schl\u00fcssel akzeptiert, Root-Logins ablehnt, Brute-Force-Versuche aussperrt und den quantenresistenten Schl\u00fcsselaustausch nutzt, den aktuelle OpenSSH-Versionen seit Ende 2024 standardm\u00e4\u00dfig mitbringen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"warum-ssh-key-authentifizierung-2026-zur-pflicht-wird\">Warum SSH-Key-Authentifizierung 2026 zur Pflicht wird<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein SSH-Key besteht aus einem mathematisch verkn\u00fcpften Schl\u00fcsselpaar: einem privaten Schl\u00fcssel, der Ihren Rechner nie verl\u00e4sst, und einem \u00f6ffentlichen Schl\u00fcssel, den Sie auf beliebig vielen Servern hinterlegen. Beim Login beweist Ihr Client kryptographisch den Besitz des privaten Schl\u00fcssels, ohne ihn jemals zu \u00fcbertragen. Es gibt kein Geheimnis, das \u00fcber die Leitung wandert, und damit nichts, was ein Angreifer abfangen oder erraten k\u00f6nnte. Ein moderner Ed25519-Schl\u00fcssel hat eine effektive St\u00e4rke von 128 Bit. Ein Brute-Force-Angriff dagegen ist mit klassischer Rechenleistung praktisch ausgeschlossen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die Bedrohungslage spricht eine deutliche Sprache. In \u00d6sterreich registrierte die Polizei laut Bundeskriminalamt 62.328 F\u00e4lle von Cyberkriminalit\u00e4t, und Server mit passwortbasiertem SSH-Zugang geh\u00f6ren zu den ersten Zielen automatisierter Angriffe. Ein frisch aufgesetzter Cloud-Server sieht innerhalb weniger Minuten die ersten Login-Versuche fremder IP-Adressen. Wer Passwortanmeldung erlaubt, setzt darauf, dass keiner dieser Versuche jemals erfolgreich ist. Wer auf SSH-Keys umstellt, nimmt diese Wette ganz vom Tisch.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein zweiter Grund ist Komfort. Nach der Einrichtung melden Sie sich ohne Passworteingabe an, Automatisierung \u00fcber Skripte und CI\/CD-Pipelines funktioniert reibungslos, und Sie verwalten Zug\u00e4nge zentral \u00fcber Dateien statt \u00fcber geteilte Geheimnisse. Ein SSH-Key l\u00e4sst sich jederzeit einzeln widerrufen, ohne dass andere Nutzer betroffen sind. Diese Anleitung behandelt nicht nur das Anlegen des Schl\u00fcssels, sondern die komplette H\u00e4rtung des Servers, denn ein Schl\u00fcssel allein n\u00fctzt wenig, solange die Passwortanmeldung als Hintert\u00fcr offen bleibt.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"voraussetzungen-software-versionen-und-zugaenge\">Voraussetzungen: Software-Versionen und Zug\u00e4nge<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Bevor wir starten, stellen Sie sicher, dass folgende Komponenten bereitstehen. Die Versionsangaben beziehen sich auf den Stand Juni 2026. \u00c4ltere Versionen funktionieren grunds\u00e4tzlich auch, aber einige H\u00e4rtungsoptionen und der quantenresistente Schl\u00fcsselaustausch setzen aktuelle Software voraus.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Ein Server<\/strong> mit Ubuntu 22.04\/24.04 LTS oder Debian 12, erreichbar per SSH (etwa ein vServer, Root-Server oder eine Cloud-Instanz).<\/li>\n<li><strong>OpenSSH-Server<\/strong> der aktuellen 9.x- oder 10.x-Reihe. Pr\u00fcfen mit <code>ssh -V<\/code>. Ubuntu 24.04 liefert OpenSSH 9.6 oder neuer, die aktuelle Upstream-Reihe ist OpenSSH 10.x (2026).<\/li>\n<li><strong>Ein lokaler Rechner<\/strong> mit OpenSSH-Client (Linux, macOS oder Windows 10\/11 mit aktiviertem OpenSSH-Client).<\/li>\n<li><strong>Ein Benutzerkonto mit sudo-Rechten<\/strong> auf dem Server. Den Root-Login deaktivieren wir sp\u00e4ter, deshalb brauchen Sie zwingend einen normalen Benutzer.<\/li>\n<li><strong>Terminalkenntnisse<\/strong> auf Einsteigerniveau: Sie sollten Befehle eintippen und eine Datei mit <code>nano<\/code> oder <code>vim<\/code> bearbeiten k\u00f6nnen.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Pr\u00fcfen Sie zuerst die installierte Version auf Client und Server. Der Befehl gibt Versionsnummer und die verwendete Krypto-Bibliothek aus:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Auf lokalem Rechner und auf dem Server ausf\u00fchren\nssh -V\n\n# Beispielausgabe:\n# OpenSSH_9.6p1 Ubuntu-3ubuntu13.5, OpenSSL 3.0.13 30 Jan 2024<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Sollte OpenSSH auf dem Server fehlen, installieren Sie es mit <code>sudo apt update &amp;&amp; sudo apt install openssh-server<\/code>. Halten Sie w\u00e4hrend der gesamten Einrichtung eine zweite SSH-Sitzung offen. Falls Sie sich durch eine falsche Konfiguration aussperren, retten Sie sich \u00fcber die noch aktive Verbindung. Diese eine Gewohnheit erspart Ihnen im Ernstfall eine Notfall-Konsole beim Hoster.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"wie-ssh-schluessel-funktionieren-ed25519-statt-rsa\">Wie SSH-Schl\u00fcssel funktionieren: Ed25519 statt RSA<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">SSH-Keys beruhen auf asymmetrischer Kryptographie. Der private Schl\u00fcssel signiert eine vom Server gestellte Challenge, der \u00f6ffentliche Schl\u00fcssel verifiziert diese Signatur. Beide Seiten teilen nie ein gemeinsames Geheimnis, weshalb das Verfahren auch \u00fcber unsichere Netze sicher bleibt. Die Wahl des Schl\u00fcsseltyps entscheidet \u00fcber Sicherheit und Geschwindigkeit. Seit OpenSSH 8.8 (2021) lehnt der Dienst RSA-Schl\u00fcssel mit SHA-1-Signatur grunds\u00e4tzlich ab, weil SHA-1 als gebrochen gilt. Wer heute neu einrichtet, hat zwei sinnvolle Optionen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ed25519 ist die empfohlene Wahl. Der Schl\u00fcssel ist kurz, die Erzeugung und Signaturpr\u00fcfung sind sehr schnell, und die Kurve gilt als robust gegen viele Implementierungsfehler. RSA mit 4096 Bit bleibt sicher, solange SHA-2-Signaturen verwendet werden, ist aber rechenintensiver und produziert deutlich l\u00e4ngere Schl\u00fcssel. Die folgende Tabelle vergleicht die g\u00e4ngigen Typen.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Schl\u00fcsseltyp<\/th><th>Effektive St\u00e4rke<\/th><th>L\u00e4nge \u00f6ffentl. Schl\u00fcssel<\/th><th>Geschwindigkeit<\/th><th>Empfehlung 2026<\/th><\/tr><\/thead><tbody><tr><td>Ed25519<\/td><td>~128 Bit<\/td><td>~68 Zeichen<\/td><td>Sehr hoch<\/td><td>Erste Wahl<\/td><\/tr><tr><td>ECDSA (nistp256)<\/td><td>~128 Bit<\/td><td>~94 Zeichen<\/td><td>Hoch<\/td><td>Akzeptabel<\/td><\/tr><tr><td>RSA 4096<\/td><td>~128 Bit<\/td><td>~720 Zeichen<\/td><td>Mittel<\/td><td>Nur bei Altsystemen<\/td><\/tr><tr><td>RSA 2048<\/td><td>~112 Bit<\/td><td>~380 Zeichen<\/td><td>Mittel<\/td><td>Nicht mehr empfohlen<\/td><\/tr><tr><td>DSA<\/td><td>gebrochen<\/td><td>&#8211;<\/td><td>&#8211;<\/td><td>Entfernt, nicht nutzen<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">DSA-Schl\u00fcssel wurden aus aktuellen OpenSSH-Versionen vollst\u00e4ndig entfernt und d\u00fcrfen nicht mehr verwendet werden. Falls Sie noch sehr alte Ger\u00e4te ansprechen m\u00fcssen, die kein Ed25519 verstehen, greifen Sie zu RSA 4096. F\u00fcr alles andere ist Ed25519 die richtige Entscheidung. Wir nutzen es im weiteren Verlauf dieser Anleitung durchg\u00e4ngig.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-1-ssh-schluesselpaar-mit-ssh-keygen-erzeugen\">Schritt 1: SSH-Schl\u00fcsselpaar mit ssh-keygen erzeugen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Den ersten echten Arbeitsschritt f\u00fchren Sie auf Ihrem lokalen Rechner aus, niemals auf dem Server. Der private Schl\u00fcssel soll dort bleiben, wo Sie physische Kontrolle haben. Erzeugen Sie das Schl\u00fcsselpaar mit <code>ssh-keygen<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Ed25519-Schl\u00fcsselpaar erzeugen\nssh-keygen -t ed25519 -C \"sam@instalinkomailer.com\"\n\n# Ausgabe:\n# Generating public\/private ed25519 key pair.\n# Enter file in which to save the key (\/home\/sam\/.ssh\/id_ed25519):\n# Enter passphrase (empty for no passphrase):\n# Enter same passphrase again:\n# Your identification has been saved in \/home\/sam\/.ssh\/id_ed25519\n# Your public key has been saved in \/home\/sam\/.ssh\/id_ed25519.pub<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Der Parameter <code>-t ed25519<\/code> w\u00e4hlt den Schl\u00fcsseltyp, <code>-C<\/code> setzt einen Kommentar, der den Schl\u00fcssel sp\u00e4ter identifizierbar macht (\u00fcblich ist eine E-Mail-Adresse oder ein Ger\u00e4tename). Best\u00e4tigen Sie den vorgeschlagenen Speicherpfad mit der Eingabetaste.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"warum-die-passphrase-nicht-optional-ist\">Warum die Passphrase nicht optional ist<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Bei der Abfrage nach einer Passphrase sollten Sie nicht einfach Enter dr\u00fccken. Die Passphrase verschl\u00fcsselt Ihren privaten Schl\u00fcssel auf der Festplatte. Ohne sie kann jeder, der Zugriff auf Ihre Datei <code>id_ed25519<\/code> erlangt, sofort alle Ihre Server \u00fcbernehmen. Mit Passphrase ist der gestohlene Schl\u00fcssel wertlos. Damit Sie die Passphrase nicht bei jedem Login eintippen m\u00fcssen, \u00fcbernimmt der SSH-Agent das Zwischenspeichern (dazu sp\u00e4ter mehr). W\u00e4hlen Sie eine lange, eindeutige Passphrase, idealerweise aus Ihrem Passwortmanager. Nach der Erzeugung liegen zwei Dateien im Verzeichnis <code>~\/.ssh\/<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ls -l ~\/.ssh\/id_ed25519*\n\n# -rw------- 1 sam sam  464 14. Jun 10:21 id_ed25519       (privat, geheim halten)\n# -rw-r--r-- 1 sam sam  103 14. Jun 10:21 id_ed25519.pub   (\u00f6ffentlich, darf geteilt werden)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Die Datei mit der Endung <code>.pub<\/code> ist der \u00f6ffentliche Schl\u00fcssel. Nur diese Datei wandert auf den Server. Die Datei ohne Endung ist der private Schl\u00fcssel. Geben Sie ihn niemals weiter, laden Sie ihn nicht in Cloud-Speicher und versenden Sie ihn nicht per E-Mail. Die Berechtigung <code>-rw-------<\/code> (600) auf dem privaten Schl\u00fcssel ist Pflicht. Der SSH-Client verweigert sonst die Nutzung.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-2-den-oeffentlichen-schluessel-auf-den-server-kopieren\">Schritt 2: Den \u00f6ffentlichen Schl\u00fcssel auf den Server kopieren<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Jetzt hinterlegen Sie den \u00f6ffentlichen Schl\u00fcssel auf dem Server. Das komfortabelste Werkzeug daf\u00fcr ist <code>ssh-copy-id<\/code>. Es \u00fcbertr\u00e4gt den Schl\u00fcssel und legt ihn mit den korrekten Berechtigungen in der Datei <code>authorized_keys<\/code> ab. F\u00fcr diesen einen Vorgang melden Sie sich noch einmal per Passwort an:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Syntax: ssh-copy-id benutzer@server-ip\nssh-copy-id sam@203.0.113.10\n\n# Ausgabe:\n# Number of key(s) added: 1\n# Now try logging into the machine, with:  \"ssh 'sam@203.0.113.10'\"\n# and check to make sure that only the key(s) you wanted were added.<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Falls <code>ssh-copy-id<\/code> auf Ihrem System fehlt (etwa unter Windows), kopieren Sie den Schl\u00fcssel manuell. Der folgende Einzeiler h\u00e4ngt Ihren \u00f6ffentlichen Schl\u00fcssel an die richtige Datei an und setzt die Berechtigungen korrekt:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Manuelle Variante (funktioniert auch ohne ssh-copy-id)\ncat ~\/.ssh\/id_ed25519.pub | ssh sam@203.0.113.10 \\\n  \"mkdir -p ~\/.ssh &amp;&amp; chmod 700 ~\/.ssh &amp;&amp; cat &gt;&gt; ~\/.ssh\/authorized_keys &amp;&amp; chmod 600 ~\/.ssh\/authorized_keys\"<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Auf dem Server liegt der \u00f6ffentliche Schl\u00fcssel nun in <code>~\/.ssh\/authorized_keys<\/code>. Diese Datei darf mehrere Schl\u00fcssel enthalten, einen pro Zeile. So geben Sie mehreren Ger\u00e4ten oder Teammitgliedern Zugang, ohne ein Passwort zu teilen. Die strikten Berechtigungen sind entscheidend: Das Verzeichnis <code>~\/.ssh<\/code> muss 700 haben, die Datei <code>authorized_keys<\/code> muss 600 haben. Der SSH-Daemon ignoriert Schl\u00fcssel in zu gro\u00dfz\u00fcgig freigegebenen Dateien aus Sicherheitsgr\u00fcnden stillschweigend.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-3-anmeldung-mit-dem-schluessel-testen\">Schritt 3: Anmeldung mit dem Schl\u00fcssel testen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Bevor Sie irgendetwas h\u00e4rten, pr\u00fcfen Sie, dass der Schl\u00fcssel-Login tats\u00e4chlich funktioniert. Das ist der wichtigste Test der ganzen Anleitung, denn die folgenden Schritte deaktivieren die Passwortanmeldung. Funktioniert der Schl\u00fcssel jetzt nicht, sperren Sie sich aus.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Verbindung aufbauen\nssh sam@203.0.113.10\n\n# Bei Passphrase werden Sie lokal danach gefragt, nicht vom Server.\n# Erfolgreich, wenn Sie ohne Server-Passwort eine Shell erhalten.<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Erhalten Sie eine Shell, ohne dass der Server nach einem Passwort fragt (die Passphrase-Abfrage Ihres lokalen Schl\u00fcssels z\u00e4hlt nicht), ist die Schl\u00fcsselanmeldung aktiv. Bei Problemen liefert der ausf\u00fchrliche Modus wertvolle Hinweise:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Ausf\u00fchrliche Diagnose\nssh -v sam@203.0.113.10\n\n# Achten Sie auf Zeilen wie:\n# debug1: Offering public key: \/home\/sam\/.ssh\/id_ed25519 ED25519\n# debug1: Server accepts key: ...\n# Authenticated to 203.0.113.10 using \"publickey\".<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Die Zeile <code>Authenticated ... using \"publickey\"<\/code> best\u00e4tigt den Erfolg. Steht dort stattdessen <code>using \"password\"<\/code>, hat der Schl\u00fcssel nicht gegriffen, und Sie sollten die Berechtigungen sowie den Pfad pr\u00fcfen, bevor Sie weitermachen. Erst wenn der Schl\u00fcssel-Login sicher klappt, geht es an die H\u00e4rtung des Servers.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-4-die-sshd_config-sichern-und-bearbeiten\">Schritt 4: Die sshd_config sichern und bearbeiten<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Die zentrale Konfigurationsdatei des SSH-Servers liegt unter <code>\/etc\/ssh\/sshd_config<\/code>. Legen Sie zuerst eine Sicherungskopie an, damit Sie jederzeit zur\u00fcck k\u00f6nnen:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Backup der Originalkonfiguration\nsudo cp \/etc\/ssh\/sshd_config \/etc\/ssh\/sshd_config.bak\n\n# Datei zur Bearbeitung \u00f6ffnen\nsudo nano \/etc\/ssh\/sshd_config<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Moderne Ubuntu- und Debian-Systeme lesen zus\u00e4tzlich Dateien aus dem Verzeichnis <code>\/etc\/ssh\/sshd_config.d\/<\/code>. Dort abgelegte Einstellungen \u00fcberschreiben die Hauptdatei. Die sauberste Methode ist deshalb, Ihre H\u00e4rtung in einer eigenen Datei zu b\u00fcndeln, etwa <code>\/etc\/ssh\/sshd_config.d\/99-haertung.conf<\/code>. So bleiben Distributions-Updates der Hauptdatei wirkungslos auf Ihre Einstellungen. Tragen Sie folgende Werte ein:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># \/etc\/ssh\/sshd_config.d\/99-haertung.conf\n\n# Nur Schl\u00fcsselauthentifizierung erlauben\nPubkeyAuthentication yes\nPasswordAuthentication no\nKbdInteractiveAuthentication no\nPermitEmptyPasswords no\n\n# Root-Login verbieten\nPermitRootLogin no\n\n# Nur bestimmte Benutzer zulassen\nAllowUsers sam\n\n# Strenge Berechtigungspr\u00fcfung\nStrictModes yes\n\n# Login-Versuche und Sitzungen begrenzen\nMaxAuthTries 3\nLoginGraceTime 30\nMaxSessions 4<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Die folgende Tabelle erkl\u00e4rt die wichtigsten Direktiven und ihre Wirkung. Jede einzelne reduziert die Angriffsfl\u00e4che messbar.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Direktive<\/th><th>Empfohlener Wert<\/th><th>Wirkung<\/th><\/tr><\/thead><tbody><tr><td>PasswordAuthentication<\/td><td>no<\/td><td>Schaltet die Passwortanmeldung komplett ab, Brute-Force wird sinnlos<\/td><\/tr><tr><td>PubkeyAuthentication<\/td><td>yes<\/td><td>Erlaubt die Schl\u00fcsselanmeldung (Standard, explizit best\u00e4tigen)<\/td><\/tr><tr><td>PermitRootLogin<\/td><td>no<\/td><td>Verhindert direkten Root-Zugang, erzwingt Umweg \u00fcber sudo<\/td><\/tr><tr><td>KbdInteractiveAuthentication<\/td><td>no<\/td><td>Schlie\u00dft interaktive Passwort-Hintert\u00fcren<\/td><\/tr><tr><td>AllowUsers<\/td><td>benutzername<\/td><td>Whitelist, nur genannte Konten d\u00fcrfen sich anmelden<\/td><\/tr><tr><td>MaxAuthTries<\/td><td>3<\/td><td>Trennt die Verbindung nach drei Fehlversuchen<\/td><\/tr><tr><td>LoginGraceTime<\/td><td>30<\/td><td>Zeitfenster in Sekunden f\u00fcr eine erfolgreiche Anmeldung<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-5-konfiguration-pruefen-und-neu-laden\">Schritt 5: Konfiguration pr\u00fcfen und neu laden<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Eine fehlerhafte Konfigurationszeile kann den SSH-Dienst beim Neustart scheitern lassen. Deshalb pr\u00fcfen Sie die Syntax vor dem Neuladen mit dem eingebauten Testmodus. Der Befehl meldet jede problematische Zeile mit Nummer:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Syntaxpr\u00fcfung, gibt bei Fehlern die Zeilennummer aus\nsudo sshd -t\n\n# Keine Ausgabe bedeutet: Konfiguration ist g\u00fcltig.<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Meldet der Test keinen Fehler, laden Sie den Dienst neu. Nutzen Sie <code>reload<\/code> statt <code>restart<\/code>, denn das Neuladen trennt bestehende Sitzungen nicht. Ihre offene Sicherheitsverbindung bleibt also erhalten:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Konfiguration neu laden, bestehende Verbindungen bleiben erhalten\nsudo systemctl reload ssh\n\n# Status kontrollieren\nsudo systemctl status ssh --no-pager<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Auf manchen Systemen hei\u00dft der Dienst <code>sshd<\/code> statt <code>ssh<\/code>. Schl\u00e4gt der erste Befehl fehl, probieren Sie <code>sudo systemctl reload sshd<\/code>. Jetzt der entscheidende Test: \u00d6ffnen Sie ein <strong>neues<\/strong> Terminalfenster (die alte Sitzung behalten Sie offen) und melden Sie sich erneut an. Funktioniert die Schl\u00fcsselanmeldung weiterhin und wird die Passworteingabe verweigert, ist die H\u00e4rtung aktiv. Zur Kontrolle erzwingen Sie testweise einen Passwort-Login, der nun scheitern muss:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Sollte abgelehnt werden, da Passwortlogin deaktiviert ist\nssh -o PubkeyAuthentication=no -o PreferredAuthentications=password sam@203.0.113.10\n\n# Erwartete Ausgabe:\n# sam@203.0.113.10: Permission denied (publickey).<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-6-den-root-login-dauerhaft-abschalten\">Schritt 6: Den Root-Login dauerhaft abschalten<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Das Konto <code>root<\/code> existiert auf jedem Linux-System und ist deshalb das beliebteste Ziel automatisierter Angriffe. Mit <code>PermitRootLogin no<\/code> aus Schritt 4 haben Sie den direkten Root-Login bereits gesperrt. Verwalten Sie das System ab jetzt ausschlie\u00dflich \u00fcber Ihren normalen Benutzer und das Kommando <code>sudo<\/code>. Das hat zwei Vorteile: Angreifer m\u00fcssen sowohl den richtigen Benutzernamen erraten als auch einen g\u00fcltigen Schl\u00fcssel besitzen, und jede administrative Aktion landet nachvollziehbar im sudo-Protokoll.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Pr\u00fcfen Sie, dass Ihr Benutzer tats\u00e4chlich sudo-Rechte hat, bevor Sie sich auf das Verbot verlassen. Andernfalls k\u00f6nnen Sie nach dem Abschalten von Root keine administrativen Aufgaben mehr erledigen:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># sudo-Rechte testen\nsudo whoami\n# Ausgabe muss \"root\" sein\n\n# Falls der Benutzer noch keine sudo-Rechte hat (als root ausf\u00fchren):\n# usermod -aG sudo sam<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn Sie f\u00fcr Automatisierung doch einen Root-Schl\u00fcssel brauchen, etwa f\u00fcr Backups, nutzen Sie statt <code>no<\/code> den Wert <code>prohibit-password<\/code>. Damit ist der Root-Login per Passwort verboten, ein hinterlegter Schl\u00fcssel funktioniert aber weiterhin. F\u00fcr die meisten Anwendungsf\u00e4lle ist das vollst\u00e4ndige <code>no<\/code> die sicherere Wahl. Beschr\u00e4nken Sie zus\u00e4tzlich die erlaubten Benutzer mit <code>AllowUsers<\/code> auf genau die Konten, die Zugang brauchen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-7-die-firewall-mit-ufw-konfigurieren\">Schritt 7: Die Firewall mit UFW konfigurieren<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Eine Firewall begrenzt, welche Dienste \u00fcberhaupt von au\u00dfen erreichbar sind. Unter Ubuntu und Debian ist <code>ufw<\/code> (Uncomplicated Firewall) das einfachste Werkzeug. Wichtig: Erlauben Sie den SSH-Port, <strong>bevor<\/strong> Sie die Firewall aktivieren, sonst trennen Sie sich selbst von der Verbindung.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># SSH zuerst erlauben (Standardport 22)\nsudo ufw allow OpenSSH\n\n# Firewall aktivieren\nsudo ufw enable\n# Best\u00e4tigung mit y\n\n# Status anzeigen\nsudo ufw status verbose<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Standardm\u00e4\u00dfig blockiert UFW nun alle eingehenden Verbindungen au\u00dfer SSH und l\u00e4sst ausgehende Verbindungen zu. \u00d6ffnen Sie weitere Ports nur, wenn Sie sie wirklich brauchen, etwa 80 und 443 f\u00fcr einen Webserver mit <code>sudo ufw allow 80,443\/tcp<\/code>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"den-ssh-port-aendern-sinnvoll-oder-sicherheitstheater\">Den SSH-Port \u00e4ndern: sinnvoll oder Sicherheitstheater?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Viele Anleitungen empfehlen, SSH von Port 22 auf einen anderen Port zu verlegen. Das verhindert keinen gezielten Angriff, ein Portscan findet den Dienst in Sekunden. Es reduziert aber sp\u00fcrbar das Grundrauschen automatisierter Bots und damit Ihre Logdateien. Wenn Sie den Port \u00e4ndern, m\u00fcssen Sie ihn in der sshd_config <strong>und<\/strong> in der Firewall anpassen:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># In \/etc\/ssh\/sshd_config.d\/99-haertung.conf erg\u00e4nzen:\nPort 2222\n\n# Firewall anpassen (neuen Port erlauben, alten entfernen)\nsudo ufw allow 2222\/tcp\nsudo ufw delete allow OpenSSH\n\n# Dienst neu laden und mit neuem Port verbinden\nsudo systemctl reload ssh\nssh -p 2222 sam@203.0.113.10<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Behandeln Sie die Port\u00e4nderung als Komfortma\u00dfnahme gegen Logspam, nicht als echten Schutz. Die eigentliche Sicherheit liefern Schl\u00fcsselauthentifizierung und deaktivierte Passw\u00f6rter.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-8-brute-force-schutz-mit-fail2ban-ergaenzen\">Schritt 8: Brute-Force-Schutz mit Fail2ban erg\u00e4nzen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Auch wenn Passwortlogins deaktiviert sind, bombardieren Bots Ihren Server weiter mit Verbindungsversuchen. Fail2ban liest die Logdateien, erkennt wiederholte Fehlversuche und sperrt die betreffenden IP-Adressen f\u00fcr einen Zeitraum aus. Das schont Ressourcen und h\u00e4lt die Protokolle \u00fcbersichtlich. Installation und Grundkonfiguration sind in wenigen Befehlen erledigt:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Fail2ban installieren\nsudo apt update &amp;&amp; sudo apt install fail2ban -y\n\n# Lokale Konfiguration anlegen (jail.local \u00fcberschreibt jail.conf)\nsudo nano \/etc\/fail2ban\/jail.local<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code># \/etc\/fail2ban\/jail.local\n[sshd]\nenabled = true\nport = 22\nmaxretry = 3\nfindtime = 600\nbantime = 3600<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Mit diesen Werten sperrt Fail2ban eine IP-Adresse f\u00fcr 3600 Sekunden (eine Stunde), wenn sie innerhalb von 600 Sekunden drei Fehlversuche produziert. Starten Sie den Dienst und pr\u00fcfen Sie den Status:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Dienst aktivieren und starten\nsudo systemctl enable --now fail2ban\n\n# Status des SSH-Jails anzeigen\nsudo fail2ban-client status sshd\n\n# Beispielausgabe:\n# Status for the jail: sshd\n# |- Currently banned: 4\n# `- Total banned:     27<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Haben Sie den SSH-Port ge\u00e4ndert, passen Sie den Wert <code>port<\/code> in der jail.local entsprechend an. Eine ausf\u00fchrliche Einrichtung mit eigenen Filtern und Benachrichtigungen behandeln wir in unserer separaten Fail2ban-Anleitung, verlinkt am Ende dieses Beitrags.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-9-quantenresistenten-schluesselaustausch-nutzen\">Schritt 9: Quantenresistenten Schl\u00fcsselaustausch nutzen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Hier kommt das vielleicht \u00fcberraschendste Detail dieser Anleitung: Aktuelle OpenSSH-Versionen sch\u00fctzen Ihre Sitzungen bereits gegen k\u00fcnftige Quantencomputer. Seit OpenSSH 9.0 (2022) ist der hybride Schl\u00fcsselaustausch <code>sntrup761x25519-sha512<\/code> Standard, und seit OpenSSH 9.9 (Ende 2024) kommt zus\u00e4tzlich der auf dem NIST-Standard basierende <code>mlkem768x25519-sha256<\/code> hinzu. Diese Verfahren kombinieren klassische Kurvenkryptographie mit gitterbasierten, quantenresistenten Algorithmen. Selbst wer heute den verschl\u00fcsselten Datenverkehr mitschneidet, kann ihn auch mit einem sp\u00e4teren Quantencomputer nicht entschl\u00fcsseln.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Sie m\u00fcssen daf\u00fcr in der Regel nichts tun, der Schutz ist bei aktuellen Versionen automatisch aktiv. Pr\u00fcfen k\u00f6nnen Sie die ausgehandelten Algorithmen aber explizit. Wer auf Nummer sicher gehen will, schreibt die bevorzugte Reihenfolge selbst fest:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Ausgehandelten Schl\u00fcsselaustausch anzeigen\nssh -v sam@203.0.113.10 2&gt;&amp;1 | grep \"kex:\"\n# debug1: kex: algorithm: mlkem768x25519-sha256\n\n# Optional in \/etc\/ssh\/sshd_config.d\/99-haertung.conf erzwingen:\nKexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Erscheint in der Ausgabe einer der Algorithmen mit <code>mlkem<\/code> oder <code>sntrup<\/code>, ist der quantenresistente Schutz aktiv. Achten Sie nur darauf, dass alte Clients diese Verfahren noch nicht beherrschen. Erzwingen Sie sie also nicht, wenn Sie veraltete Systeme anbinden m\u00fcssen. Wer tiefer einsteigen will, findet in unserem Beitrag zur Post-Quanten-Kryptographie die Hintergr\u00fcnde zu Kyber und Dilithium.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"schritt-10-ssh-agent-und-ssh-config-fuer-den-alltag\">Schritt 10: SSH-Agent und ~\/.ssh\/config f\u00fcr den Alltag<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Damit die Passphrase Ihres Schl\u00fcssels nicht bei jedem Login st\u00f6rt, \u00fcbernimmt der SSH-Agent das sichere Zwischenspeichern f\u00fcr die Dauer Ihrer Sitzung. Sie geben die Passphrase einmal ein, danach l\u00e4uft die Anmeldung automatisch:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># SSH-Agent starten (auf den meisten Systemen bereits aktiv)\neval \"$(ssh-agent -s)\"\n\n# Schl\u00fcssel zum Agenten hinzuf\u00fcgen\nssh-add ~\/.ssh\/id_ed25519\n# Enter passphrase for \/home\/sam\/.ssh\/id_ed25519:\n# Identity added: \/home\/sam\/.ssh\/id_ed25519 (sam@instalinkomailer.com)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Noch komfortabler wird der Alltag mit einer pers\u00f6nlichen Client-Konfiguration in <code>~\/.ssh\/config<\/code>. Dort hinterlegen Sie pro Server einen Kurznamen samt Benutzer, Port und Schl\u00fcsseldatei. Statt langer Befehle tippen Sie dann nur noch <code>ssh produktiv<\/code>:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># ~\/.ssh\/config auf dem lokalen Rechner\nHost produktiv\n    HostName 203.0.113.10\n    User sam\n    Port 2222\n    IdentityFile ~\/.ssh\/id_ed25519\n    IdentitiesOnly yes\n    AddKeysToAgent yes<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Die Option <code>IdentitiesOnly yes<\/code> sorgt daf\u00fcr, dass der Client nur den angegebenen Schl\u00fcssel anbietet und nicht wahllos alle vorhandenen. Das verhindert das verbreitete Problem, dass der Server nach zu vielen falschen Schl\u00fcsseln die Verbindung mit <code>Too many authentication failures<\/code> abbricht. Mit diesem letzten Schritt ist Ihr Setup vollst\u00e4ndig: Schl\u00fcsselanmeldung, geh\u00e4rteter Server, Firewall, Brute-Force-Schutz und bequemer Alltag.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"das-vollstaendige-beispielprojekt-im-ueberblick\">Das vollst\u00e4ndige Beispielprojekt im \u00dcberblick<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Zur Kontrolle hier das komplette, funktionierende Setup in der richtigen Reihenfolge. Wenn Sie diese Befehle in genau dieser Reihenfolge ausf\u00fchren und Ihre Werte (Benutzername, IP, Port) anpassen, erhalten Sie einen vollst\u00e4ndig geh\u00e4rteten SSH-Server.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># ===== LOKALER RECHNER =====\n# 1. Schl\u00fcssel erzeugen\nssh-keygen -t ed25519 -C \"sam@instalinkomailer.com\"\n\n# 2. \u00d6ffentlichen Schl\u00fcssel auf den Server kopieren\nssh-copy-id sam@203.0.113.10\n\n# 3. Schl\u00fcssel-Login testen\nssh sam@203.0.113.10\n\n# ===== AUF DEM SERVER (zweite Sitzung offen halten!) =====\n# 4. Backup und H\u00e4rtungsdatei anlegen\nsudo cp \/etc\/ssh\/sshd_config \/etc\/ssh\/sshd_config.bak\nsudo tee \/etc\/ssh\/sshd_config.d\/99-haertung.conf &gt; \/dev\/null &lt;&lt;'EOF'\nPubkeyAuthentication yes\nPasswordAuthentication no\nKbdInteractiveAuthentication no\nPermitRootLogin no\nAllowUsers sam\nMaxAuthTries 3\nLoginGraceTime 30\nEOF\n\n# 5. Syntax pr\u00fcfen und neu laden\nsudo sshd -t &amp;&amp; sudo systemctl reload ssh\n\n# 6. Firewall\nsudo ufw allow OpenSSH\nsudo ufw enable\n\n# 7. Brute-Force-Schutz\nsudo apt install fail2ban -y\nsudo systemctl enable --now fail2ban\n\n# 8. Verifizieren: neue Sitzung \u00f6ffnen, Passwortlogin muss scheitern\nssh -o PreferredAuthentications=password sam@203.0.113.10  # -&gt; Permission denied<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Behalten Sie die Sicherungsdatei <code>sshd_config.bak<\/code> auf dem Server. Sollte sp\u00e4ter etwas schieflaufen, stellen Sie damit in Sekunden den Ausgangszustand wieder her. Dokumentieren Sie au\u00dferdem, welche Schl\u00fcssel auf welchem Server liegen, damit Sie verlorene oder kompromittierte Schl\u00fcssel gezielt aus der <code>authorized_keys<\/code> entfernen k\u00f6nnen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"haeufige-fehler-beim-ssh-key-einsatz-vermeiden\">H\u00e4ufige Fehler beim SSH-Key-Einsatz vermeiden<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Die folgenden f\u00fcnf Fehler f\u00fchren zu den meisten Support-Anfragen und Selbstaussperrungen. Wer sie kennt, umgeht die typischen Stolperfallen.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Passwortlogin deaktivieren ohne getesteten Schl\u00fcssel.<\/strong> Das ist die klassische Selbstaussperrung. Testen Sie den Schl\u00fcssel-Login immer in einer neuen Sitzung, bevor Sie die alte schlie\u00dfen.<\/li>\n<li><strong>Falsche Dateiberechtigungen.<\/strong> Ist <code>~\/.ssh<\/code> nicht 700 oder <code>authorized_keys<\/code> nicht 600, ignoriert der Server den Schl\u00fcssel kommentarlos. Auch der private Schl\u00fcssel braucht 600.<\/li>\n<li><strong>Privaten Schl\u00fcssel auf den Server kopiert.<\/strong> Auf den Server geh\u00f6rt ausschlie\u00dflich die <code>.pub<\/code>-Datei. Der private Schl\u00fcssel bleibt lokal.<\/li>\n<li><strong>Keine Passphrase gesetzt.<\/strong> Ein ungesch\u00fctzter privater Schl\u00fcssel ist bei Diebstahl sofort einsatzbereit. Eine Passphrase macht ihn wertlos.<\/li>\n<li><strong>Firewall vor der SSH-Regel aktiviert.<\/strong> Wer <code>ufw enable<\/code> ausf\u00fchrt, ohne SSH freizugeben, kappt die eigene Verbindung. Immer zuerst <code>ufw allow OpenSSH<\/code>.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"troubleshooting-die-haeufigsten-ssh-probleme-loesen\">Troubleshooting: Die h\u00e4ufigsten SSH-Probleme l\u00f6sen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn etwas klemmt, hilft fast immer der ausf\u00fchrliche Modus mit <code>ssh -vvv<\/code> sowie ein Blick ins Server-Log mit <code>sudo journalctl -u ssh -n 50<\/code>. Die folgende Tabelle ordnet die h\u00e4ufigsten Meldungen ihrer Ursache und L\u00f6sung zu.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Meldung \/ Symptom<\/th><th>Ursache<\/th><th>L\u00f6sung<\/th><\/tr><\/thead><tbody><tr><td>Permission denied (publickey)<\/td><td>Schl\u00fcssel nicht gefunden oder falsche Berechtigungen<\/td><td>Pfad pr\u00fcfen, <code>chmod 600<\/code> auf Schl\u00fcssel, <code>chmod 700<\/code> auf ~\/.ssh<\/td><\/tr><tr><td>Too many authentication failures<\/td><td>Client bietet zu viele Schl\u00fcssel an<\/td><td><code>IdentitiesOnly yes<\/code> in ~\/.ssh\/config setzen<\/td><\/tr><tr><td>Connection refused<\/td><td>SSH-Dienst l\u00e4uft nicht oder Port blockiert<\/td><td><code>systemctl status ssh<\/code>, Firewall und Port pr\u00fcfen<\/td><\/tr><tr><td>Connection timed out<\/td><td>Falsche IP, Firewall oder Netzwerkproblem<\/td><td>IP und Port verifizieren, <code>ufw status<\/code> pr\u00fcfen<\/td><\/tr><tr><td>Host key verification failed<\/td><td>Serverschl\u00fcssel hat sich ge\u00e4ndert<\/td><td>Alten Eintrag mit <code>ssh-keygen -R hostname<\/code> entfernen<\/td><\/tr><tr><td>sign_and_send_pubkey: signing failed<\/td><td>SSH-Agent l\u00e4uft nicht oder Schl\u00fcssel nicht geladen<\/td><td><code>ssh-add ~\/.ssh\/id_ed25519<\/code> ausf\u00fchren<\/td><\/tr><tr><td>Authentications that can continue: password<\/td><td>Schl\u00fcssel wurde nicht akzeptiert<\/td><td>authorized_keys auf dem Server kontrollieren<\/td><\/tr><tr><td>Bad configuration option<\/td><td>Tippfehler in sshd_config<\/td><td><code>sudo sshd -t<\/code> zeigt die fehlerhafte Zeile<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Haben Sie sich tats\u00e4chlich ausgesperrt, hilft die Notfall-Konsole (KVM, VNC oder serielle Konsole) Ihres Hosters. Dort melden Sie sich lokal an, stellen mit <code>sudo cp \/etc\/ssh\/sshd_config.bak \/etc\/ssh\/sshd_config<\/code> die Sicherung wieder her und entfernen vor\u00fcbergehend Ihre H\u00e4rtungsdatei. Genau f\u00fcr diesen Fall haben Sie die Sicherungskopie aus Schritt 4 angelegt.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"fortgeschrittene-tipps-fuer-maximale-sicherheit\">Fortgeschrittene Tipps f\u00fcr maximale Sicherheit<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wer das Grundsetup beherrscht, kann den Schutz weiter ausbauen. Diese Ma\u00dfnahmen lohnen sich besonders f\u00fcr Server mit mehreren Nutzern oder erh\u00f6htem Schutzbedarf.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"hardware-schluessel-mit-fido2\">Hardware-Schl\u00fcssel mit FIDO2<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Aktuelle OpenSSH-Versionen unterst\u00fctzen Hardware-Token wie YubiKey \u00fcber die Schl\u00fcsseltypen <code>ed25519-sk<\/code> und <code>ecdsa-sk<\/code>. Der private Schl\u00fcsselanteil verl\u00e4sst das Hardware-Token nie, und die Anmeldung erfordert eine physische Ber\u00fchrung. Selbst ein vollst\u00e4ndig kompromittierter Rechner gibt den Schl\u00fcssel nicht preis. Erzeugt wird er mit <code>ssh-keygen -t ed25519-sk<\/code> bei eingestecktem Token.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"ssh-zertifikate-statt-authorized_keys\">SSH-Zertifikate statt authorized_keys<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">In gr\u00f6\u00dferen Umgebungen wird das Verwalten einzelner Schl\u00fcssel pro Server schnell un\u00fcbersichtlich. SSH-Zertifikate l\u00f6sen das: Eine eigene Zertifizierungsstelle (CA) signiert Benutzerschl\u00fcssel mit begrenzter G\u00fcltigkeit. Der Server vertraut nur der CA, nicht jedem einzelnen Schl\u00fcssel. So rotieren Sie Zug\u00e4nge zentral und mit Ablaufdatum, ohne auf jedem Host die <code>authorized_keys<\/code> pflegen zu m\u00fcssen.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"zugriff-auf-ip-bereiche-und-zeitfenster-begrenzen\">Zugriff auf IP-Bereiche und Zeitfenster begrenzen<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Mit der <code>Match<\/code>-Direktive in der sshd_config setzen Sie feingranulare Regeln, etwa nur Schl\u00fcsselanmeldung aus dem Firmennetz. Erg\u00e4nzend l\u00e4sst sich der SSH-Port per Firewall auf bekannte IP-Adressen beschr\u00e4nken. Wer nur aus einem festen B\u00fcro oder \u00fcber ein VPN zugreift, kann den Zugang darauf einschr\u00e4nken und damit das Internet als Angriffsfl\u00e4che praktisch ausschlie\u00dfen. Eine VPN-Verbindung davor, etwa per WireGuard, kombiniert beide Welten elegant.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"ssh-keys-verwalten-rotieren-und-widerrufen\">SSH-Keys verwalten, rotieren und widerrufen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein SSH-Key ist kein Werkzeug, das man einmal einrichtet und dann vergisst. Wie jedes Geheimnis sollte er einen Lebenszyklus haben: erzeugen, einsetzen, rotieren, widerrufen. Verschaffen Sie sich zuerst einen \u00dcberblick, welche Schl\u00fcssel auf einem Server \u00fcberhaupt Zugang haben. Die Datei <code>authorized_keys<\/code> listet jeden berechtigten \u00f6ffentlichen Schl\u00fcssel in einer eigenen Zeile, samt Kommentar am Ende. Anhand des Kommentars erkennen Sie, welches Ger\u00e4t oder welche Person dahintersteht.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Alle berechtigten Schl\u00fcssel auf dem Server anzeigen\ncat ~\/.ssh\/authorized_keys\n\n# Fingerabdruck eines lokalen Schl\u00fcssels pr\u00fcfen\nssh-keygen -lf ~\/.ssh\/id_ed25519.pub\n# 256 SHA256:4f3c... sam@instalinkomailer.com (ED25519)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Verl\u00e4sst eine Person das Team oder geht ein Ger\u00e4t verloren, widerrufen Sie den Zugang, indem Sie die entsprechende Zeile aus der <code>authorized_keys<\/code> entfernen. Das wirkt sofort, ohne Neustart des Dienstes. Den Fingerabdruck aus dem <code>ssh-keygen -lf<\/code> nutzen Sie, um die richtige Zeile sicher zu identifizieren, bevor Sie sie l\u00f6schen. Vermeiden Sie es, einfach die ganze Datei zu leeren, sonst sperren Sie auch die noch ben\u00f6tigten Schl\u00fcssel aus.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Rotation bedeutet, einen Schl\u00fcssel nach einer festgelegten Zeit gegen einen neuen zu tauschen. F\u00fcr pers\u00f6nliche Schl\u00fcssel mit Passphrase ist ein Rhythmus von ein bis zwei Jahren praktikabel. Erzeugen Sie dazu ein neues Paar, hinterlegen Sie den neuen \u00f6ffentlichen Schl\u00fcssel auf allen Servern, testen Sie den Login und entfernen Sie erst danach den alten Eintrag. So entsteht keine L\u00fccke. Bei Schl\u00fcsseln f\u00fcr Automatisierung, etwa in CI\/CD-Pipelines, lohnt sich eine k\u00fcrzere Frist und im Idealfall der Umstieg auf SSH-Zertifikate mit eingebautem Ablaufdatum, die diesen Prozess vollst\u00e4ndig automatisieren.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"haeufig-gestellte-fragen-faq\">H\u00e4ufig gestellte Fragen (FAQ)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"ist-ein-ssh-key-wirklich-sicherer-als-ein-langes-passwort\">Ist ein SSH-Key wirklich sicherer als ein langes Passwort?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Ja, deutlich. Ein Ed25519-Schl\u00fcssel hat eine effektive St\u00e4rke von rund 128 Bit, die kein realistischer Brute-Force-Angriff \u00fcberwindet. Vor allem aber wird beim Login nie ein Geheimnis \u00fcbertragen, das abgefangen werden k\u00f6nnte. Selbst das st\u00e4rkste Passwort kann durch Phishing oder einen kompromittierten Server abhandenkommen. Ein privater Schl\u00fcssel mit Passphrase bleibt auch dann gesch\u00fctzt.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"was-passiert-wenn-ich-meinen-privaten-schluessel-verliere\">Was passiert, wenn ich meinen privaten Schl\u00fcssel verliere?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Ohne den privaten Schl\u00fcssel k\u00f6nnen Sie sich nicht mehr anmelden, deshalb sind ein Backup an einem sicheren Ort und ein zweiter hinterlegter Schl\u00fcssel sinnvoll. Geht der Schl\u00fcssel verloren oder wird gestohlen, entfernen Sie den zugeh\u00f6rigen \u00f6ffentlichen Schl\u00fcssel umgehend aus der <code>authorized_keys<\/code> aller Server. Eine gesetzte Passphrase verschafft Ihnen dabei wertvolle Zeit, da der gestohlene Schl\u00fcssel ohne sie nutzlos ist.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"sollte-ich-den-ssh-port-von-22-auf-einen-anderen-aendern\">Sollte ich den SSH-Port von 22 auf einen anderen \u00e4ndern?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Es ist eine Komfortma\u00dfnahme, kein echter Schutz. Ein Portscan findet den Dienst trotzdem in Sekunden. Die \u00c4nderung reduziert aber das Grundrauschen automatisierter Bots und h\u00e4lt Ihre Logdateien \u00fcbersichtlicher. Die eigentliche Sicherheit liefern die Schl\u00fcsselauthentifizierung und die deaktivierte Passwortanmeldung, nicht die Portnummer.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"funktioniert-ssh-key-authentifizierung-auch-unter-windows\">Funktioniert SSH-Key-Authentifizierung auch unter Windows?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Ja. Windows 10 und 11 enthalten den OpenSSH-Client, den Sie in den optionalen Features aktivieren. Danach funktionieren <code>ssh-keygen<\/code>, <code>ssh<\/code> und <code>~\/.ssh\/config<\/code> genau wie unter Linux. Lediglich <code>ssh-copy-id<\/code> fehlt, weshalb Sie den \u00f6ffentlichen Schl\u00fcssel mit dem manuellen Befehl aus Schritt 2 \u00fcbertragen oder per PowerShell anh\u00e4ngen.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"muss-ich-fuer-jeden-server-ein-eigenes-schluesselpaar-erzeugen\">Muss ich f\u00fcr jeden Server ein eigenes Schl\u00fcsselpaar erzeugen?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Nicht zwingend, aber es ist gute Praxis, pro Ger\u00e4t oder Zweck ein eigenes Paar zu nutzen. So k\u00f6nnen Sie einzelne Schl\u00fcssel gezielt widerrufen, ohne alle Zug\u00e4nge zu erneuern. Ein Schl\u00fcssel pro Arbeitsger\u00e4t und ein separater f\u00fcr die Automatisierung sind ein praktikabler Kompromiss zwischen Sicherheit und Verwaltungsaufwand.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"ist-ssh-gegen-quantencomputer-geschuetzt\">Ist SSH gegen Quantencomputer gesch\u00fctzt?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Der Schl\u00fcsselaustausch ja, sofern Sie eine aktuelle OpenSSH-Version nutzen. Seit OpenSSH 9.0 ist der hybride, quantenresistente Schl\u00fcsselaustausch Standard, seit Version 9.9 kommt der NIST-basierte <code>mlkem768x25519<\/code> hinzu. Damit ist Ihr verschl\u00fcsselter Datenverkehr auch gegen das Mitschneiden f\u00fcr eine sp\u00e4tere Entschl\u00fcsselung gesch\u00fctzt. Aktualisieren Sie Ihre Server regelm\u00e4\u00dfig, dann profitieren Sie automatisch.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"wie-binde-ich-weitere-personen-in-mein-team-ein\">Wie binde ich weitere Personen in mein Team ein?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Jede Person erzeugt ihr eigenes Schl\u00fcsselpaar und schickt Ihnen nur den \u00f6ffentlichen Schl\u00fcssel. Diesen h\u00e4ngen Sie als zus\u00e4tzliche Zeile an die <code>authorized_keys<\/code> des entsprechenden Benutzers an und erg\u00e4nzen den Namen in <code>AllowUsers<\/code>. Bei mehr als einer Handvoll Nutzer lohnt sich der Umstieg auf SSH-Zertifikate, die das zentrale Verwalten und Ablaufenlassen von Zug\u00e4ngen erheblich vereinfachen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"fazit-in-30-minuten-zum-gehaerteten-ssh-server\">Fazit: In 30 Minuten zum geh\u00e4rteten SSH-Server<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein SSH-Key ersetzt das schw\u00e4chste Glied der Server-Sicherheit, das Passwort, durch ein Verfahren, das Brute-Force-Angriffe praktisch ausschlie\u00dft. Mit den zehn Schritten dieser Anleitung haben Sie nicht nur den Schl\u00fcssel eingerichtet, sondern den gesamten Dienst geh\u00e4rtet: Passwortlogins sind deaktiviert, der Root-Zugang ist gesperrt, eine Firewall begrenzt die erreichbaren Dienste, und Fail2ban sperrt aufdringliche Bots aus. Der quantenresistente Schl\u00fcsselaustausch aktueller OpenSSH-Versionen sch\u00fctzt Ihre Verbindungen sogar gegen k\u00fcnftige Bedrohungen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Der wichtigste Grundsatz bleibt: Testen Sie jeden Schritt, bevor Sie die n\u00e4chste T\u00fcr schlie\u00dfen, und halten Sie immer eine zweite Sitzung offen. Mit der Sicherungskopie der Konfiguration und der Notfall-Konsole Ihres Hosters als R\u00fcckversicherung ist die ganze Prozedur risikolos. Halten Sie Ihre Systeme aktuell, rotieren Sie Schl\u00fcssel regelm\u00e4\u00dfig, und Ihr Server bleibt auch in der wachsenden Bedrohungslage 2026 ein hartes Ziel.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"verwandte-beitraege-related-coverage\">Verwandte Beitr\u00e4ge (Related Coverage)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"\/at\/fail2ban-einrichten\/\">Fail2ban einrichten: SSH-Schutz in 12 Schritten<\/a><\/li>\n<li><a href=\"\/at\/wireguard-einrichten\/\">WireGuard einrichten: VPN-Server in 12 Schritten<\/a><\/li>\n<li><a href=\"\/at\/keepassxc-einrichten\/\">KeePassXC einrichten: Passwort-Tresor in 12 Schritten<\/a><\/li>\n<li><a href=\"\/at\/passwortsicherheit\/\">Passwortsicherheit: starke Passw\u00f6rter, Hashing und 2FA<\/a><\/li>\n<li><a href=\"\/at\/https-und-tls\/\">HTTPS und TLS: Wie das Schloss im Browser Sie sch\u00fctzt<\/a><\/li>\n<li><a href=\"\/at\/datenlecks\/\">Datenlecks: Wie sie entstehen und wie Sie sich sch\u00fctzen<\/a><\/li>\n<li><a href=\"\/security\/\">Mehr aus dem Bereich Cybersicherheit<\/a><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"externe-quellen\">Externe Quellen<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/www.openssh.com\/\" target=\"_blank\" rel=\"noopener nofollow\">OpenSSH: Offizielle Projektseite und Release Notes<\/a><\/li>\n<li><a href=\"https:\/\/man.openbsd.org\/sshd_config\" target=\"_blank\" rel=\"noopener nofollow\">sshd_config: Vollst\u00e4ndige Referenz aller Direktiven<\/a><\/li>\n<li><a href=\"https:\/\/ubuntu.com\/server\/docs\/openssh-server\" target=\"_blank\" rel=\"noopener nofollow\">Ubuntu Server: OpenSSH-Dokumentation<\/a><\/li>\n<li><a href=\"https:\/\/wiki.archlinux.org\/title\/OpenSSH\" target=\"_blank\" rel=\"noopener nofollow\">Arch Wiki: OpenSSH-Konfiguration und H\u00e4rtung<\/a><\/li>\n<li><a href=\"https:\/\/infosec.mozilla.org\/guidelines\/openssh\" target=\"_blank\" rel=\"noopener nofollow\">Mozilla Infosec: OpenSSH Security Guidelines<\/a><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Passw\u00f6rter sind die schw\u00e4chste Stelle jedes Servers. Automatisierte Bots scannen rund um die Uhr das Internet nach offenen SSH-Diensten auf Port 22 und probieren in Sekunden tausende Standardpassw\u00f6rter durch. Ein\u2026<\/p>\n","protected":false},"author":2,"featured_media":94,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-93","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security"],"_links":{"self":[{"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/posts\/93","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/comments?post=93"}],"version-history":[{"count":1,"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/posts\/93\/revisions"}],"predecessor-version":[{"id":95,"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/posts\/93\/revisions\/95"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/media\/94"}],"wp:attachment":[{"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/media?parent=93"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/categories?post=93"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/shattered.io\/at\/wp-json\/wp\/v2\/tags?post=93"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}