SSH-Key erstellen (2026): Anleitung mit 11 echten Fehlertests

SSH-Key erstellen dauert eine Minute: ssh-keygen -t ed25519 eintippen, zweimal eine Passphrase vergeben, fertig. Danach liegen zwei Dateien in ~/.ssh/, und der öffentliche Teil muss auf den Server. So weit steht es in jeder Anleitung.

Was in den meisten Anleitungen fehlt, ist der Teil danach. Warum klappt die Anmeldung trotz richtigem Schlüssel nicht? Welche Dateirechte lehnt der Server ab, und welche lässt er durchgehen? Was passiert, wenn der Schlüssel beim Kopieren umbricht? Genau dort geht in der Praxis die Zeit verloren, weil der Client in fast allen Fällen dieselbe nichtssagende Meldung zeigt: Permission denied (publickey).

Für diesen Artikel haben wir darum nicht nur nacherzählt. Wir haben auf unserem Produktionsserver (Ubuntu 24.04, OpenSSH 9.6p1) einen getrennten Test-SSH-Dienst auf einem lokalen Port gestartet, einen Wegwerf-Benutzer angelegt und elf typische Fehler absichtlich eingebaut. Zu jedem Fehler steht unten, was der Client sagt und was im Server-Log steht. Außerdem haben wir die Schlüsseltypen gegeneinander gestoppt.

Drei Befunde vorweg:

1. Ein Ed25519-Schlüssel war in unserem Test im Schnitt in 9 Millisekunden erzeugt. RSA mit 4096 Bit brauchte 1.322 Millisekunden, also rund 150-mal so lange. Der öffentliche Ed25519-Schlüssel ist 86 Byte lang, der RSA-4096-Schlüssel 730 Byte.

2. Bei 10 von 11 eingebauten Fehlern zeigte der Client nur Permission denied (publickey). Den eigentlichen Grund stand ausschließlich im Server-Log. Wer nur auf den Client schaut, rät.

3. Zwei Fehler, vor denen viele Anleitungen warnen, haben bei uns nicht zum Abbruch geführt: Windows-Zeilenenden (CRLF) in authorized_keys und ein gruppenbeschreibbares .ssh-Verzeichnis. Warum das zweite trotzdem keine gute Idee ist, steht weiter unten.

Wenn du erst verstehen willst, was SSH überhaupt ist und warum Schlüssel sicherer sind als Passwörter, fang mit unserem Grundlagenartikel Was ist SSH? an. Hier geht es um das Handwerk.

SSH-Key erstellen in 60 Sekunden: die Kurzfassung

Für alle, die nur die Befehle brauchen. Das funktioniert unter Linux, macOS und Windows 10/11 (PowerShell) gleich:

# 1. Schlüsselpaar erzeugen
ssh-keygen -t ed25519 -C "laptop-arbeit-2026"

# 2. Öffentlichen Schlüssel auf den Server kopieren (Linux/macOS)
ssh-copy-id -i ~/.ssh/id_ed25519.pub benutzer@server-ip

# 3. Testen
ssh benutzer@server-ip

Bei Schritt 1 fragt ssh-keygen nach dem Speicherort (Enter übernimmt ~/.ssh/id_ed25519) und zweimal nach einer Passphrase. Vergib eine. Warum, steht im Abschnitt zur Passphrase.

Wenn Schritt 3 ohne Passwortabfrage des Servers klappt, bist du fertig. Wenn nicht, spring direkt zum Abschnitt Die 11 Fehlertests.

Was beim SSH-Key erstellen eigentlich passiert

ssh-keygen erzeugt ein Schlüsselpaar, also zwei Dateien, die mathematisch zusammengehören:

Der Server bekommt nur den öffentlichen Teil. Er trägt ihn in die Datei ~/.ssh/authorized_keys des jeweiligen Benutzers ein. Beim Anmelden schickt der Server eine Aufgabe, die nur lösen kann, wer den passenden privaten Schlüssel besitzt. Der private Schlüssel selbst wird dabei nie übertragen. Das ist der Kern: Selbst wenn jemand die Verbindung mitschneidet oder den Server übernimmt, bekommt er deinen privaten Schlüssel nicht.

So sieht ein öffentlicher Ed25519-Schlüssel aus, genau eine Zeile mit drei Teilen:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...  laptop-arbeit-2026
│           │                              └─ Kommentar (frei wählbar)
│           └─ der eigentliche Schlüssel (Base64)
└─ Typ

Der private Schlüssel beginnt mit -----BEGIN OPENSSH PRIVATE KEY-----. Ein Detail, das wir beim Testen gesehen haben: Bei einem Schlüssel mit Passphrase steht schon in der zweiten Zeile, Base64-kodiert, aes256-ctr und bcrypt. Das ist das Verfahren, mit dem OpenSSH die Datei verschlüsselt. Ohne Passphrase steht dort none.

Welcher Schlüsseltyp? Ed25519 gegen RSA, gemessen

Die Empfehlung ist eindeutig: Ed25519. Damit die Empfehlung nicht nur behauptet ist, haben wir auf unserem Server je fünf Schlüssel pro Typ erzeugt und die Zeit gestoppt:

Gemessen am 01.10.2026, OpenSSH 9.6p1, ohne Passphrase, Wanduhrzeit inklusive Programmstart.

Die Erzeugungszeit ist für dich als Mensch egal, eine Sekunde wartet jeder. Interessanter sind zwei andere Punkte:

Länge. Ein Ed25519-Schlüssel passt in eine kurze Zeile. Das klingt nach Kosmetik, ist aber praktisch: Beim Kopieren über ein Terminal, eine Weboberfläche oder eine Notiz bricht er seltener um. Und ein Umbruch ist, wie unser Test 9 zeigt, ein harter Fehler.

Robustheit. Ed25519 ist so gebaut, dass typische Implementierungsfehler weniger Schaden anrichten. ECDSA reagiert empfindlich auf schlechte Zufallszahlen beim Signieren. RSA ist nicht unsicher, braucht aber mindestens 3072 Bit, und viele alte Anleitungen empfehlen noch 2048.

Wann doch RSA? Nur wenn ein Zielsystem Ed25519 nicht kann. Das betrifft heute fast nur sehr alte Netzwerkgeräte oder Appliances mit OpenSSH älter als 6.5 (von 2014). Dann ssh-keygen -t rsa -b 4096.

DSA ist tot. OpenSSH hat die Unterstützung mit Version 9.8 im Jahr 2024 abgeschaltet.

Was unser eigener Server akzeptiert, lässt sich direkt abfragen. Die Liste ist lang, Ed25519 steht vorne:

sshd -T | grep pubkeyacceptedalgorithms

Und tatsächlich: Alle 7 erfolgreichen Schlüssel-Anmeldungen, die in unserem aktuellen Journal stehen, liefen über Ed25519. Kein einziger RSA-Login.

Schritt 1: Den SSH-Key erstellen mit ssh-keygen

Der vollständige Befehl, den wir empfehlen:

ssh-keygen -t ed25519 -a 100 -C "laptop-arbeit-2026" -f ~/.ssh/id_ed25519

Was die Optionen bedeuten:

• -t ed25519 wählt den Typ.
• -a 100 legt fest, wie oft die Passphrase durch die Schlüsselableitung (bcrypt) läuft. Mehr Runden machen das Raten einer gestohlenen Datei teurer. Standard ist 16.
• -C "..." setzt den Kommentar. Ohne Angabe nimmt ssh-keygen benutzer@rechnername.
• -f legt den Dateinamen fest. Ohne Angabe fragt das Programm.

Die Ausgabe sieht ungefähr so aus:

Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/du/.ssh/id_ed25519
Your public key has been saved in /home/du/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:CHAHGMoAvYw9cfsCl/+c7F1ubJ5FIG7YMa1WPcZ2MvE laptop-arbeit-2026
The key's randomart image is:
+--[ED25519 256]--+
|+.ooo..       .  |
|o.+o..     . o o |
...

Der Fingerabdruck (SHA256:...) ist die kurze, eindeutige Kennung des Schlüssels. Mit ihm erkennst du den Schlüssel später im Server-Log wieder. Das „Randomart“-Bild darunter ist eine grafische Version davon. Es soll helfen, zwei Schlüssel mit dem Auge zu unterscheiden. Praktisch benutzt es kaum jemand.

Was kostet -a 100 beim Entsperren?

Mehr Runden schützen besser, aber du zahlst bei jedem Entsperren. Wir haben gemessen, wie lange das Entsperren eines Ed25519-Schlüssels bei verschiedenen Rundenzahlen dauert:

Die Kurve ist linear: Doppelt so viele Runden, doppelt so lange. Für einen Angreifer, der eine gestohlene Datei durchprobieren will, gilt dasselbe Verhältnis pro Versuch. Mit -a 100 kostet ihn jeder Rateversuch rund sechsmal so viel wie mit dem Standard. Du merkst davon eine gute halbe Sekunde, und mit dem ssh-agent (siehe unten) nur einmal pro Sitzung.

Mehrere Schlüssel? Gib ihnen Namen

Wenn du verschiedene Schlüssel für verschiedene Zwecke willst (Arbeit, privat, GitHub), nutze -f:

ssh-keygen -t ed25519 -C "github-privat" -f ~/.ssh/id_ed25519_github

Wie SSH dann automatisch den richtigen Schlüssel nimmt, steht im Abschnitt zur ~/.ssh/config.

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

Linux und macOS: ssh-copy-id

Der bequemste und sicherste Weg:

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

ssh-copy-id meldet sich einmal mit Passwort an, legt ~/.ssh an, falls es fehlt, hängt den Schlüssel an authorized_keys an und setzt die Rechte richtig. Gerade der letzte Punkt ist wichtig, wie die Fehlertests unten zeigen.

Windows: ohne ssh-copy-id

Windows 10 und 11 bringen den OpenSSH-Client mit, also ssh und ssh-keygen. ssh-copy-id fehlt aber. In der PowerShell geht es so:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh benutzer@server-ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Die Schlüssel liegen unter Windows in C:\Users\DEINNAME\.ssh\.

Von Hand, wenn es nicht anders geht

Bei manchen Hostern gibt es nur eine Weboberfläche oder eine Konsole im Browser. Dann:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys     # Schlüssel als EINE Zeile einfügen
chmod 600 ~/.ssh/authorized_keys

Wichtig: Der Schlüssel muss in genau einer Zeile stehen. Viele Webkonsolen und Editoren brechen lange Zeilen beim Einfügen um. Genau das haben wir in Test 9 nachgestellt.

Bei Cloud-Servern: am besten gleich bei der Bestellung

Hetzner, DigitalOcean, AWS und die meisten anderen Anbieter lassen dich beim Anlegen des Servers einen öffentlichen Schlüssel hinterlegen. Dann landet er in /root/.ssh/authorized_keys, und die Passwortanmeldung ist oft von Anfang an aus. Das ist der sauberste Start. Wie es danach weitergeht, steht in unserer Anleitung Linux-Server einrichten.

Schritt 3: Testen, bevor du irgendetwas abschaltest

ssh -i ~/.ssh/id_ed25519 benutzer@server-ip

Wenn das klappt, ohne nach dem Passwort des Servers zu fragen, funktioniert der Schlüssel. Die Frage nach der Passphrase deines Schlüssels ist normal, das ist dein lokales Schloss.

Wenn du wissen willst, was genau passiert, hängst du -v an. Die zwei Zeilen, auf die es ankommt:

debug1: Offering public key: /home/du/.ssh/id_ed25519 ED25519 SHA256:...
debug1: Server accepts key: /home/du/.ssh/id_ed25519 ED25519 SHA256:...

Steht da Offering, aber nie Server accepts key, hat der Server den Schlüssel abgelehnt. Warum, sagt er dem Client absichtlich nicht. Das steht nur im Server-Log, und deshalb der nächste Abschnitt.

Jürgen Barth zeigt Erzeugung und Installation von Ed25519-Schlüsseln unter Windows, Linux und macOS auf Deutsch. Das Video ist von 2020, die Befehle sind bis heute dieselben.

Die 11 Fehlertests: was der Server wirklich ablehnt

Der Aufbau

Wir wollten nicht an der echten SSH-Konfiguration unseres Servers herumspielen. Darum lief der Test so:

• ein zweiter sshd nur auf 127.0.0.1, Port 2299, mit eigener Konfiguration und eigenem Host-Key
• PasswordAuthentication no, StrictModes yes (Standard), LogLevel VERBOSE
• ein Wegwerf-Benutzer skmtest, nach dem Test samt Home-Verzeichnis gelöscht
• pro Test genau eine Sache kaputt gemacht, danach wieder repariert

So sieht man jeden Fehler einzeln, ohne dass sich zwei überlagern. Die Ergebnisse:

Die Spalte „Client sagt“ ist der Grund, warum SSH-Fehlersuche so zäh ist. Bis auf Test 3 sieht der Client immer dasselbe.

Test 0: Der Fehler, den wir nicht geplant hatten

Der erste Lauf scheiterte, bevor wir überhaupt etwas kaputt gemacht hatten. Der Benutzer war gerade frisch mit useradd angelegt, der Schlüssel lag richtig, die Rechte stimmten, und trotzdem: Permission denied. Im Log stand:

User skmtest not allowed because account is locked

useradd legt neue Konten mit einem gesperrten Passwort an (! in /etc/shadow). Ohne PAM wertet OpenSSH das als gesperrtes Konto und lässt auch Schlüssel nicht durch. Die Lösung ist, das Passwort auf „keines möglich“ statt „gesperrt“ zu setzen:

usermod -p '*' benutzername

Ehrliche Einschränkung: Unser Test-sshd lief ohne PAM. Auf einem normalen Ubuntu- oder Debian-Server steht in der sshd_config UsePAM yes, und dort tritt dieser Fall in der Regel nicht auf. Auf Systemen ohne PAM (manche Container, Alpine, BSD) kostet er einen aber gern eine halbe Stunde. Wir hätten ihn ohne Blick ins Log auch nicht gefunden.

Test 3: Der einzige Fehler, den der Client meldet

Liegt dein privater Schlüssel mit zu offenen Rechten auf der Platte, verweigert der Client die Benutzung und sagt das laut:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Lösung: chmod 600 ~/.ssh/id_ed25519. Das passiert typischerweise, wenn man Schlüssel über einen USB-Stick, ein geteiltes Laufwerk oder ein ZIP-Archiv von Rechner zu Rechner kopiert.

Test 4 und 6: Wann gruppenbeschreibbar trotzdem durchgeht

Viele Anleitungen sagen: authorized_keys muss 600 sein, .ssh muss 700 sein, sonst geht nichts. Unser Test hat das nur halb bestätigt. Mit 644 für authorized_keys und 755 für .ssh lief die Anmeldung problemlos, weil andere dann nur lesen, nicht schreiben können. Lesen ist bei einem öffentlichen Schlüssel kein Problem.

Überraschender war Test 4: Selbst mit 664, also gruppenbeschreibbar, klappte die Anmeldung. Der Grund ist eine Eigenheit von Debian und Ubuntu: OpenSSH duldet dort Gruppen-Schreibrechte, wenn die Gruppe nur den Benutzer selbst enthält. Das ist bei useradd der Normalfall, jeder Benutzer bekommt seine eigene Gruppe.

Um das zu prüfen, haben wir einen zweiten Benutzer in die Gruppe von skmtest aufgenommen und denselben Test wiederholt. Ergebnis:

Authentication refused: bad ownership or modes for file /home/skmtest/.ssh/authorized_keys

Der Server lehnt also genau dann ab, wenn tatsächlich jemand anderes die Datei ändern könnte. Das ist sinnvoll, aber es hat eine Falle: Eine Konfiguration, die heute funktioniert, bricht morgen, wenn jemand einen Kollegen in die Gruppe aufnimmt. Darum bleiben wir bei der Empfehlung 700 und 600. Nicht weil alles andere sofort kaputt ist, sondern weil es dann später nicht überraschend kaputtgeht.

Test 5: Das Home-Verzeichnis zählt mit

Den Fehler aus Test 5 übersehen viele: OpenSSH prüft nicht nur .ssh und authorized_keys, sondern den ganzen Pfad bis dorthin. Ist das Home-Verzeichnis für alle beschreibbar (777), könnte jemand anderes .ssh umbenennen und durch ein eigenes ersetzen. Darum verweigert der Server die Schlüsselanmeldung komplett:

Authentication refused: bad ownership or modes for directory /home/skmtest

Das passiert in der Praxis nach einem zu großzügigen chmod -R 777, mit dem jemand ein ganz anderes Rechteproblem „lösen“ wollte. Lösung: chmod 750 ~ oder chmod 755 ~.

Test 7: Die Datei gehört dem falschen Benutzer

Wer als root nano /home/benutzer/.ssh/authorized_keys aufruft und die Datei neu anlegt, erzeugt sie mit root als Besitzer. Mit Rechten 600 kann der eigentliche Benutzer sie dann nicht einmal lesen. Ergebnis: Failed publickey. Lösung:

chown -R benutzer:benutzer /home/benutzer/.ssh

Test 8: Windows-Zeilenenden sind harmlos

Wir hatten erwartet, dass CRLF-Zeilenenden (das \r von Windows) den Schlüssel unbrauchbar machen. In OpenSSH 9.6 ist das nicht so, die Anmeldung lief. Das ist gut zu wissen, wenn du die Datei unter Windows bearbeitet hast. Bei älteren Versionen oder anderen SSH-Servern (etwa Dropbear auf Routern) würden wir uns nicht darauf verlassen.

Test 9: Ein Umbruch macht den Schlüssel kaputt

Einen Schlüssel, der beim Einfügen auf zwei Zeilen verteilt wurde, liest der Server als zwei kaputte Einträge. Ergebnis: Failed publickey, ohne jeden weiteren Hinweis. Prüfen kannst du das schnell:

ssh-keygen -lf ~/.ssh/authorized_keys

Dieser Befehl gibt für jede gültige Zeile einen Fingerabdruck aus. Fehlt einer, oder meldet er einen Fehler, ist die Datei kaputt.

Test 10: Passphrase ohne Agent in Skripten

Ein Schlüssel mit Passphrase funktioniert nicht in Skripten, Cronjobs oder CI, wenn niemand die Passphrase eingeben kann (BatchMode=yes). Der Client überspringt ihn still. Für Automatisierung gibt es zwei saubere Wege: einen eigenen Schlüssel ohne Passphrase, der auf dem Server mit Optionen stark eingeschränkt wird (siehe Test 11), oder einen laufenden ssh-agent.

Test 11: Schlüssel einschränken

authorized_keys kann vor jeden Schlüssel Bedingungen schreiben. Zwei davon haben wir getestet:

from="10.0.0.0/8" ssh-ed25519 AAAA... backup-server
from="127.0.0.1",command="echo forced" ssh-ed25519 AAAA... test

Mit from= aus dem falschen Netz lehnte der Server ab: Refused by key options. Mit command= wurde statt unseres Befehls rm -rf / (in einem Wegwerf-Konto, wohlgemerkt) nur echo forced ausgeführt. Der Server ignoriert, was der Client ausführen will, und führt seinen festen Befehl aus.

Das ist das richtige Werkzeug für Schlüssel ohne Passphrase, etwa für Backups: Der Schlüssel funktioniert nur von einer IP und kann nur einen Befehl ausführen. Wird er gestohlen, ist der Schaden begrenzt. Weitere Optionen sind no-port-forwarding, no-pty oder einfach restrict, das alles abschaltet.

Die Fehlersuche in einem Befehl

Weil der Client so wenig verrät, ist dies der wichtigste Befehl für die Fehlersuche. Auf dem Server, während du dich in einem zweiten Fenster anmeldest:

journalctl -u ssh -f

Auf älteren Systemen heißt der Dienst sshd, oder die Meldungen stehen in /var/log/auth.log. Die Zeilen mit Authentication refused, bad ownership, not allowed oder Refused by key options sagen dir genau, was los ist.

Passphrase und ssh-agent: Sicherheit ohne Tipparbeit

Ein privater Schlüssel ohne Passphrase ist eine Datei, die sofort funktioniert, sobald jemand sie kopiert: aus einem Backup, von einem gestohlenen Laptop, aus einem versehentlich hochgeladenen Repository. Mit Passphrase ist sie verschlüsselt, und der Angreifer muss sie erst knacken. Mit -a 100 kostet ihn das pro Versuch rund zwei Drittel einer Sekunde Rechenzeit auf normaler Hardware.

Damit du die Passphrase nicht bei jeder Verbindung tippen musst, gibt es den ssh-agent. Er hält den entsperrten Schlüssel im Arbeitsspeicher, bis du dich abmeldest:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh-add -l     # zeigt, welche Schlüssel der Agent gerade hält

Auf den meisten Linux-Desktops (GNOME, KDE) und unter macOS läuft ein Agent schon automatisch. Unter macOS kann der Schlüsselbund die Passphrase dauerhaft speichern:

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

Unter Windows ist der Agent ein Dienst, der standardmäßig aus ist. Einmalig in einer Administrator-PowerShell:

Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519

Passphrase und Kommentar nachträglich ändern

Beides geht, ohne einen neuen Schlüssel zu erzeugen:

ssh-keygen -p -f ~/.ssh/id_ed25519                # Passphrase ändern oder hinzufügen
ssh-keygen -c -C "neuer-kommentar" -f ~/.ssh/id_ed25519   # Kommentar ändern

Wir haben nachgeprüft, dass sich dabei der Fingerabdruck nicht ändert. Vor und nach beiden Änderungen stand derselbe Wert SHA256:CHAHGMo.... Der Server merkt also nichts, du musst nichts neu verteilen.

Daraus folgt aber auch etwas, das wir im Artikel Was ist SSH? ausführlich gezeigt haben: Der Kommentar ist frei wählbar und beweist nichts. Wie ein Schlüssel heißt, sagt nur, was sich jemand beim Erzeugen gedacht hat. Wem er wirklich gehört, steht im Log, über den Fingerabdruck.

Passphrase vergessen? Dann ist der Schlüssel verloren. Es gibt keinen Weg zurück, das ist ja gerade der Sinn. Neuen Schlüssel erzeugen, den alten Eintrag aus authorized_keys auf allen Servern löschen.

Die ~/.ssh/config: nie wieder -i tippen

Sobald du mehr als einen Schlüssel oder mehr als einen Server hast, lohnt sich eine ~/.ssh/config:

Host meinserver
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github
    IdentitiesOnly yes

Danach reicht ssh meinserver. IdentitiesOnly yes ist dabei wichtiger, als es aussieht: Ohne diese Zeile probiert der Client alle Schlüssel aus dem Agent nacheinander durch. Hast du fünf oder sechs davon, bricht der Server nach MaxAuthTries ab, bei uns nach 6, und du bekommst Too many authentication failures, obwohl der richtige Schlüssel dabei gewesen wäre.

SSH-Key für GitHub und GitLab

Der Ablauf ist derselbe, nur kommt der öffentliche Schlüssel nicht in eine Datei, sondern in die Weboberfläche:

1. Öffentlichen Schlüssel anzeigen: cat ~/.ssh/id_ed25519.pub
2. Die komplette Zeile kopieren
3. GitHub: Settings → SSH and GPG keys → New SSH key. GitLab: Preferences → SSH Keys
4. Testen:

ssh -T git@github.com
# Hi benutzername! You've successfully authenticated, but GitHub does not provide shell access.

Für GitHub empfehlen wir einen eigenen Schlüssel (siehe oben, -f ~/.ssh/id_ed25519_github). Kommt er abhanden, musst du nur an einer Stelle aufräumen.

Tom Lawrence (Lawrence Systems) zeigt auf Englisch den kompletten Weg bis zur abgeschalteten Passwortanmeldung.

Hardware-Schlüssel: ed25519-sk

Wer einen FIDO2-Sicherheitsschlüssel wie einen YubiKey hat, kann den privaten Schlüssel daran binden:

ssh-keygen -t ed25519-sk -C "yubikey"

Dann liegt auf der Platte nur noch ein Verweis, der ohne den physischen Stick nutzlos ist. Bei jeder Anmeldung musst du den Stick berühren. Das braucht OpenSSH 8.2 oder neuer auf beiden Seiten. Für Admin-Zugänge zu wichtigen Servern ist das der stärkste Schutz, den SSH ohne zusätzliche Infrastruktur bietet. Wir haben das für diesen Artikel nicht selbst gemessen, weil auf dem Server kein Stick steckt.

Danach: Passwortanmeldung abschalten

Ein Schlüssel bringt nur dann Sicherheit, wenn das Passwort nicht mehr als Hintertür funktioniert. Erst nachdem du in einer zweiten Sitzung bestätigt hast, dass der Schlüssel funktioniert, in /etc/ssh/sshd_config oder einer Datei unter /etc/ssh/sshd_config.d/:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Dann prüfen und neu laden:

sshd -t && systemctl reload ssh
sshd -T | grep -iE "passwordauth|kbdinteractive"

Der letzte Befehl fragt den laufenden Dienst, nicht die Datei. So sieht es bei uns aus:

passwordauthentication no
kbdinteractiveauthentication no

Was das in der Praxis bedeutet: In unserem aktuellen Journal (es reicht derzeit nur bis zum 29.09.2026 zurück, also gut 42 Stunden) stehen 19.497 Anmeldeversuche mit nicht existierenden Benutzernamen und null Einträge Failed password. Die Bots probieren weiter Passwörter, aber der Server bietet gar keine Passwortabfrage mehr an. Es gibt nichts zu erraten. Wie wir den verbleibenden Lärm zusätzlich eindämmen, steht in fail2ban einrichten und UFW-Firewall einrichten.

Was wir nicht gemessen haben

Damit niemand mehr in die Zahlen liest, als drinsteht:

• Die Erzeugungszeiten stammen von einem Server und je fünf Durchläufen. Auf einem Laptop oder Raspberry Pi sind die absoluten Werte anders. Das Verhältnis zwischen Ed25519 und RSA bleibt ähnlich.
• Die Fehlertests liefen gegen OpenSSH 9.6p1 von Ubuntu, ohne PAM. Test 0 und Test 4 hängen von der Distribution und von PAM ab. Andere Versionen können sich anders verhalten.
• Die 19.497 Versuche stammen aus einem Fenster von rund 42 Stunden, weil unser Journal nicht weiter zurückreicht. Für eine längere Auswertung siehe unseren fail2ban-Artikel mit 31 Tagen Daten.
• Hardware-Schlüssel (ed25519-sk) und SSH-Zertifikate haben wir nicht selbst getestet.

Häufige Fragen

Wie erstelle ich einen SSH-Key?

Mit ssh-keygen -t ed25519 -C "beschreibung" im Terminal. Das funktioniert unter Linux, macOS und in der PowerShell von Windows 10/11. Den Speicherort mit Enter bestätigen, eine Passphrase vergeben. Danach liegen der private Schlüssel id_ed25519 und der öffentliche id_ed25519.pub in ~/.ssh/.

Wo werden SSH-Keys gespeichert?

Unter Linux und macOS in ~/.ssh/ (also /home/benutzer/.ssh/ bzw. /Users/benutzer/.ssh/), unter Windows in C:\Users\BENUTZER\.ssh\. Auf dem Server stehen die erlaubten öffentlichen Schlüssel in ~/.ssh/authorized_keys des jeweiligen Benutzers.

Wie zeige ich meinen öffentlichen SSH-Key an?

cat ~/.ssh/id_ed25519.pub (Windows: type $env:USERPROFILE\.ssh\id_ed25519.pub). Den Fingerabdruck zeigt ssh-keygen -lf ~/.ssh/id_ed25519.pub. Kopiere immer die .pub-Datei, niemals die ohne Endung.

Ed25519 oder RSA, was soll ich nehmen?

Ed25519. In unserem Test war er rund 150-mal schneller erzeugt als RSA 4096 und der öffentliche Schlüssel ist 86 statt 730 Byte lang. RSA (mit mindestens 3072 Bit) nur, wenn ein sehr altes Zielsystem Ed25519 nicht unterstützt.

Wie kopiere ich den SSH-Key auf den Server?

Unter Linux und macOS mit ssh-copy-id -i ~/.ssh/id_ed25519.pub benutzer@server. Unter Windows mit dem PowerShell-Einzeiler aus diesem Artikel. Bei Cloud-Servern am besten direkt bei der Bestellung im Kundenmenü hinterlegen.

Warum kommt trotz Schlüssel „Permission denied (publickey)“?

Weil der Server den Schlüssel abgelehnt hat und dem Client den Grund nicht verrät. Häufigste Ursachen in unseren Tests: falsche Besitzer oder zu offene Rechte am Home-Verzeichnis, ein umgebrochener Schlüssel in authorized_keys, ein gesperrtes Konto oder ein falscher Schlüssel. Den Grund zeigt journalctl -u ssh -f auf dem Server.

Brauche ich eine Passphrase?

Ja, für alle Schlüssel, mit denen sich ein Mensch anmeldet. Ohne Passphrase reicht eine kopierte Datei für den Zugang. Für Automatisierung ohne Passphrase den Schlüssel auf dem Server mit from=, command= oder restrict einschränken.

Kann ich die Passphrase später ändern?

Ja, mit ssh-keygen -p -f ~/.ssh/id_ed25519. Der Fingerabdruck bleibt gleich, auf den Servern muss nichts geändert werden. Eine vergessene Passphrase lässt sich nicht wiederherstellen.

Kann ich einen SSH-Key für mehrere Server benutzen?

Technisch ja, der öffentliche Schlüssel kann auf beliebig vielen Servern liegen. Sinnvoll ist eher ein Schlüssel pro Gerät (Laptop, Desktop, Handy) statt pro Server. Geht ein Gerät verloren, entfernst du genau diesen einen Schlüssel überall.

Wie lösche oder sperre ich einen SSH-Key?

Auf dem Server die entsprechende Zeile aus ~/.ssh/authorized_keys entfernen. Vorher mit ssh-keygen -lf ~/.ssh/authorized_keys die Fingerabdrücke anzeigen und im Log prüfen, ob der Schlüssel noch benutzt wird. Ein selten genutzter Schlüssel kann an einem Backup oder Cronjob hängen.

Funktioniert derselbe SSH-Key für GitHub?

Ja. Den Inhalt der .pub-Datei unter Settings → SSH and GPG keys eintragen und mit ssh -T git@github.com testen. Wir empfehlen trotzdem einen eigenen Schlüssel für GitHub.

Fazit

SSH-Key erstellen ist ein Befehl: ssh-keygen -t ed25519. Die Wahl des Typs ist keine Glaubensfrage mehr. Ed25519 ist kürzer, schneller und robuster, und auf unserem Server lief jede einzelne Schlüsselanmeldung darüber.

Die Zeit geht woanders verloren, nämlich wenn es nicht klappt. In zehn von elf Fehlerfällen hat der Client uns nichts verraten außer Permission denied (publickey). Die Antwort stand jedes Mal im Server-Log, mal als bad ownership, mal als account is locked, mal als Refused by key options. Wer sich nur eine Sache aus diesem Artikel merkt, sollte diese nehmen: Bei Schlüsselproblemen nicht am Client raten, sondern journalctl -u ssh -f auf dem Server öffnen.

Und danach, erst nach dem erfolgreichen Test in einer zweiten Sitzung, die Passwortanmeldung abschalten. Dann gibt es für die 19.497 Bots in unserem Journal nichts mehr zu erraten.