Snippet
SSH Key erstellen und einrichten
Die schlüsselbasierte Authentifizierung ist deutlich sicherer als ein Passwort – egal wie komplex es gewählt ist – und spart obendrein bei jeder Verbindung Zeit, weil das Eintippen entfällt.
Das Prinzip: Auf dem eigenen Rechner wird ein Schlüsselpaar erzeugt, bestehend aus einem privaten und einem öffentlichen Schlüssel. Der öffentliche Schlüssel kommt auf den Server, der private bleibt lokal. Bei der Anmeldung beweist der Client, dass er den passenden privaten Schlüssel besitzt – ohne dass dieser jemals übertragen wird.
SSH-Schlüsselpaar erzeugen
ssh-keygen -t ed25519 -C "kommentar@beispiel.de"
ed25519 ist der aktuelle Standard – schneller und sicherer als das ältere RSA-Verfahren. Der -C-Parameter fügt einen Kommentar hinzu (üblicherweise die eigene E-Mail-Adresse), der bei der Zuordnung auf Servern mit mehreren hinterlegten Keys hilft.
Das Tool fragt nach einem Speicherort (Standardpfad ~/.ssh/id_ed25519 ist in den meisten Fällen richtig) und nach einer optionalen Passphrase. Die Passphrase verschlüsselt den privaten Schlüssel auf der lokalen Festplatte – empfehlenswert als zusätzliche Absicherung, falls jemand Zugriff auf den Rechner erlangt.
Falls ein Zielsystem ed25519 nicht unterstützt (ältere SSH-Versionen vor 6.5), kann als Fallback RSA mit 4096 Bit verwendet werden:
ssh-keygen -t rsa -b 4096 -C "kommentar@beispiel.de"
Nach der Erzeugung liegen zwei Dateien im Verzeichnis ~/.ssh/:
- id_ed25519 – der private Schlüssel (diesen niemals weitergeben oder auf Server kopieren)
- id_ed25519.pub – der öffentliche Schlüssel (dieser kommt auf den Server)
Öffentlichen Schlüssel auf den Server kopieren (ssh-copy-id)
Der einfachste Weg:
ssh-copy-id benutzer@server-ip
Das Tool kopiert den öffentlichen Schlüssel automatisch in die Datei ~/.ssh/authorized_keys auf dem Server und setzt die richtigen Dateiberechtigungen. Beim ersten Mal wird noch das Passwort des Server-Benutzers abgefragt – danach funktioniert die Anmeldung per Key.
Falls ssh-copy-id nicht verfügbar ist (z. B. unter Windows ohne WSL), geht es auch manuell:
cat ~/.ssh/id_ed25519.pub | ssh benutzer@server-ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
Verbindung testen
ssh benutzer@server-ip
Wenn alles richtig eingerichtet ist, erfolgt die Anmeldung ohne Passwortabfrage – oder nur mit der Passphrase des lokalen Schlüssels, falls eine gesetzt wurde.
Für eine ausführliche Diagnose bei Problemen:
ssh -v benutzer@server-ip
Die Verbose-Ausgabe zeigt Schritt für Schritt, welche Schlüssel ausprobiert werden und wo die Authentifizierung scheitert.
Passwort-Login deaktivieren
Sobald die Key-Authentifizierung zuverlässig funktioniert, sollte der Passwort-Login auf dem Server deaktiviert werden. Das schließt Brute-Force-Angriffe praktisch aus.
In der SSH-Server-Konfiguration auf dem Server:
sudo nano /etc/ssh/sshd_config
Folgende Einstellungen setzen (oder vorhandene Zeilen ändern):
PasswordAuthentication no
PubkeyAuthentication yes
Danach den SSH-Dienst neu laden:
sudo systemctl reload sshd
Wichtig: Vor dem Deaktivieren des Passwort-Logins unbedingt in einer zweiten, parallel geöffneten SSH-Sitzung testen, ob die Key-Anmeldung funktioniert. Wer sich aussperrt, kommt nur noch über eine Konsole des Hosting-Providers zurück.
SSH-Agent für Passphrasen
Wer eine Passphrase für den privaten Schlüssel gesetzt hat (empfohlen), muss diese bei jeder Verbindung eintippen. Der SSH-Agent speichert die entschlüsselten Schlüssel für die Dauer der Sitzung im Arbeitsspeicher:
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
Auf den meisten Desktop-Systemen (macOS, GNOME, KDE) läuft der SSH-Agent automatisch und übernimmt die Passphrase-Abfrage beim ersten Verbinden.
Unter macOS lässt sich die Passphrase zusätzlich im Schlüsselbund speichern:
ssh-add --apple-use-keychain ~/.ssh/id_ed25519
Mehrere Schlüssel verwalten
Wer verschiedene Schlüssel für verschiedene Server oder Dienste nutzt (etwa einen für Produktivserver, einen für Git), kann in ~/.ssh/config festlegen, welcher Schlüssel wo verwendet wird:
Host produktion
HostName 203.0.113.10
User deploy
IdentityFile ~/.ssh/id_ed25519_produktion
Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_github
Danach genügt ssh produktion statt des vollständigen Befehls mit IP, Benutzername und Schlüsselpfad.
Häufige Stolperfallen
Berechtigungen stimmen nicht? SSH ist streng bei Dateiberechtigungen. Wenn die Anmeldung trotz korrektem Schlüssel fehlschlägt, sind fast immer die Rechte das Problem:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
Das gilt sowohl auf dem Client als auch auf dem Server.
Falscher Schlüssel wird angeboten? Wenn mehrere Schlüssel im ~/.ssh/-Verzeichnis liegen, probiert SSH sie der Reihe nach durch. Nach zu vielen fehlgeschlagenen Versuchen bricht der Server die Verbindung ab. Die Lösung: den richtigen Schlüssel explizit angeben mit ssh -i ~/.ssh/mein_key benutzer@server oder die ~/.ssh/config nutzen.
Key funktioniert, aber Passwort wird trotzdem abgefragt? In der sshd_config auf dem Server prüfen, ob PubkeyAuthentication yes gesetzt ist. Außerdem sicherstellen, dass der öffentliche Schlüssel in authorized_keys in einer einzigen Zeile steht – ein versehentlicher Zeilenumbruch macht den Schlüssel ungültig.
Root-Login per Key? Funktioniert, aber Best Practice ist ein normaler Benutzer mit sudo-Rechten. Falls Root-Login per Key gewünscht ist, muss in der sshd_config die Einstellung PermitRootLogin prohibit-password statt no gesetzt werden.
Kurzreferenz
| Aufgabe | Befehl |
|---|---|
| Schlüsselpaar erzeugen (ed25519) | ssh-keygen -t ed25519 -C "mail@beispiel.de" |
| Schlüsselpaar erzeugen (RSA Fallback) | ssh-keygen -t rsa -b 4096 -C "mail@beispiel.de" |
| Key auf Server kopieren | ssh-copy-id benutzer@server-ip |
| Verbindung testen (verbose) | ssh -v benutzer@server-ip |
| SSH-Agent starten | eval "$(ssh-agent -s)" |
| Key zum Agent hinzufügen | ssh-add ~/.ssh/id_ed25519 |
| SSH-Dienst neu laden | sudo systemctl reload sshd |
| Berechtigungen prüfen/setzen | chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys |
