SSH-Keys generieren & effizient verteilen

Passwort-Login über SSH ist langsam, unsicher und nervt bei jedem Connect. Ein Schlüsselpaar löst alle drei Probleme auf einmal — wenn man es einmal richtig aufsetzt. Hier die Kurzversion, die für 95 % der Fälle reicht.

Schlüssel generieren: ed25519 statt RSA

ssh-keygen erzeugt standardmäßig noch RSA-Schlüssel — für neue Setups gibt es aber kaum einen Grund, nicht Ed25519 zu nehmen: kürzere Schlüssel, schnellere Signaturen, genauso sicher wie RSA-4096.

ssh-keygen -t ed25519 -C "kai@laptop"

# Legt zwei Dateien an:
# ~/.ssh/id_ed25519       ← privat, bleibt IMMER auf der Maschine
# ~/.ssh/id_ed25519.pub   ← öffentlich, darf überall hin

Der -C-Kommentar landet als Klartext in der .pub-Datei — praktisch, um Jahre später auf einem Server zu sehen, von welcher Maschine welcher Key stammt. Bei der Passphrase gilt: leer ist bequem, aber ein geklauter Laptop bedeutet dann sofortigen Vollzugriff auf jeden Server, der den Key kennt. Eine Passphrase plus ssh-agent (nächster Abschnitt) kostet fast nichts an Komfort.

ssh-agent: Passphrase einmal pro Session

Ohne Agent fragt SSH bei jedem einzelnen Connect nach der Passphrase. Der Agent hält den entsperrten Key im Speicher — Passphrase einmal eingeben, danach läuft jede Verbindung ohne Nachfrage.

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

# macOS: Key dauerhaft im Schlüsselbund merken
ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Die meisten Desktop-Umgebungen (GNOME Keyring, macOS) starten den Agent automatisch beim Login — ssh-add -l zeigt, welche Keys gerade geladen sind.

Effizient rüberschieben: ssh-copy-id

Den Public Key manuell per Copy-Paste in ~/.ssh/authorized_keys einzufügen ist fehleranfällig — ein Zeilenumbruch zu viel und der Key funktioniert nicht. ssh-copy-id macht das in einem Befehl, inklusive korrekter Dateirechte:

ssh-copy-id -i ~/.ssh/id_ed25519.pub nutzer@server.de

# Anderer Port als 22:
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 nutzer@server.de

Kein ssh-copy-id zur Hand (z. B. auf macOS ohne Homebrew)? Der Ein-Zeiler dahinter, der überall funktioniert:

cat ~/.ssh/id_ed25519.pub | ssh nutzer@server.de \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Die Rechte sind kein Detail: SSH verweigert den Key-Login kommentarlos, wenn ~/.ssh oder authorized_keys für die Gruppe oder andere schreibbar sind. Das ist der häufigste Grund, warum „es geht einfach nicht" nach dem Kopieren.

~/.ssh/config: Server-Zoo zähmen

Wer mehr als zwei Server hat, sollte nie wieder ssh -i ~/.ssh/id_ed25519 -p 2222 nutzer@lange-domain.de tippen. Die Config-Datei macht daraus einen Alias:

# ~/.ssh/config

Host prod
  HostName lange-domain.de
  User nutzer
  Port 2222
  IdentityFile ~/.ssh/id_ed25519

Host intern
  HostName 10.0.0.42
  User admin
  ProxyJump prod

Ab jetzt reicht ssh prod. Der zweite Eintrag zeigt noch einen Trick: ProxyJump tunnelt automatisch über prod zu einem Server, der nur intern erreichbar ist — kein manuelles -J mehr nötig, und auch scp/rsync nutzen dieselbe Config.

Ein Key pro Zweck, nicht ein Key für alles

Statt einem einzigen Universal-Key lohnt sich Trennung nach Kontext — privat, Arbeit, CI/CD. Passendes Host-Muster in der Config wählt automatisch den richtigen Key aus, ganz ohne -i im Terminal:

Host *.privat-server.de
  IdentityFile ~/.ssh/id_ed25519_privat

Host *.firma.de
  IdentityFile ~/.ssh/id_ed25519_arbeit
  IdentitiesOnly yes

IdentitiesOnly yes ist hier der wichtige Teil: Ohne die Zeile probiert SSH bei vielen geladenen Keys im Agent einfach alle durch, bis einer passt oder der Server die Verbindung wegen zu vieler Fehlversuche killt. Mit der Zeile wird ausschließlich der angegebene Key verwendet.