{"id":231,"date":"2026-06-19T08:00:00","date_gmt":"2026-06-19T08:00:00","guid":{"rendered":"https:\/\/shattered.io\/de\/2026\/06\/19\/ssh-keys-erstellen-linux\/"},"modified":"2026-06-19T08:00:00","modified_gmt":"2026-06-19T08:00:00","slug":"ssh-keys-erstellen-linux","status":"publish","type":"post","link":"https:\/\/shattered.io\/de\/2026\/06\/19\/ssh-keys-erstellen-linux\/","title":{"rendered":"SSH-Keys einrichten: 12 Schritte, 25 Min [2026]"},"content":{"rendered":"\n

SSH-Keys sind das Fundament sicherer Server-Authentifizierung. Wer noch mit Passw\u00f6rtern auf Linux-Server zugreift, riskiert Brute-Force-Angriffe, Credential-Stuffing und kompromittierte Zug\u00e4nge. OpenSSH 10.3, ver\u00f6ffentlicht am 2. April 2026, unterst\u00fctzt jetzt standardm\u00e4\u00dfig den post-quanten-sicheren Schl\u00fcsselaustausch mlk768x25519-sha256<\/strong>. Dieses Tutorial zeigt, wie du in 12 Schritten SSH-Keys erstellst, auf Server \u00fcbertr\u00e4gst, absicherst und professionell verwaltest.<\/p>\n\n\n\n

CVE-2024-6387 (“regreSSHion”) betraf alle OpenSSH-Versionen von 8.5p1 bis 9.7p1 und erm\u00f6glichte Root-Zugriff ohne Authentifizierung. Wer SSH-Keys richtig konfiguriert und Passwort-Login deaktiviert, schlie\u00dft genau diese Angriffsvektoren. Laut BSI-Technischer Richtlinie TR-02102-4 sind Ed25519-Keys die empfohlene Methode f\u00fcr sichere SSH-Authentifizierung in Deutschland.<\/p>\n\n\n\n

Voraussetzungen<\/h2>\n\n\n\n

Bevor du beginnst, pr\u00fcfe folgende Anforderungen:<\/p>\n\n\n\n

Komponente<\/th>Mindestversion<\/th>Empfohlen<\/th>Pr\u00fcfbefehl<\/th><\/tr><\/thead>
OpenSSH Client<\/td>8.0<\/td>10.3 (April 2026)<\/td>ssh -V<\/code><\/td><\/tr>
OpenSSH Server (sshd)<\/td>8.0<\/td>10.3 (April 2026)<\/td>sshd -V<\/code><\/td><\/tr>
Linux Distribution<\/td>Ubuntu 22.04 \/ Debian 12<\/td>Ubuntu 24.04 LTS<\/td>lsb_release -a<\/code><\/td><\/tr>
Root oder sudo<\/td>Pflicht f\u00fcr sshd_config<\/td>Sudo-Zugang<\/td>sudo -v<\/code><\/td><\/tr>
Netzwerkzugang<\/td>Port 22 offen oder custom<\/td>Port nach Wahl<\/td>ss -tlnp<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Dieses Tutorial setzt grundlegende Linux-Kenntnisse voraus. Du ben\u00f6tigst Zugang zu einem lokalen Rechner (Client) und einem entfernten Linux-Server. Die Schritte funktionieren identisch auf Ubuntu, Debian, CentOS\/RHEL und Fedora.<\/p>\n\n\n\n

Wie SSH-Keys funktionieren: Asymmetrische Kryptographie<\/h2>\n\n\n\n

SSH-Schl\u00fcsselpaare basieren auf asymmetrischer Kryptographie. Ein privater Schl\u00fcssel (Private Key) bleibt ausschlie\u00dflich auf deinem lokalen Rechner. Der \u00f6ffentliche Schl\u00fcssel (Public Key) landet auf dem Server in der Datei ~\/.ssh\/authorized_keys<\/code>. Beim Verbindungsaufbau beweist der Client durch eine kryptographische Signatur, dass er den passenden privaten Schl\u00fcssel besitzt, ohne den Schl\u00fcssel selbst zu \u00fcbertragen.<\/p>\n\n\n\n

Dieser Mechanismus macht SSH-Keys fundamentell sicherer als Passw\u00f6rter. Ein abgefangenes Passwort gibt sofortigen Zugang. Ein abgefangener Public Key ist nutzlos ohne den dazugeh\u00f6rigen Private Key. Selbst bei einem Man-in-the-Middle-Angriff kann ein Angreifer die Signatur nicht f\u00e4lschen, sofern du den Server-Fingerprint beim ersten Verbindungsaufbau verifizierst.<\/p>\n\n\n\n

Der Authentifizierungsprozess l\u00e4uft in vier Phasen ab: (1) Der Client sendet den Public-Key-Fingerprint an den Server. (2) Der Server pr\u00fcft, ob dieser Fingerprint in authorized_keys<\/code> vorhanden ist. (3) Der Server sendet eine zuf\u00e4llige Challenge. (4) Der Client signiert die Challenge mit dem Private Key und schickt die Signatur zur\u00fcck. Der Server verifiziert die Signatur mit dem Public Key. Nur wer den Private Key besitzt, kann eine g\u00fcltige Signatur erstellen.<\/p>\n\n\n\n

Algorithmus<\/th>Schl\u00fcssell\u00e4nge<\/th>Sicherheitsniveau<\/th>Geschwindigkeit<\/th>Empfehlung 2026<\/th><\/tr><\/thead>
Ed25519<\/td>256 Bit (fest)<\/td>ca. 128 Bit<\/td>Sehr schnell<\/td>Erste Wahl<\/td><\/tr>
ECDSA (P-384)<\/td>384 Bit<\/td>ca. 192 Bit<\/td>Schnell<\/td>Zweite Wahl<\/td><\/tr>
ECDSA (P-256)<\/td>256 Bit<\/td>ca. 128 Bit<\/td>Schnell<\/td>Dritte Wahl<\/td><\/tr>
RSA-4096<\/td>4096 Bit<\/td>ca. 140 Bit<\/td>Langsam<\/td>Kompatibilit\u00e4t<\/td><\/tr>
RSA-2048<\/td>2048 Bit<\/td>ca. 112 Bit<\/td>Mittel<\/td>Nicht mehr empfohlen<\/td><\/tr>
DSA-1024<\/td>1024 Bit<\/td>Unsicher<\/td>Mittel<\/td>Verboten<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Ed25519, der Goldstandard unter den SSH-Key-Algorithmen, verwendet Elliptic-Curve-Kryptographie auf Basis der Curve25519. Die feste Schl\u00fcsselgr\u00f6\u00dfe von 256 Bit bietet ca. 128 Bit Sicherheit, vergleichbar mit RSA-3072. Der BSI empfiehlt Ed25519 in der TR-02102-4 als bevorzugten Algorithmus f\u00fcr neue SSH-Deployments. OpenSSH 10.0 (April 2025) w\u00e4hlte zudem den post-quanten-sicheren Key-Exchange mlkem768x25519-sha256<\/strong> als neuen Standard, was SSH-Verbindungen bereits heute gegen hypothetische Quantencomputer-Angriffe absichert.<\/p>\n\n\n\n

Schritt 1: OpenSSH-Version pr\u00fcfen und aktualisieren<\/h2>\n\n\n\n

Bevor du einen SSH-Key erstellst, stelle sicher, dass du eine aktuelle OpenSSH-Version verwendest. OpenSSH 10.3 (April 2026) schlie\u00dft mehrere kritische Sicherheitsl\u00fccken und unterst\u00fctzt post-quanten-sichere Schl\u00fcsselaustausch-Algorithmen. Veraltete Versionen vor 9.9p2 sind anf\u00e4llig f\u00fcr CVE-2025-26465 (CVSS 6.8), der Man-in-the-Middle-Angriffe bei aktiviertem VerifyHostKeyDNS erm\u00f6glicht.<\/p>\n\n\n\n

# OpenSSH-Version pr\u00fcfen\nssh -V\n\n# Beispiel-Ausgabe (aktuell):\n# OpenSSH_10.3p1, OpenSSL 3.5.0 8 Apr 2026\n\n# System aktualisieren (Ubuntu\/Debian)\nsudo apt update && sudo apt upgrade -y openssh-client openssh-server\n\n# System aktualisieren (CentOS\/RHEL\/Fedora)\nsudo dnf update openssh openssh-clients openssh-server -y\n\n# SSH-Daemon-Status pr\u00fcfen\nsudo systemctl status sshd\n\n# SSH-Daemon neu starten (nach Updates)\nsudo systemctl restart sshd<\/code><\/pre>\n\n\n\n
Nach dem Update pr\u00fcfe erneut mit ssh -V<\/code>, ob die neue Version aktiv ist. F\u00fcr produktive Systeme empfiehlt sich ein SSH-Audit mit dem Tool ssh-audit<\/code> (verf\u00fcgbar als Python-Paket \u00fcber pip), das alle aktiven Ciphers, MACs und Kex-Algorithmen auf Schwachstellen analysiert und einen detaillierten Bericht erstellt.<\/p>\n\n\n\n
Schritt 2: Ed25519-Schl\u00fcsselpaar erstellen<\/h2>\n\n\n\n
Der Befehl ssh-keygen<\/code> ist das zentrale Werkzeug zur Schl\u00fcsselerstellung. Das Flag -t ed25519<\/code> w\u00e4hlt den Algorithmus, -a 100<\/code> erh\u00f6ht die Anzahl der KDF-Runden (Key Derivation Function) f\u00fcr die Passphrase-Ableitung auf 100, was Brute-Force-Angriffe gegen die verschl\u00fcsselte Schl\u00fcsseldatei erheblich erschwert (Standard: 16 Runden). Das Flag -C<\/code> f\u00fcgt einen Kommentar zur Identifikation hinzu.<\/p>\n\n\n\n
# Ed25519-Schl\u00fcsselpaar mit 100 KDF-Runden erstellen\nssh-keygen -t ed25519 -a 100 -f ~\/.ssh\/id_ed25519 -C \"alice@laptop-2026\"\n\n# Ausgabe des Befehls:\n# Generating public\/private ed25519 key pair.\n# Enter passphrase (empty for no passphrase): [starke Passphrase eingeben]\n# Enter same passphrase again: [Passphrase wiederholen]\n# Your identification has been saved in \/home\/alice\/.ssh\/id_ed25519\n# Your public key has been saved in \/home\/alice\/.ssh\/id_ed25519.pub\n# The key fingerprint is:\n# SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz123456789abcdef alice@laptop-2026\n# The key's randomart image is:\n# +--[ED25519 256]--+\n# |        . o .    |\n# +----[SHA256]-----+\n\n# Erstellte Dateien pr\u00fcfen\nls -la ~\/.ssh\/\n\n# Erwartete Ausgabe:\n# drwx------  2 alice alice 4096 Jun 19 10:23 .\n# -rw-------  1 alice alice  464 Jun 19 10:23 id_ed25519\n# -rw-r--r--  1 alice alice  102 Jun 19 10:23 id_ed25519.pub\n\n# Public Key anzeigen\ncat ~\/.ssh\/id_ed25519.pub\n# Beispielausgabe:\n# ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAbCdEfGhIjKlMnOpQrStUvWxYz alice@laptop-2026<\/code><\/pre>\n\n\n\n
Wichtig: Die Datei id_ed25519<\/code> (Private Key) erh\u00e4lt automatisch Berechtigungen 0600 (rw——-). Die Datei id_ed25519.pub<\/code> (Public Key) bekommt 0644 (rw-r–r–). Diese Berechtigungen sind nicht optional: OpenSSH verweigert die Verwendung eines Private Keys mit zu offenen Berechtigungen mit der Fehlermeldung “Permissions 0644 for ‘\/home\/alice\/.ssh\/id_ed25519’ are too open.”<\/p>\n\n\n\n
W\u00e4hle eine starke Passphrase mit mindestens 20 Zeichen, idealerweise eine Passphrase aus mehreren zuf\u00e4lligen W\u00f6rtern (Diceware-Methode). Die Passphrase sch\u00fctzt den Private Key bei physischem Diebstahl des Rechners oder einem Dateileck. Ohne Passphrase ist jeder, der Zugang zur Schl\u00fcsseldatei erh\u00e4lt, sofort in der Lage, sich auf allen Servern anzumelden, die den zugeh\u00f6rigen Public Key akzeptieren.<\/p>\n\n\n\n
Schritt 3: RSA-4096-Schl\u00fcssel f\u00fcr Legacy-Systeme erstellen<\/h2>\n\n\n\n
F\u00fcr Systeme, die Ed25519 noch nicht unterst\u00fctzen (OpenSSH vor Version 6.5, bestimmte Netzwerkger\u00e4te wie \u00e4ltere Cisco- oder Juniper-Systeme), ist RSA-4096 die empfohlene Alternative. RSA-2048 gilt seit 2024 gem\u00e4\u00df NIST-Empfehlungen als nicht mehr zukunftssicher f\u00fcr langfristige Sicherheit. Das BSI empfiehlt in der TR-02102-4 mindestens RSA-3000 f\u00fcr neue Schl\u00fcssel, praktikabler und h\u00e4ufiger verwendet ist RSA-4096.<\/p>\n\n\n\n
# RSA-4096-Schl\u00fcsselpaar erstellen (Kompatibilit\u00e4ts-Backup)\nssh-keygen -t rsa -b 4096 -a 100 -f ~\/.ssh\/id_rsa_backup -C \"alice@laptop-rsa-2026\"\n\n# Public Key aus vorhandenem Private Key ableiten (Wiederherstellung)\nssh-keygen -y -f ~\/.ssh\/id_ed25519 > ~\/.ssh\/id_ed25519_recovered.pub\n\n# Key-Fingerprint anzeigen (SHA256, Standard ab OpenSSH 6.8)\nssh-keygen -lf ~\/.ssh\/id_ed25519.pub\n\n# MD5-Fingerprint anzeigen (f\u00fcr \u00e4ltere Systeme)\nssh-keygen -lf ~\/.ssh\/id_ed25519.pub -E md5\n\n# Ausgabe SHA256:\n# 256 SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz123456789abcdef alice@laptop-2026 (ED25519)<\/code><\/pre>\n\n\n\n
Benenne Schl\u00fcssel nach Verwendungszweck, nicht nach Algorithmus. Ein Schema wie id_ed25519_prod<\/code>, id_ed25519_staging<\/code>, id_ed25519_github<\/code> und id_ed25519_gitlab<\/code> macht die Verwaltung bei mehreren Servern und Diensten \u00fcbersichtlich. Verwende nie denselben Private Key f\u00fcr verschiedene Sicherheitsbereiche: Produktionsserver und Test-Umgebungen geh\u00f6ren konzeptionell in unterschiedliche Vertrauenszonen.<\/p>\n\n\n\n
Schritt 4: SSH-Verzeichnis und Berechtigungen korrekt setzen<\/h2>\n\n\n\n
Falsche Dateiberechtigungen sind der h\u00e4ufigste Grund, warum SSH-Key-Authentifizierung fehlschl\u00e4gt. Der SSH-Daemon ist absichtlich restriktiv: Zu offene Berechtigungen an ~\/.ssh<\/code> oder authorized_keys<\/code> werden als Sicherheitsrisiko interpretiert und f\u00fchren zum stillen Fallback auf Passwort-Authentifizierung, ohne klare Fehlermeldung an den Benutzer.<\/p>\n\n\n\n
# Korrekte Berechtigungen setzen (auf Client und Server)\nchmod 700 ~\/.ssh\nchmod 600 ~\/.ssh\/id_ed25519\nchmod 644 ~\/.ssh\/id_ed25519.pub\nchmod 600 ~\/.ssh\/config          # falls vorhanden\nchmod 600 ~\/.ssh\/authorized_keys # auf dem Server\n\n# Berechtigungen pr\u00fcfen\nls -la ~\/.ssh\/\n\n# Korrekte Ausgabe:\n# drwx------  2 alice alice 4096 Jun 19 10:23 .\n# -rw-------  1 alice alice  464 Jun 19 10:23 id_ed25519\n# -rw-r--r--  1 alice alice  102 Jun 19 10:23 id_ed25519.pub\n# -rw-------  1 alice alice  412 Jun 19 10:23 authorized_keys\n\n# Besitzer korrigieren (falls Dateien unter anderem User erstellt wurden)\nchown -R $USER:$USER ~\/.ssh\n\n# Home-Verzeichnis auf korrekte Berechtigungen pr\u00fcfen\nls -ld ~\/\n# Muss lauten: drwxr-xr-x (0755) oder drwx------ (0700)\n# NICHT 0777 oder 0775 - SSH w\u00fcrde authorized_keys dann ignorieren!<\/code><\/pre>\n\n\n\n
Auf dem Server muss das Home-Verzeichnis des Benutzers f\u00fcr andere nicht beschreibbar sein. Ein Home-Verzeichnis mit Berechtigungen 0777 oder 0775 veranlasst SSH dazu, die authorized_keys<\/code>-Datei zu ignorieren. Das ist ein bekanntes Problem bei frisch aufgesetzten Servern, bei denen mehrere Administratoren Dateien im Home-Verzeichnis abgelegt haben. Pr\u00fcfe mit ls -ld ~\/<\/code>, ob die Berechtigungen maximal 0755 sind.<\/p>\n\n\n\n
Schritt 5: Public Key auf den Server \u00fcbertragen mit ssh-copy-id<\/h2>\n\n\n\n
Das Werkzeug ssh-copy-id<\/code> \u00fcbertr\u00e4gt den Public Key automatisch und sicher in die authorized_keys<\/code>-Datei des Zielbenutzers auf dem Remoteserver. Es pr\u00fcft dabei, ob der Schl\u00fcssel bereits vorhanden ist (um Duplikate zu vermeiden), erstellt das ~\/.ssh<\/code>-Verzeichnis auf dem Server falls n\u00f6tig, und setzt automatisch die korrekten Berechtigungen. F\u00fcr die einmalige \u00dcbertragung ist noch ein Passwort-Login n\u00f6tig.<\/p>\n\n\n\n
# Public Key mit ssh-copy-id auf Server \u00fcbertragen (Standard-Port 22)\nssh-copy-id -i ~\/.ssh\/id_ed25519.pub alice@server.example.de\n\n# Bei nicht-standardm\u00e4\u00dfigem SSH-Port\nssh-copy-id -i ~\/.ssh\/id_ed25519.pub -p 2222 alice@server.example.de\n\n# Manuelle Alternative (wenn ssh-copy-id nicht verf\u00fcgbar, z.B. auf macOS ohne Homebrew)\ncat ~\/.ssh\/id_ed25519.pub | ssh alice@server.example.de \\\n  \"mkdir -p ~\/.ssh && chmod 700 ~\/.ssh && \\\n   cat >> ~\/.ssh\/authorized_keys && \\\n   chmod 600 ~\/.ssh\/authorized_keys\"\n\n# Verbindung mit Key testen (vor Deaktivierung des Passwort-Logins!)\nssh -i ~\/.ssh\/id_ed25519 alice@server.example.de \"echo 'SSH-Key funktioniert'\"\n\n# Ausgabe bei Erfolg:\n# SSH-Key funktioniert<\/code><\/pre>\n\n\n\n
Nach erfolgreicher \u00dcbertragung pr\u00fcfe unbedingt in einer neuen Session, ob der Key-Login funktioniert, bevor du die Passwort-Authentifizierung deaktivierst. Das ist Schritt 7 in diesem Tutorial. Kein Passwort-Login bedeutet: Brute-Force-Angriffe gegen SSH werden vollst\u00e4ndig unwirksam, da es kein Passwort gibt, das geraten werden k\u00f6nnte.<\/p>\n\n\n\n
Schritt 6: SSH-Agent f\u00fcr komfortables Key-Management einrichten<\/h2>\n\n\n\n
Der SSH-Agent ist ein Hintergrundprozess, der Private Keys entschl\u00fcsselt im RAM h\u00e4lt und auf Anfrage Authentifizierungsoperationen durchf\u00fchrt. Du gibst die Passphrase einmal ein, und der Agent k\u00fcmmert sich f\u00fcr den Rest der Session. Das eliminiert das wiederholte Eingeben der Passphrase bei h\u00e4ufigen SSH-Verbindungen, ohne die Sicherheit des Schl\u00fcssels zu kompromittieren, da der Private Key nie \u00fcber das Netzwerk \u00fcbertragen wird.<\/p>\n\n\n\n
# SSH-Agent starten (falls nicht automatisch via Desktop-Umgebung gestartet)\neval \"$(ssh-agent -s)\"\n\n# Ausgabe:\n# Agent pid 12345\n\n# Private Key zum Agent hinzuf\u00fcgen (Passphrase wird einmalig abgefragt)\nssh-add ~\/.ssh\/id_ed25519\n\n# Key mit Zeitlimit hinzuf\u00fcgen (erlischt nach 8 Stunden = 28800 Sekunden)\nssh-add -t 28800 ~\/.ssh\/id_ed25519\n\n# Alle geladenen Keys anzeigen\nssh-add -l\n\n# Ausgabe:\n# 256 SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz123456789abcdef alice@laptop-2026 (ED25519)\n\n# Alle Keys aus Agent entfernen\nssh-add -D\n\n# Automatischen Agent-Start in ~\/.bashrc oder ~\/.zshrc einrichten\ncat >> ~\/.bashrc << 'EOF'\nif [ -z \"$SSH_AUTH_SOCK\" ]; then\n  eval \"$(ssh-agent -s)\" > \/dev\/null\n  ssh-add ~\/.ssh\/id_ed25519 2>\/dev\/null\nfi\nEOF<\/code><\/pre>\n\n\n\n
Unter GNOME und KDE \u00fcbernimmt der Desktop-Environment die Agent-Verwaltung automatisch. GNOME-Keyring und KWallet integrieren sich in den SSH-Agent und speichern Passphrasen sicher im Betriebssystem-Keystore. Auf Servern ohne Desktop empfiehlt sich das Tool keychain<\/code> (verf\u00fcgbar in den Standard-Repositories), das Keys \u00fcber mehrere Terminals und sogar tmux\/screen-Sessions hinweg persistent verwaltet und dabei einen einzigen ssh-agent-Prozess nutzt.<\/p>\n\n\n\n
Schritt 7: SSH-Server mit sshd_config absichern<\/h2>\n\n\n\n
Die Konfigurationsdatei \/etc\/ssh\/sshd_config<\/code> steuert das Verhalten des SSH-Servers. Die Standardkonfiguration ist auf maximale Kompatibilit\u00e4t ausgelegt, nicht auf Sicherheit. Nach der Einrichtung von SSH-Keys ist das Deaktivieren des Passwort-Logins der wichtigste H\u00e4rtungsschritt. Ohne Passwort-Authentifizierung sind Brute-Force-Angriffe und Credential-Stuffing grunds\u00e4tzlich wirkungslos.<\/p>\n\n\n\n
# Backup der Original-Konfiguration erstellen\nsudo cp \/etc\/ssh\/sshd_config \/etc\/ssh\/sshd_config.bak.$(date +%Y%m%d)\n\n# Konfigurationsdatei bearbeiten\nsudo nano \/etc\/ssh\/sshd_config\n\n# Empfohlene Sicherheitseinstellungen (eine pro Zeile einf\u00fcgen\/\u00e4ndern):\nPort 2222                          # Standard-Port \u00e4ndern (Security by Obscurity)\nPermitRootLogin no                 # Root-Login verbieten\nPasswordAuthentication no          # Passwort-Login deaktivieren\nPubkeyAuthentication yes           # Key-Authentifizierung aktivieren\nKbdInteractiveAuthentication no    # Challenge-Response deaktivieren\nAuthenticationMethods publickey    # Ausschliesslich Public-Key erlauben\nMaxAuthTries 3                     # Maximale Authentifizierungsversuche pro Verbindung\nLoginGraceTime 30                  # 30 Sekunden Timeout fuer Login\nX11Forwarding no                   # X11-Weiterleitung deaktivieren\nAllowTcpForwarding no              # TCP-Tunneling deaktivieren (falls nicht benoetigt)\nClientAliveInterval 300            # Keep-alive alle 5 Minuten senden\nClientAliveCountMax 2              # Nach 2 fehlgeschlagenen Keep-alives trennen\nAllowUsers alice bob               # Nur explizit erlaubte Benutzer\n\n# Konfiguration auf Syntaxfehler pr\u00fcfen (immer vor Neustart!)\nsudo sshd -t\n\n# Falls keine Fehler: SSH-Daemon neu laden (ohne bestehende Sessions zu trennen)\nsudo systemctl reload sshd\n\n# Falls reload nicht ausreicht (z.B. nach Port-\u00c4nderung):\nsudo systemctl restart sshd<\/code><\/pre>\n\n\n\n
Kritisch: Teste die neue Konfiguration in einer bestehenden SSH-Session, bevor du die aktuelle Session schlie\u00dft. \u00d6ffne ein zweites Terminal-Fenster und versuche dich mit dem Key einzuloggen. Nur wenn das funktioniert, schlie\u00dfe die urspr\u00fcngliche Session. Ein Konfigurationsfehler oder eine falsch gesetzte Berechtigung kann dich sonst dauerhaft vom Server aussperren und erfordert dann Konsolen-Zugang beim Hosting-Provider.<\/p>\n\n\n\n
F\u00fcr moderne, sichere Algorithmen in sshd_config erg\u00e4nze explizite Cipher-, MAC- und KEX-Listen. Das schlie\u00dft bekannte schwache Algorithmen wie arcfour, blowfish-cbc, 3des-cbc und diffie-hellman-group1-sha1 aus, die in \u00e4lteren OpenSSH-Versionen noch verf\u00fcgbar waren und in Security-Audits regelm\u00e4\u00dfig als Findings auftauchen:<\/p>\n\n\n\n
# Moderne Algorithmen in \/etc\/ssh\/sshd_config erg\u00e4nzen\nCiphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com\nMACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com\nHostKeyAlgorithms ssh-ed25519,rsa-sha2-256,rsa-sha2-512\nKexAlgorithms mlkem768x25519-sha256,curve25519-sha256,diffie-hellman-group16-sha512\n\n# \u00dcberpr\u00fcfung mit ssh-audit (Open-Source Sicherheits-Scanner)\n# Installation: sudo pip3 install ssh-audit\nssh-audit localhost\n\n# Beispiel-Ausgabe nach H\u00e4rtung:\n# (nfo) SSH version: OpenSSH 10.3 (protocol 2.0)\n# (rec) Good: Following key exchange algorithms are supported:\n#       mlkem768x25519-sha256, curve25519-sha256\n# (good) No problematic algorithms found.<\/code><\/pre>\n\n\n\n
Schritt 8: SSH-Config-Datei f\u00fcr mehrere Server einrichten<\/h2>\n\n\n\n
Die Datei ~\/.ssh\/config<\/code> ist das zentrale Verwaltungsinstrument f\u00fcr mehrere SSH-Verbindungen. Statt langer Befehle mit vielen Flags reicht nach der Konfiguration ein einfaches Alias wie ssh prod<\/code> f\u00fcr eine vollst\u00e4ndig konfigurierte, sichere Verbindung. Die Config-Datei unterst\u00fctzt Wildcards und Vererbung, was die Verwaltung von Dutzenden Servern erheblich vereinfacht. Die Datei liegt unter ~\/.ssh\/config<\/code> und muss Berechtigungen 0600 haben.<\/p>\n\n\n\n
# ~\/.ssh\/config erstellen oder bearbeiten\nnano ~\/.ssh\/config\n\n# Vollst\u00e4ndige Beispiel-Konfiguration:\n\n# Globale Standardeinstellungen (fuer alle Hosts)\nHost *\n  AddKeysToAgent yes\n  IdentitiesOnly yes\n  ServerAliveInterval 60\n  ServerAliveCountMax 3\n  HashKnownHosts yes\n  StrictHostKeyChecking yes\n\n# Produktionsserver\nHost prod\n  HostName prod.example.de\n  User alice\n  Port 2222\n  IdentityFile ~\/.ssh\/id_ed25519_prod\n\n# Staging-Server\nHost staging\n  HostName staging.example.de\n  User alice\n  Port 22\n  IdentityFile ~\/.ssh\/id_ed25519_staging\n\n# Alle internen Server (Wildcard)\nHost *.intern.example.de\n  User alice\n  IdentityFile ~\/.ssh\/id_ed25519_prod\n  Port 2222\n\n# GitHub\nHost github.com\n  User git\n  IdentityFile ~\/.ssh\/id_ed25519_github\n  IdentitiesOnly yes\n\n# Datei-Berechtigungen setzen\nchmod 600 ~\/.ssh\/config\n\n# Verbindung testen\nssh prod<\/code><\/pre>\n\n\n\n
Die Option IdentitiesOnly yes<\/code> in der globalen Sektion ist besonders wichtig: Ohne sie versucht SSH alle verf\u00fcgbaren Identit\u00e4ten aus dem Agent anzubieten, was bei SSH-Servern mit niedrigem MaxAuthTries<\/code>-Limit (hier auf 3 gesetzt) zur automatischen Aussperrung f\u00fchren kann, wenn du viele Keys im Agent hast. Mit IdentitiesOnly yes<\/code> wird nur der explizit in IdentityFile<\/code> angegebene Schl\u00fcssel verwendet.<\/p>\n\n\n\n
Schritt 9: ProxyJump f\u00fcr Bastion-Hosts konfigurieren<\/h2>\n\n\n\n
In professionellen Infrastrukturen sind Produktionsserver oft nicht direkt aus dem Internet erreichbar. Ein Bastion-Host (auch Jump-Server) dient als gesicherter Eintrittspunkt ins interne Netzwerk. Fr\u00fchere L\u00f6sungen nutzten verschachtelte ProxyCommand<\/code>-Konstrukte mit Shell-Expansion; seit OpenSSH 7.3 (August 2016) ist ProxyJump<\/code> die sichere und elegante Alternative. ProxyJump ist sicherer, weil keine Shell-Expansion der Verbindungsparameter stattfindet und deshalb keine Injection-Angriffe m\u00f6glich sind.<\/p>\n\n\n\n
# ProxyJump direkt im Befehl (einmaliger Einsatz)\nssh -J alice@bastion.example.de alice@intern.example.de\n\n# Mehrere Hops verketten (verschachtelte Bastion-Hosts)\nssh -J alice@bastion.example.de,alice@intern-bastion alice@zielserver.intern\n\n# ProxyJump dauerhaft in ~\/.ssh\/config konfigurieren\nHost bastion\n  HostName bastion.example.de\n  User alice\n  IdentityFile ~\/.ssh\/id_ed25519_bastion\n  Port 22\n\nHost intern-*\n  User alice\n  IdentityFile ~\/.ssh\/id_ed25519_prod\n  ProxyJump bastion\n  # Beispiel: 'ssh intern-db' verbindet via bastion -> intern-db\n\n# SCP \u00fcber Bastion-Host\nscp -J bastion datei.tar.gz alice@intern-web:\/home\/alice\/\n\n# SFTP \u00fcber Bastion-Host\nsftp -J bastion alice@intern-db\n\n# Tunnel \u00fcber Bastion (Port-Forwarding durch Jump-Host)\nssh -J bastion -L 5432:localhost:5432 alice@intern-db -N<\/code><\/pre>\n\n\n\n
ProxyJump vermeidet das unsichere Agent-Forwarding. Ein h\u00e4ufiger Fehler in Legacy-Infrastrukturen ist ForwardAgent yes<\/code> f\u00fcr Bastion-Hosts zu aktivieren, damit der Jump-Server sich weiter nach innen authentifizieren kann. Das erlaubt einem kompromittierten Bastion-Host, deine gesamte SSH-Identit\u00e4t f\u00fcr beliebige Verbindungen zu missbrauchen, solange die Session aktiv ist. ProxyJump l\u00f6st das Problem architektonisch: SSH baut zwei separate verschl\u00fcsselte Tunnel auf, und der Bastion-Host sieht ausschlie\u00dflich verschl\u00fcsselten Durchleitungs-Traffic, niemals die Credentials f\u00fcr Innensysteme.<\/p>\n\n\n\n
Schritt 10: SSH-Keys f\u00fcr GitHub und GitLab einrichten<\/h2>\n\n\n\n
GitHub und GitLab unterst\u00fctzen SSH-Keys f\u00fcr sichere Git-Operationen (git clone, push, pull) ohne Passwort-Eingabe. Beide Plattformen empfehlen Ed25519 als bevorzugten Algorithmus. GitHub akzeptiert keine DSA-Keys mehr (seit 2021) und empfiehlt mindestens RSA-3072 f\u00fcr RSA-Keys. F\u00fcr einen dedizierten GitHub-Key erstelle einen separaten Schl\u00fcssel, um bei einer Kompromittierung nur GitHub und nicht alle anderen Server zu gef\u00e4hrden.<\/p>\n\n\n\n
# Dedizierten GitHub-Key erstellen\nssh-keygen -t ed25519 -a 100 -f ~\/.ssh\/id_ed25519_github -C \"alice@laptop-github-2026\"\n\n# Public Key anzeigen (diesen Inhalt bei GitHub einf\u00fcgen)\ncat ~\/.ssh\/id_ed25519_github.pub\n\n# ~\/.ssh\/config f\u00fcr GitHub erweitern\n# (falls noch nicht vorhanden, aus Schritt 8 hinzufuegen)\ncat >> ~\/.ssh\/config << 'EOF'\n\nHost github.com\n  HostName github.com\n  User git\n  IdentityFile ~\/.ssh\/id_ed25519_github\n  IdentitiesOnly yes\n\nHost gitlab.com\n  HostName gitlab.com\n  User git\n  IdentityFile ~\/.ssh\/id_ed25519_gitlab\n  IdentitiesOnly yes\nEOF\n\n# GitHub-SSH-Verbindung testen (nach Upload des Public Key in GitHub Settings)\nssh -T git@github.com\n\n# Erwartete Ausgabe:\n# Hi alice! You've successfully authenticated, but GitHub does not provide shell access.\n\n# GitLab-Verbindung testen\nssh -T git@gitlab.com\n\n# Erwartete Ausgabe:\n# Welcome to GitLab, @alice!<\/code><\/pre>\n\n\n\n
Den Public Key auf GitHub hochladen: Navigiere zu Settings > SSH and GPG keys > New SSH key<\/strong>. Kopiere den vollst\u00e4ndigen Inhalt der .pub<\/code>-Datei inklusive des abschlie\u00dfenden Kommentars (“alice@laptop-github-2026”). W\u00e4hle als Key-Typ “Authentication Key” f\u00fcr regul\u00e4ren Zugang oder “Signing Key”, wenn du Git-Commits mit SSH signieren m\u00f6chtest. GitHub zeigt nach erfolgreichem Upload den SHA256-Fingerprint an, den du mit ssh-keygen -lf ~\/.ssh\/id_ed25519_github.pub<\/code> lokal verifizieren kannst.<\/p>\n\n\n\n
Schritt 11: SSH-Key-Rotation und Ablaufverwaltung<\/h2>\n\n\n\n
Key-Rotation ist eine sicherheitskritische Praxis, die in vielen Organisationen vernachl\u00e4ssigt wird. Das BSI empfiehlt f\u00fcr regul\u00e4re Zug\u00e4nge eine Rotation mindestens alle 12 Monate, f\u00fcr privilegierte Zug\u00e4nge (root, sudo) alle 6 Monate. Nach einem Mitarbeiterabgang oder Sicherheitsvorfall ist sofortige Rotation Pflicht. OpenSSH kennt kein eingebautes Ablaufdatum f\u00fcr Keys, die Verwaltung erfordert Disziplin oder spezialisiertes Tooling.<\/p>\n\n\n\n
# Neuen Key fuer Rotation erstellen\nssh-keygen -t ed25519 -a 100 -f ~\/.ssh\/id_ed25519_new -C \"alice@laptop-rotation-2026\"\n\n# Neuen Public Key auf alle betroffenen Server \u00fcbertragen\n# (alter Key bleibt vor\u00fcbergehend noch aktiv fuer Rollback-Moeglichkeit)\nssh-copy-id -i ~\/.ssh\/id_ed25519_new.pub alice@prod.example.de\nssh-copy-id -i ~\/.ssh\/id_ed25519_new.pub alice@staging.example.de\n\n# Neuen Key testen BEVOR der alte entfernt wird\nssh -i ~\/.ssh\/id_ed25519_new alice@prod.example.de \"echo 'Neuer Key: OK'\"\n\n# Alten Key aus authorized_keys entfernen (auf jedem Server)\n# Fingerprint des alten Keys ermitteln:\nOLD_FINGERPRINT=$(ssh-keygen -lf ~\/.ssh\/id_ed25519.pub | awk '{print $2}')\necho \"Entferne Key mit Fingerprint: $OLD_FINGERPRINT\"\n\n# Auf Server ausfuehren:\nssh alice@prod.example.de \"\n  grep -v '$OLD_FINGERPRINT' ~\/.ssh\/authorized_keys > \/tmp\/ak_new\n  mv \/tmp\/ak_new ~\/.ssh\/authorized_keys\n  chmod 600 ~\/.ssh\/authorized_keys\n\"\n\n# Alten lokalen Key archivieren (nicht loeschen - fuer Forensik 90 Tage aufheben)\nmkdir -p ~\/.ssh\/archive\nmv ~\/.ssh\/id_ed25519 ~\/.ssh\/archive\/id_ed25519_deprecated_$(date +%Y%m%d)\nmv ~\/.ssh\/id_ed25519.pub ~\/.ssh\/archive\/id_ed25519_deprecated_$(date +%Y%m%d).pub\n\n# Neuen Key an Standard-Speicherort verschieben\nmv ~\/.ssh\/id_ed25519_new ~\/.ssh\/id_ed25519\nmv ~\/.ssh\/id_ed25519_new.pub ~\/.ssh\/id_ed25519.pub<\/code><\/pre>\n\n\n\n
F\u00fcr Organisationen mit vielen Servern ist manuelle Key-Rotation fehleranf\u00e4llig und zeitaufwendig. Das Tool HashiCorp Vault<\/strong> bietet SSH-Certificate-Authority-Funktionalit\u00e4t: Vault signiert SSH-Keys mit einer zentral verwalteten CA, und Zertifikate haben eingebaute Ablaufdaten (TTL). Das macht Rotation automatisierbar und vollst\u00e4ndig auditierbar. Eine Alternative ist Teleport<\/strong> (open source), das SSH-Zertifikate mit kurzen Laufzeiten (typisch 8-12 Stunden) und vollst\u00e4ndiger Session-Aufzeichnung kombiniert.<\/p>\n\n\n\n
Schritt 12: Komplette Konfiguration testen und verifizieren<\/h2>\n\n\n\n
Nach Abschluss aller Schritte pr\u00fcfe die Gesamtkonfiguration systematisch. SSH bietet einen eingebauten Verbose-Modus, der detaillierte Informationen \u00fcber den Authentifizierungsprozess liefert. Das Flag -v<\/code> aktiviert einen Verbose-Level, -vvv<\/code> maximale Ausgabe. Bei Problemen mit SSH-Key-Authentifizierung ist dieser Modus das erste Diagnose-Werkzeug.<\/p>\n\n\n\n
# 1. Verbindung im Debug-Modus testen\nssh -vvv alice@server.example.de 2>&1 | grep -E \"(Offering|accepts|succeeded|denied)\"\n\n# Erwartete relevante Ausgaben:\n# debug1: Offering public key: \/home\/alice\/.ssh\/id_ed25519 ED25519 SHA256:...\n# debug1: Server accepts key: \/home\/alice\/.ssh\/id_ed25519 ED25519 SHA256:...\n# debug1: Authentication succeeded (publickey).\n\n# 2. Passwort-Login verifizieren (muss fehlschlagen)\nssh -o PasswordAuthentication=yes -o PubkeyAuthentication=no alice@server.example.de\n# Erwartete Ausgabe:\n# Permission denied (publickey).\n\n# 3. Root-Login verifizieren (muss fehlschlagen)\nssh root@server.example.de\n# Erwartete Ausgabe:\n# Permission denied (publickey).\n\n# 4. Server-Logs auf Anomalien pr\u00fcfen\nsudo tail -50 \/var\/log\/auth.log | grep -E \"Accepted|Failed|Invalid\"\n\n# 5. Aktive SSH-Verbindungen anzeigen\nsudo ss -tnp | grep :22\nsudo who\n\n# 6. ssh-audit f\u00fcr vollst\u00e4ndigen Sicherheitsbericht\npip3 install ssh-audit --quiet\nssh-audit server.example.de 2>\/dev\/null | tail -20<\/code><\/pre>\n\n\n\n
Aktuelle Sicherheitsl\u00fccken in OpenSSH 2024 bis 2026<\/h2>\n\n\n\n
Richtig konfigurierte SSH-Keys reduzieren die Angriffsfl\u00e4che erheblich, ersetzen aber kein zeitnahes Patching. Die letzten zwei Jahre brachten mehrere kritische OpenSSH-Schwachstellen, die auch gut konfigurierte Systeme betrafen und schnelles Handeln erforderten.<\/p>\n\n\n\n
CVE<\/th>CVSS<\/th>Betroffen<\/th>Behoben in<\/th>Auswirkung<\/th><\/tr><\/thead>
CVE-2024-6387<\/td>8.1<\/td>OpenSSH 8.5p1 bis 9.7p1<\/td>9.8p1 (Juli 2024)<\/td>Remote Code Execution als root<\/td><\/tr>
CVE-2025-26465<\/td>6.8<\/td>OpenSSH 6.8p1 bis 9.9p1<\/td>9.9p2 (Feb. 2025)<\/td>Man-in-the-Middle bei VerifyHostKeyDNS<\/td><\/tr>
CVE-2025-26466<\/td>5.9<\/td>OpenSSH 9.5p1 bis 9.9p1<\/td>9.9p2 (Feb. 2025)<\/td>Pre-Auth Denial of Service<\/td><\/tr>
CVE-2025-61984<\/td>7.5<\/td>OpenSSH mit ProxyCommand<\/td>RHEL-Patch 2026<\/td>Code-Ausf\u00fchrung via Shell-Metazeichen<\/td><\/tr>
CVE-2025-61985<\/td>7.5<\/td>OpenSSH mit ssh:\/\/-URI<\/td>RHEL-Patch 2026<\/td>Code-Ausf\u00fchrung via Null-Byte in URI<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
CVE-2024-6387, intern “regreSSHion” genannt, war besonders gravierend: Eine Signal-Handler-Race-Condition im Authentifizierungs-Code erm\u00f6glichte Remote Code Execution als root auf nicht gepatchten Systemen. Das Sicherheitsunternehmen Qualys sch\u00e4tzte, dass \u00fcber 14 Millionen verwundbare OpenSSH-Server \u00f6ffentlich erreichbar waren. Das Exploit erforderte keine Authentifizierung und war \u00fcber einen Zeitraum von Stunden zuverl\u00e4ssig ausf\u00fchrbar. Systeme mit deaktiviertem Passwort-Login waren zwar unattraktiver als Ziel f\u00fcr Brute-Force, aber von CVE-2024-6387 gleicherma\u00dfen betroffen, da die L\u00fccke vor der Authentifizierungsphase lag.<\/p>\n\n\n\n
Die Gegenma\u00dfnahme f\u00fcr CVE-2025-26465 ist simpel: VerifyHostKeyDNS no<\/code> in \/etc\/ssh\/ssh_config<\/code> oder ~\/.ssh\/config<\/code> setzen. Diese Option ist standardm\u00e4\u00dfig deaktiviert, wird aber in DANE-basierten Infrastrukturen aktiviert. Wer DANE f\u00fcr SSH nutzt, sollte auf OpenSSH 9.9p2 oder neuer aktualisieren. CVE-2025-26466 (DoS) erfordert kein spezielles Konfigurationsmerkmal, ist aber durch das Update auf 9.9p2 ebenfalls behoben.<\/p>\n\n\n\n
7 h\u00e4ufige Fehler bei der SSH-Key-Einrichtung<\/h2>\n\n\n\n
Fehler 1: Kein Passphrase auf dem Private Key.<\/strong> Ein Private Key ohne Passphrase ist bei Diebstahl des Rechners oder einem Datenleck sofort nutzbar. Der SSH-Agent eliminiert die l\u00e4stige Passphrase-Eingabe, ohne die Sicherheit zu opfern. Setze immer eine starke Passphrase und nutze den Agent f\u00fcr den t\u00e4glichen Betrieb.<\/p>\n\n\n\n
Fehler 2: Falsche Dateiberechtigungen.<\/strong> authorized_keys<\/code> mit 0644 statt 0600, oder ~\/.ssh<\/code> mit 0755 statt 0700 f\u00fchrt dazu, dass SSH den Key ignoriert und nur “Permission denied” meldet. Pr\u00fcfe Berechtigungen mit ls -la ~\/.ssh\/<\/code> und korrigiere mit chmod<\/code>.<\/p>\n\n\n\n
Fehler 3: Agent-Forwarding auf untrusted Hosts.<\/strong> ForwardAgent yes<\/code> in der globalen Host *<\/code>-Sektion erlaubt jedem Server, deinen SSH-Agent zu nutzen, auch kompromittierten. Aktiviere Agent-Forwarding nur f\u00fcr explizit vertrauensw\u00fcrdige Hosts, oder nutze ProxyJump als sichere Alternative.<\/p>\n\n\n\n
Fehler 4: Einen Key f\u00fcr alle Dienste.<\/strong> Derselbe Private Key f\u00fcr Produktionsserver, GitHub, GitLab und Unternehmens-VPN bedeutet, dass eine Kompromittierung alle Zug\u00e4nge gleichzeitig \u00f6ffnet. Separate Keys pro Sicherheitskontext mit ~\/.ssh\/config<\/code> verwalten.<\/p>\n\n\n\n
Fehler 5: Passwort-Login nach Key-Setup aktiv lassen.<\/strong> SSH-Keys einrichten und Passwort-Auth aktiv lassen ist wie eine Alarmanlage installieren und die Hintert\u00fcr offen stehen lassen. Nach Verifikation des Key-Logins sofort PasswordAuthentication no<\/code> in sshd_config setzen.<\/p>\n\n\n\n
Fehler 6: StrictHostKeyChecking deaktivieren.<\/strong> Das Flag -o StrictHostKeyChecking=no<\/code> oder die Config-Option StrictHostKeyChecking no<\/code> schaltet die Man-in-the-Middle-Erkennung vollst\u00e4ndig aus. In CI\/CD-Pipelines verwende ssh-keyscan<\/code>, um Server-Fingerprints vorab sicher in known_hosts<\/code> einzutragen, statt die Pr\u00fcfung zu deaktivieren.<\/p>\n\n\n\n
Fehler 7: Keys nie rotieren.<\/strong> Ein SSH-Key, der seit Jahren nicht rotiert wurde, k\u00f6nnte aus einem ehemaligen Mitarbeiter-Laptop stammen, der schon l\u00e4ngst aus dem Unternehmen ausgeschieden ist. F\u00fchre ein Inventar aller authorized_keys<\/code>-Eintr\u00e4ge auf allen Servern und plane regelm\u00e4\u00dfige Rotation. Das BSI-Framework Allianz f\u00fcr Cyber-Sicherheit empfiehlt SSH-Key-Inventarisierung als Bestandteil des Asset-Managements.<\/p>\n\n\n\n
Erweiterte Techniken: SSH-Zertifikate und CI\/CD-Integration<\/h2>\n\n\n\n
SSH-Zertifikate als skalierbare Alternative<\/h3>\n\n\n\n
SSH-Zertifikate l\u00f6sen das Skalierungsproblem bei statischen Keys. Statt jeden Public Key auf jeden Server zu kopieren, vertrauen alle Server der SSH-Certificate-Authority (CA). Neue Benutzer erhalten ein zeitlich befristetes Zertifikat. Bei Mitarbeiterabgang l\u00e4uft das Zertifikat automatisch ab. Die Infrastruktur ben\u00f6tigt keine Server-seitigen \u00c4nderungen pro Benutzer, was bei 100 oder 1000 Servern den Aufwand dramatisch reduziert.<\/p>\n\n\n\n
# SSH-CA erstellen (einmalig, sicher offline aufbewahren)\nssh-keygen -t ed25519 -f \/etc\/ssh\/ca_key -C \"SSH-CA Organization XYZ 2026\"\n\n# CA-Public-Key auf Servern verteilen (in \/etc\/ssh\/sshd_config):\n# TrustedUserCAKeys \/etc\/ssh\/ca_key.pub\n\n# Benutzer-Key mit CA signieren (30-Tage-Gueltigkeit)\nssh-keygen -s \/etc\/ssh\/ca_key \\\n  -I \"alice@example.de-2026-06-19\" \\\n  -n alice,deploy \\\n  -V +30d \\\n  ~\/.ssh\/id_ed25519.pub\n\n# Ergebnis: ~\/.ssh\/id_ed25519-cert.pub\n\n# Zertifikat-Details anzeigen und verifizieren\nssh-keygen -Lf ~\/.ssh\/id_ed25519-cert.pub\n\n# Ausgabe (vereinfacht):\n# Type: ssh-ed25519-cert-v01@openssh.com user certificate\n# Public key: ED25519-CERT SHA256:...\n# Signing CA: ED25519 SHA256:...\n# Key ID: \"alice@example.de-2026-06-19\"\n# Valid: from 2026-06-19T00:00:00 to 2026-07-19T00:00:00\n# Principals: alice, deploy<\/code><\/pre>\n\n\n\n
SSH-Keys in CI\/CD-Pipelines sicher verwalten<\/h3>\n\n\n\n
Automatisierte Deployment-Pipelines brauchen SSH-Zugang ohne interaktive Passphrase-Eingabe. Das direkte Speichern von Private Keys in Repository-Dateien ist ein kritischer Fehler, der in Git-Histories verbleibt und bei \u00f6ffentlichen Repositories sofortige Kompromittierung bedeutet. Die sichere L\u00f6sung kombiniert dedizierte Deploy-Keys, minimale Berechtigungen in authorized_keys<\/code> und einen Secret-Manager wie GitHub Actions Secrets oder HashiCorp Vault.<\/p>\n\n\n\n
# Dedizierten Deploy-Key erstellen (ohne Passphrase fuer Automation, aber mit Einschraenkungen)\nssh-keygen -t ed25519 -a 100 -f ~\/.ssh\/id_ed25519_deploy -C \"ci-deploy@github-actions-2026\" -N \"\"\n\n# Auf Server: authorized_keys mit command-Einschraenkung (nur git pull erlaubt)\n# ~\/.ssh\/authorized_keys Eintrag:\n# command=\"git -C \/var\/www\/app pull --ff-only\",no-pty,no-agent-forwarding,no-port-forwarding ssh-ed25519 AAAA...\n\n# GitHub Actions Workflow-Beispiel (als Kommentar, nicht als Shell-Code):\n# - name: Setup SSH Deploy Key\n#   run: |\n#     mkdir -p ~\/.ssh\n#     echo \"${{ secrets.DEPLOY_PRIVATE_KEY }}\" > ~\/.ssh\/id_ed25519\n#     chmod 600 ~\/.ssh\/id_ed25519\n#     ssh-keyscan -H prod.example.de >> ~\/.ssh\/known_hosts\n#\n# - name: Deploy\n#   run: ssh deploy@prod.example.de  # Nur 'git pull' moeglich durch command= Einschraenkung\n\n# Vault-basierte Alternative fuer kurze SSH-Zertifikate (empfohlen):\n# vault write ssh\/sign\/deploy-role \\\n#   public_key=@~\/.ssh\/id_ed25519.pub \\\n#   valid_principals=deploy \\\n#   ttl=1h<\/code><\/pre>\n\n\n\n
Fehlerbehebung: 8 h\u00e4ufige SSH-Verbindungsprobleme<\/h2>\n\n\n\n
Fehlermeldung<\/th>Wahrscheinliche Ursache<\/th>L\u00f6sung<\/th><\/tr><\/thead>
Permission denied (publickey)<\/td>Key nicht in authorized_keys, oder falsche Berechtigungen<\/td>ssh-copy-id erneut ausf\u00fchren; chmod 600 ~\/.ssh\/authorized_keys<\/td><\/tr>
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED<\/td>Server-Key ge\u00e4ndert oder MitM-Verdacht<\/td>ssh-keygen -R hostname; Fingerprint beim Admin pr\u00fcfen<\/td><\/tr>
Could not open a connection to your authentication agent<\/td>SSH-Agent nicht gestartet<\/td>eval “$(ssh-agent -s)” ausf\u00fchren<\/td><\/tr>
Bad permissions. Try removing permissions for user<\/td>authorized_keys oder ~\/.ssh zu offen<\/td>chmod 700 ~\/.ssh; chmod 600 ~\/.ssh\/authorized_keys<\/td><\/tr>
Too many authentication failures<\/td>MaxAuthTries \u00fcberschritten (Agent bietet zu viele Keys an)<\/td>IdentitiesOnly yes in ~\/.ssh\/config setzen<\/td><\/tr>
Connection refused<\/td>sshd nicht gestartet oder falscher Port<\/td>sudo systemctl start sshd; Port in ssh-Befehl angeben<\/td><\/tr>
No supported authentication methods available<\/td>Nur PubkeyAuthentication aktiv, aber Key fehlt auf Server<\/td>Key auf Server kopieren; authorized_keys pr\u00fcfen<\/td><\/tr>
Host key verification failed<\/td>known_hosts-Eintrag veraltet oder falsch<\/td>ssh-keygen -R hostname; neuen Fingerprint beim Admin verifizieren<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Bei hartn\u00e4ckigen Problemen hilft die Kombination aus ssh -vvv<\/code> auf dem Client und sudo tail -f \/var\/log\/auth.log<\/code> auf dem Server. OpenSSH protokolliert pr\u00e4zise, warum eine Authentifizierung scheitert. Ein h\u00e4ufig \u00fcbersehenes Problem auf RHEL- und CentOS-Systemen: SELinux blockiert den SSH-Daemon bei falschen Dateikontexten. Der Befehl restorecon -Rv ~\/.ssh\/<\/code> stellt die korrekten SELinux-Kontexte wieder her. Bei Ubuntu kann AppArmor \u00e4hnliche Probleme verursachen; sudo apparmor_status<\/code> zeigt den Status.<\/p>\n\n\n\n
Ein weiterer h\u00e4ufiger Fall: der Server akzeptiert den Key, aber der Login schl\u00e4gt danach trotzdem fehl. Das deutet auf ein Problem mit der Benutzerumgebung hin (\/etc\/nologin<\/code> vorhanden, Shell in \/etc\/passwd<\/code> nicht ausf\u00fchrbar, oder das Konto ist deaktiviert). Pr\u00fcfe mit sudo getent passwd alice<\/code> die Shell und mit sudo passwd -S alice<\/code> den Account-Status.<\/p>\n\n\n\n
Verwandte Artikel<\/h2>\n\n\n\n
Weiterf\u00fchrende Lekt\u00fcre auf shattered.io<\/h3>\n\n\n\n