SSH-Schlüssel erstellen: ed25519 Schritt für Schritt

Jedes Mal das Server-Passwort eintippen nervt, und ein Passwort lässt sich im Gegensatz zu einem SSH-Schlüssel erraten oder abgreifen. Mit einem Schlüsselpaar meldest Du Dich an Deinem Server, Deinem Raspberry Pi und bei GitHub an, ohne dass ein Passwort über die Leitung geht. In dieser Anleitung erzeugen wir einen ed25519-Schlüssel mit Passphrase, bringen ihn auf den Server, lassen den Mac sich die Passphrase merken, ordnen mehrere Schlüssel sauber über ~/.ssh/config und lösen am Ende den Klassiker „Permission denied (publickey)“ Schritt für Schritt.

Alle Befehle habe ich mit OpenSSH 10.5 unter macOS 27 ausprobiert. Die Fehlermeldungen und die ssh -v-Ausgaben weiter unten stammen aus einem lokalen Test-SSH-Server, an dem ich die typischen Fehler gezielt nachgestellt habe. Unter Linux und im Terminal von Windows 11 sind die Befehle dieselben, Abweichungen nenne ich an der jeweiligen Stelle.

Wie ein SSH-Schlüssel funktioniert und warum ed25519

Ein SSH-Schlüssel besteht aus zwei Dateien. Der private Schlüssel (id_ed25519) bleibt auf Deinem Rechner und verlässt ihn nie. Der öffentliche Schlüssel (id_ed25519.pub) kommt auf jeden Server, an dem Du Dich anmelden willst. Bei der Anmeldung beweist Dein Rechner mit dem privaten Schlüssel, dass er zum öffentlichen passt, ohne ihn dabei preiszugeben. Den öffentlichen Schlüssel darfst Du deshalb bedenkenlos weitergeben, den privaten niemals.

Als Verfahren nimmst Du ed25519. Die Schlüssel sind kurz, schnell und nach heutigem Stand sicher, GitHub empfiehlt das Verfahren ausdrücklich, und seit OpenSSH 9.5 ist es auch der Standard von ssh-keygen. Einen RSA-Schlüssel brauchst Du nur noch für sehr alte Systeme, die ed25519 nicht kennen.

Schritt 1: Den Schlüssel erzeugen

Öffne auf Deinem Mac das Terminal (unter Linux ein beliebiges Terminal, unter Windows 11 PowerShell) und gib ein:

ssh-keygen -t ed25519 -C "deinname@macbook"

Der Teil hinter -C ist nur ein Kommentar, der am Ende des öffentlichen Schlüssels steht. Nimm etwas, woran Du später erkennst, von welchem Gerät der Schlüssel stammt, zum Beispiel Deinen Namen und den Rechner. Danach stellt ssh-keygen zwei Fragen:

1. Speicherort: Bestätige den Vorschlag ~/.ssh/id_ed25519 mit Enter. Gibt es dort schon einen Schlüssel, fragt das Programm, ob es ihn überschreiben soll. Antworte dann mit n und überleg zuerst, ob Du den alten noch brauchst, denn überschrieben ist er weg.
2. Passphrase: Vergib eine Passphrase und wiederhole sie. Sie verschlüsselt den privaten Schlüssel auf der Festplatte. Kommt Dein Laptop abhanden, ist die Schlüsseldatei ohne Passphrase wertlos. Damit Du sie nicht ständig tippen musst, kümmert sich in Schritt 3 der Schlüsselbund darum.

Zum Schluss zeigt ssh-keygen den Fingerabdruck an, der mit SHA256: beginnt. Mit ls -l ~/.ssh siehst Du die beiden neuen Dateien: id_ed25519 mit den Rechten -rw------- (nur Du darfst lesen) und id_ed25519.pub. Den öffentlichen Schlüssel kannst Du Dir mit cat ~/.ssh/id_ed25519.pub anzeigen lassen. Er ist eine einzige Zeile, die mit ssh-ed25519 AAAA beginnt und mit Deinem Kommentar endet.

Schritt 2: Den öffentlichen Schlüssel auf den Server bringen

Am bequemsten geht das mit ssh-copy-id, das auf macOS und Linux bereits installiert ist:

ssh-copy-id -i ~/.ssh/id_ed25519.pub benutzer@SERVER

Ersetze benutzer durch Deinen Benutzernamen auf dem Server und SERVER durch seine IP-Adresse oder seinen Hostnamen, bei einem Raspberry Pi im Heimnetz zum Beispiel 192.168.178.50. Der Befehl fragt ein letztes Mal nach dem Passwort des Servers, legt dort bei Bedarf den Ordner ~/.ssh mit den richtigen Rechten an und hängt Deinen Schlüssel an die Datei ~/.ssh/authorized_keys an. Bereits vorhandene Schlüssel bleiben erhalten.

Unter Windows gibt es ssh-copy-id nicht. Dort kopierst Du den Inhalt von id_ed25519.pub per Hand in eine neue Zeile der Datei ~/.ssh/authorized_keys auf dem Server und setzt danach die Rechte so, wie es unten im Abschnitt zu den Fehlern steht.

Jetzt kommt der Test:

ssh benutzer@SERVER

Fragt SSH nach der Passphrase Deines Schlüssels (die Eingabeaufforderung lautet Enter passphrase for key), funktioniert die Anmeldung per Schlüssel. Fragt es dagegen nach dem Passwort des Servers, ist der Schlüssel nicht angekommen oder wird nicht akzeptiert. Spring in diesem Fall zum Abschnitt über „Permission denied“.

Willst Du danach die Passwort-Anmeldung auf dem Server ganz abschalten, zeigt Dir Linux-Server absichern: SSH-Schlüssel, ufw, fail2ban, wie Du das gefahrlos machst, ohne Dich auszusperren.

Schritt 3: Die Passphrase im Schlüsselbund des Mac speichern

Damit Du die Passphrase nicht bei jeder Verbindung eintippen musst, legst Du sie im Schlüsselbund von macOS ab:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Du gibst die Passphrase ein letztes Mal ein, danach liegt sie im Schlüsselbund. Damit SSH sie nach einem Neustart auch von selbst wieder lädt, brauchst Du noch zwei Zeilen in der Konfigurationsdatei. Öffne sie mit:

nano ~/.ssh/config

Gibt es die Datei noch nicht, legt nano sie an. Trag ganz oben diesen Block ein:

Host *
  AddKeysToAgent yes
  UseKeychain yes

Speichere mit Ctrl + O, bestätige mit Enter und schließe den Editor mit Ctrl + X. UseKeychain yes sorgt dafür, dass SSH die Passphrase aus dem Schlüsselbund holt, AddKeysToAgent yes lädt den Schlüssel bei der ersten Verbindung in den laufenden SSH-Agent. Diese beiden Optionen gibt es nur in der SSH-Version von Apple. Unter Linux lässt Du UseKeychain weg, dort übernimmt der Agent Deiner Desktopumgebung die Passphrase.

Schritt 4: Mehrere Schlüssel und Server in ~/.ssh/config ordnen

Sobald Du mehrere Server hast, lohnt sich ein Eintrag pro Ziel in derselben Datei. Unter den Host *-Block schreibst Du zum Beispiel:

Host pi
  HostName 192.168.178.50
  User pi
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

Host webserver
  HostName 203.0.113.10
  User deploy
  Port 2222
  IdentityFile ~/.ssh/id_ed25519_web
  IdentitiesOnly yes

Hinter Host steht ein frei wählbarer Kurzname. Statt ssh [email protected] tippst Du dann nur noch ssh pi. HostName ist die echte Adresse, User der Benutzer, Port nur nötig, wenn der Server nicht auf Port 22 lauscht. IdentityFile legt fest, welcher Schlüssel für diesen Server gilt, und IdentitiesOnly yes verhindert, dass SSH nacheinander alle Schlüssel aus dem Agent durchprobiert. Ohne diese Zeile kann es bei vielen Schlüsseln passieren, dass der Server mit Too many authentication failures abbricht, bevor der richtige an der Reihe ist.

Ob SSH Deine Datei so versteht, wie Du sie gemeint hast, prüfst Du mit ssh -G pi. Der Befehl verbindet sich nicht, sondern zeigt die fertig ausgewerteten Einstellungen, darunter hostname, user und identityfile. Wenn Du Deine Server lieber als Lesezeichen mit Namen und Farben verwaltest, findest Du die passende Ergänzung in SSH-Verbindungen am Mac speichern: PuTTY-Ersatz.

Schritt 5: Den Schlüssel bei GitHub hinterlegen

Für GitHub kannst Du denselben Schlüssel verwenden. Kopiere den öffentlichen Schlüssel in die Zwischenablage:

pbcopy < ~/.ssh/id_ed25519.pub

Unter Linux lässt Du Dir den Schlüssel mit cat ~/.ssh/id_ed25519.pub anzeigen und markierst die Zeile. Öffne dann auf github.com Dein Profilbild oben rechts und gehe zu Settings > SSH and GPG keys > New SSH key. Gib einen Titel wie „MacBook 2026“ ein, lass den Typ auf Authentication Key, füge den Schlüssel ins Feld Key ein und klicke auf Add SSH key. Prüfe die Verbindung danach im Terminal:

ssh -T [email protected]

Beim allerersten Mal fragt SSH, ob Du dem Fingerabdruck von GitHub vertraust. Vergleiche ihn mit den Werten, die GitHub in seiner Dokumentation unter GitHub’s SSH key fingerprints veröffentlicht, und antworte dann mit yes. Die Antwort Hi deinname! You've successfully authenticated, but GitHub does not provide shell access. bedeutet Erfolg. Damit Git den Schlüssel auch benutzt, klonst Du Repositorys ab jetzt über die SSH-Adresse in der Form [email protected]:deinname/repo.git statt über https://.

„Permission denied (publickey)“: systematisch zur Ursache

Diese Meldung sagt nur, dass der Server keinen Schlüssel akzeptiert hat. Warum, verrät sie nicht. Den Grund findest Du am schnellsten mit der ausführlichen Ausgabe:

ssh -v benutzer@SERVER

In der Flut von Zeilen interessieren Dich nur die, in denen es um Schlüssel geht. So sah es in meinem Test aus, als der öffentliche Schlüssel auf dem Server fehlte:

debug1: Will attempt key: /Users/du/.ssh/id_ed25519 ED25519 SHA256:e3aI6k... explicit
debug1: Offering public key: /Users/du/.ssh/id_ed25519 ED25519 SHA256:e3aI6k... explicit
debug1: Authentications that can continue: publickey
benutzer@SERVER: Permission denied (publickey).

Und so, wenn alles stimmt:

debug1: Offering public key: /Users/du/.ssh/id_ed25519 ED25519 SHA256:e3aI6k... explicit
debug1: Server accepts key: /Users/du/.ssh/id_ed25519 ED25519 SHA256:e3aI6k... explicit
Authenticated to SERVER ([SERVER]:22) using "publickey".

Aus diesen Zeilen leitest Du ab, wo Du suchen musst.

Taucht gar keine Zeile Offering public key auf, findet SSH Deinen Schlüssel nicht. Meist liegt er unter einem anderen Namen, oder ein IdentityFile in ~/.ssh/config zeigt auf eine falsche Datei. Gib den Schlüssel testweise direkt an: ssh -i ~/.ssh/id_ed25519 benutzer@SERVER.

Wird der richtige Schlüssel angeboten, aber nicht akzeptiert, liegt der Fehler auf dem Server. Prüfe zuerst, ob Du Dich mit dem richtigen Benutzer anmeldest, denn der Schlüssel gilt nur für den Benutzer, in dessen authorized_keys er steht. Vergleiche danach den Fingerabdruck: ssh-keygen -lf ~/.ssh/id_ed25519.pub auf Deinem Rechner muss denselben SHA256:-Wert zeigen wie ssh-keygen -lf ~/.ssh/authorized_keys auf dem Server für die entsprechende Zeile.

Stimmt beides, sind es fast immer die Dateirechte. Der SSH-Server ist an dieser Stelle streng: Darf außer Dir noch jemand in den Ordner ~/.ssh oder in die Datei authorized_keys schreiben, ignoriert er den Schlüssel stillschweigend. Melde Dich per Passwort oder über die Konsole Deines Hosters an und setze die Rechte neu:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod go-w ~

Die letzte Zeile nimmt Gruppe und anderen das Schreibrecht auf Dein Home-Verzeichnis, das prüft der Server nämlich ebenfalls. Den Beweis liefert das Log des Servers. Unter Debian, Ubuntu und Raspberry Pi OS zeigt Dir sudo journalctl -u ssh -n 30 die letzten Einträge. Bei falschen Rechten steht dort eine Zeile wie Authentication refused: bad ownership or modes for file /home/benutzer/.ssh/authorized_keys, genau so, wie sie mein Testserver ausgegeben hat.

Wurde der Server neu installiert und meckert SSH stattdessen über einen geänderten Host-Schlüssel, ist das ein anderes Problem. Wie Du den alten Eintrag sauber entfernst, steht in known_hosts am Mac bearbeiten und SSH-Fehler beheben.

Noch sicherer: der Schlüssel auf einem Hardware-Token

Ein privater Schlüssel als Datei lässt sich kopieren, wenn jemand Zugriff auf Deinen Rechner bekommt. Wer das ausschließen will, legt den Schlüssel auf einen Sicherheitsschlüssel wie einen YubiKey 5C NFC (Affiliate Link). Dann erzeugst Du mit ssh-keygen -t ed25519-sk einen Schlüssel, der ohne den eingesteckten Stick und ein Antippen nicht funktioniert. Am Mac brauchst Du dafür allerdings das OpenSSH aus Homebrew, weil Apples mitgeliefertes SSH mit Sicherheitsschlüsseln nicht umgehen kann. Wie das zusammen mit dem Apple Account und Bitwarden aussieht und was dabei mit UseKeychain passiert, beschreibt YubiKey am Mac und iPhone: Apple Account, SSH, Bitwarden.

Kurz zusammengefasst

Ein ed25519-Schlüssel mit Passphrase, die der Schlüsselbund verwaltet, ist bequemer als jedes Passwort und deutlich sicherer. Einmal erzeugt, verteilst Du den öffentlichen Teil per ssh-copy-id auf alle Server und trägst ihn bei GitHub ein, die Kurznamen in ~/.ssh/config sparen Dir danach jede Menge Tipparbeit. Und wenn eine Anmeldung scheitert, führt ssh -v zusammen mit dem Server-Log fast immer in wenigen Minuten zur Ursache. Die Details zu allen Optionen findest Du in den Handbuchseiten zu ssh-keygen und ssh_config sowie in GitHubs Anleitung Generating a new SSH key and adding it to the ssh-agent.