Verwendete Software und Versionen
Diese Erklärung bezieht sich auf:
- SSH-Protokoll: OpenSSH 9.0+ (Standard auf modernen Systemen)
- Kryptographie: RSA-4096, Ed25519, ECDSA-256
- SSH-Client: ssh, ssh-keygen, ssh-add, ssh-agent
- Kontext: Distributions-übergreifende SSH-Grundlagen
SSH-Keys ersetzen Passwörter durch einen mathematische Beweis
SSH-Verbindungen ohne Passwörter funktionieren über asymmetrische Kryptographie mit Schlüsselpaaren. Der private Schlüssel (id_rsa) signiert Authentifizierungs-Nachrichten, der entsprechende öffentliche Schlüssel (id_rsa.pub) verifiziert diese Signaturen. Der Server speichert öffentliche Schlüssel in ~/.ssh/authorized_keys - Clients beweisen ihre Identität durch die Signatur-Erzeugung mit dem privaten Schlüssel ohne eine Passwort-Übertragung.
Artikel 1 erklärt Port-basierte Netzwerk-Kommunikation. SSH erweitert diese Grundlagen um verschlüsselte Verbindungen auf Port 22 mit kryptographischer Authentifizierung. Ein SSH-Client verbindet sich zu 192.168.1.100:22 und führt ein Schlüsselaustausch-Protokoll durch - der mathematische Beweis der Schlüssel-Identität ersetzt die Passwort-Eingabe vollständig.
RSA-4096-Schlüssel bieten 152-Bit-Sicherheit gegen aktuelle Angriffsmethoden. Ed25519-Schlüssel verwenden elliptische Kurven-Kryptographie mit besserer Leistung bei gleichwertiger Sicherheit. Ein ssh-keygen -t ed25519 erstellt einen 256-Bit-Ed25519-Schlüssel in weniger als einer Sekunde - RSA-4096-Schlüssel benötigen dafür mehrere Sekunden Generationszeit.
Der SSH-Agent speichert entschlüsselte Schlüssel im Arbeitsspeicher
Private SSH-Schlüssel werden meist mit Passphrase verschlüsselt gespeichert. Der SSH-Agent lädt diese Schlüssel einmalig, nach der Passphrase-Eingabe, in den Arbeitsspeicher und signiert SSH-Anfragen automatisch. Ein ssh-add ~/.ssh/id_ed25519 fügt den Schlüssel zum Agent hinzu - nachfolgende SSH-Verbindungen funktionieren ohne weitere Authentifizierung.
SSH-Agent-Forwarding leitet lokale SSH-Keys über SSH-Verbindungen weiter. Ein ssh -A user@server1 ermöglicht es, von server1 aus weitere SSH-Verbindungen mit lokalen Keys aufzubauen. Der Agent läuft nur auf dem lokalen Client - entfernte Server erhalten niemals private Schlüssel, sondern können nur Signatur-Anfragen stellen.
Keychain und ssh-ident automatisieren SSH-Agent-Management über Shell-Sessions hinweg. Diese Tools starten SSH-Agent automatisch beim Login und laden konfigurierte Schlüssel ohne weitere Benutzerinteraktion. Desktop-Umgebungen wie GNOME oder KDE integrieren SSH-Agent in ihre Schlüsselbund-Systeme für eine Schlüsselwort-Eingabe über die grafische Oberflächen.
Die Schlüssel-Generierung folgt den kryptographischen Standards
Ed25519-Schlüssel bieten moderne Kryptographie mit optimaler Sicherheit-Leistung-Balance:
ssh-keygen -t ed25519 -C "user@hostname-beschreibung"
Dieser Befehl erstellt ~/.ssh/id_ed25519 (privater Schlüssel) und ~/.ssh/id_ed25519.pub (öffentlicher Schlüssel). Der Comment-Parameter (-C) hilft bei der Schlüssel-Identifikation in der authorized_keys-Dateien bei mehreren Einträgen.
RSA-Schlüssel erfordern mindestens 4096-Bit-Länge für eine angemessene Sicherheit:
ssh-keygen -t rsa -b 4096 -C "user@hostname-rsa"
ECDSA-Schlüssel verwenden elliptische Kurven mit verschiedenen Kurven-Größen:
ssh-keygen -t ecdsa -b 256 -C "user@hostname-ecdsa"
Die Passphrase verschlüsselt den privaten Schlüssel mit AES-128-CBC. Starke Passphrases enthalten Zufälligkeit und Länge - Diceware-Methode generiert sichere, merkbare Passphrases aus Wörterbuch-Listen. Eine leere Passphrase erstellt unverschlüsselte private Schlüssel für automatisierte Systeme.
Sichere Automatisierung verwendet verschlüsselte Schlüssel: SSH-Agent mit keychain lädt Schlüssel einmalig beim Login nach der Passphrase-Eingabe. Desktop-Keyring-Systeme (GNOME Keyring, KDE KWallet) speichern Passphrases verschlüsselt und entsperren SSH-Keys automatisch. Systemd-User-Services starten ssh-agent mit vorgeladenen Schlüsseln ohne Passphrase-Wiederholung. Command-restricted Keys führen ausschließlich vordefinierte Befehle aus statt vollständigen Shell-Zugriff.
Der öffentliche Schlüssel ermöglichen den Server-Zugriff
Der öffentliche Schlüssel wird in ~/.ssh/authorized_keys auf dem Zielserver gespeichert:
# Lokaler öffentlicher Schlüssel
cat ~/.ssh/id_ed25519.pub
# Auf dem Server hinzufügen
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIG... user@hostname" >> ~/.ssh/authorized_keys
Jede Zeile in authorized_keys repräsentiert einen autorisierten öffentlichen Schlüssel. Das Format ist: schlüssel-typ öffentlicher-schlüssel comment. Multiple Schlüssel ermöglichen Zugriff von verschiedenen Clients oder Backup-Schlüssel für Notfälle.
ssh-copy-id automatisiert die Schlüssel-Installation auf den entfernten Servern:
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@192.168.1.100
Dieser Befehl kopiert den spezifizierten öffentlichen Schlüssel nach ~/.ssh/authorized_keys und setzt korrekte Dateiberechtigungen (600 für authorized_keys, 700 für .ssh-Verzeichnis). Der erste Zugriff erfordert noch eine Passwort-Authentifizierung.
Erweiterte Schlüssel-Sicherheit und Beschränkungen
SSH-Schlüssel unterstützen Zugriffs-Beschränkungen direkt in der authorized_keys:
command="/usr/local/bin/sicherungsskript",no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAAC3NzaC1lZDI1NTE5... backup@client
from="192.168.1.0/24",no-agent-forwarding ssh-ed25519 AAAAC3NzaC1lZDI1NTE5... admin@workstation
Command-Restriction führt nur spezifische Befehle aus - der Schlüssel kann ausschließlich das definierte Sicherungsskript ausführen. From-Restriction limitiert Zugriff auf bestimmte IP-Adressbereiche unterstützt aber auch Hostnames: from="workstation.example.com" oder Wildcards from="*.company.com". Bei dynamischen IP-Adressen entstehen DNS-Caching-Probleme - breitere Netzwerk-Bereiche oder VPN-basierte Lösungen funktionieren zuverlässiger. Diese Beschränkungen funktionieren unabhängig von der SSH-Client-Konfiguration.
Eine Certificate-basierte SSH-Authentifizierung skaliert besser für große Infrastrukturen. Eine Zertifizierungsstelle (CA) signiert Benutzer-Schlüssel mit Gültigkeitsdauer und Zugriffs-Bereichen. Server vertrauen der CA statt individuellen öffentlichen Schlüsseln - neue Benutzer benötigen keine Server-Konfiguration.
FIDO2/WebAuthn-Hardware-Token bieten eine physische Zwei-Faktor-Authentifizierung für SSH:
ssh-keygen -t ed25519-sk -C "user@hostname-yubikey"
Diese Schlüssel erfordern eine physische Token-Berührung für jede Authentifizierung. Der private Schlüssel verlässt niemals den Hardware-Token. Gestohlene “Schlüssel-Dateien” enthalten nur Token-Referenzen, die ohne physischen Token wertlos sind.
Monitoring und Audit von SSH-Verbindungen
SSH-Server-Protokolle in /var/log/auth.log (Debian/Arch) oder /var/log/authlog (OpenBSD) zeigen Verbindungsversuche und Authentifizierungen:
Feb 15 10:30:15 server sshd[1234]: Accepted publickey for admin from 192.168.1.50 port 54321 ssh2: ED25519 SHA256:abc123...
Feb 15 10:35:22 server sshd[5678]: Failed password for root from 203.0.113.10 port 12345 ssh2
Diese Protokoll-Einträge identifizieren erfolgreiche Key-Authentifizierungen und fehlgeschlagene Passwort-Versuche. SSH-Key-Fingerprints in den Protokollen ermöglichen Zuordnung zu spezifischen Schlüsseln. Fail2ban blockiert IP-Adressen nach wiederholten fehlgeschlagenen Versuchen automatisch.
SSH-Sitzungs-Aufzeichnung mit dem Standard-Unix-Tool script dokumentiert administrative Tätigkeiten:
script -t 2>timing.log -a session.log
# Administrative Arbeit
exit
Zur Nachverfolgung ermöglichen diese Aufzeichnungen ein Replay der SSH-Sessions. Zentrale Protokollierung über rsyslog oder journald sammelt SSH-Session-Aufzeichnungen von mehreren Servern an einer Stelle.
LastLog und wtmp zeigen verschiedene Anmeldungstypen:
# Alle Login-Sessions (auch lokale Konsole)
last -i root
root tty1 0.0.0.0 Mon Sep 18 16:41 - 16:42 (00:01)
# Nur echte root-Anmeldungen, nicht sudo-Wechsel
lastlog -u root
Benutzername Port Letzter
root **Noch nie angemeldet**
lastlog registriert nur direkte Anmeldungen (ssh root@server), nicht privilege escalation (sudo su -). Diese Unterscheidung ist sicherheitsrelevant: Häufige lastlog-root-Einträge können auf direkte root-SSH-Angriffe hinweisen, während sudo-Nutzung in separaten Logs erscheint.
Troubleshooting häufiger SSH-Key-Probleme
Verbindungsfehler “Permission denied (publickey)” entstehen meist durch falsche Dateiberechtigungen:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/authorized_keys
SSH-Server verweigern Verbindungen bei zu offenen Berechtigungen für die Sicherheitsdateien. World-readable private Schlüssel (644) oder beschreibbare authorized_keys (666) werden ignoriert. Diese strikten Berechtigungen verhindern eine Schlüssel-Kompromittierung durch andere Benutzer.
SSH-Agent-Probleme zeigen sich durch Verbindungsfehler:
ssh-add -l
Could not open a connection to your authentication agent.
# SSH funktioniert trotzdem mit unverschlüsselten Keys
ssh server.example.com
Last login: Sun Sep 14 19:24:37 2025 from 192.168.1.50
OpenBSD 7.7 (GENERIC.MP) #2: Sun Jun 29 09:07:00 MDT 2025
Der SSH-Agent ist nur für verschlüsselte Keys mit Passphrases erforderlich. Unverschlüsselte Keys funktionieren direkt ohne Agent. Bei verschlüsselten Keys:
# SSH-Agent starten
eval $(ssh-agent)
# SSH-Agent-Status prüfen
ssh-add -l
# Alle Schlüssel entfernen
ssh-add -D
# Schlüssel erneut hinzufügen
ssh-add ~/.ssh/id_ed25519
SSH_AUTH_SOCK-Umgebungsvariable zeigt den SSH-Agent-Socket-Pfad. Fehlende oder falsche Werte verhindern die SSH-Agent-Kommunikation. Neue Terminal-Sessions erben die SSH-Agent-Umgebung nicht automatisch - keychain oder ssh-ident lösen dieses Problem.
Host-Key-Verification-Failures entstehen bei geänderten Server-Schlüsseln:
ssh-keygen -R hostname.example.com
ssh-keygen -R 192.168.1.100
Diese Befehle entfernen bekannte Host-Schlüssel aus ~/.ssh/known_hosts. Eine Server-Neuinstallationen oder eine IP-Adress-Änderungen erfordern Host-Key-Updates. StrictHostKeyChecking=no deaktiviert die Verifikation, reduziert aber die Sicherheit gegen Man-in-the-Middle-Angriffe.
Ein Verbose SSH-Debug-Output identifiziert Authentifizierungs-Probleme:
ssh -vvv user@hostname
Der Triple-Verbose-Modus zeigt detaillierte Protokoll-Verhandlung, Schlüssel-Versuche und Server-Antworten. Diese Ausgabe lokalisiert Konfigurationsfehler, Netzwerk-Probleme oder Server-seitige Beschränkungen. Key-Exchange-Algorithmen, Cipher-Suites und Authentifizierungs-Methoden werden dabei vollständig protokolliert.
Weiterführende Schritte:
