SSH-Key erstellen und das Passwort-Login abschalten

Ein SSH-Key ersetzt das Passwort beim Anmelden auf einem Server – bequemer, weil du nichts mehr tippst, und deutlich sicherer, weil ein 256 Bit langer Schlüssel nicht zu erraten ist. Erzeugt ist er in einem Befehl.

Der Teil, der danach kommt, ist der eigentlich wichtige: das Passwort-Login abschalten. Und genau dort scheitern viele, ohne es zu merken – weil auf Ubuntu eine Einstellungsdatei dazwischenliegt, die alles übersteuert, was man in der Hauptkonfiguration einträgt. Man setzt „Passwort aus“, bekommt keinen Fehler, und das Passwort-Login bleibt offen.

Dieser Artikel zeigt beides und weist das Ubuntu-Problem nachprüfbar nach. Getestet auf Debian 13 und Ubuntu 26.04 LTS mit OpenSSH 10 (Stand September 2026); alle Ausgaben stammen aus diesem Durchlauf.

Das Wichtigste in Kürze

• ed25519 nehmen, nicht RSA. Kürzer, schneller, mindestens so sicher.
• Der private Schlüssel braucht Rechte 600. Bei allem anderen verweigert SSH den Dienst.
• Auf Ubuntu übersteuert /etc/ssh/sshd_config.d/50-cloud-init.conf die Hauptdatei – dort steht PasswordAuthentication yes.
• Prüfe nie die Datei, sondern immer sudo sshd -T. Nur das zeigt, was wirklich gilt.
• Halte beim Ändern der SSH-Konfiguration eine zweite Sitzung offen.

Schritt 1: Schlüsselpaar erzeugen

Auf deinem eigenen Rechner, nicht auf dem Server:

ssh-keygen -t ed25519 -C "dein.name@arbeitsplatz"

Drei Rückfragen kommen: wohin gespeichert wird (Eingabetaste für die Vorgabe), und zweimal eine Passphrase. Zur Passphrase gleich mehr. Die Ausgabe sieht so aus:

Your identification has been saved in /home/dr/.ssh/id_ed25519
Your public key has been saved in /home/dr/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:oQxkV+9/8BPtE3mBVEc3DReDxATQqgmR5qL6tLJG2wU dein.name@arbeitsplatz
The key's randomart image is:
+--[ED25519 256]--+
|    o o...o.=++BB|
|   o =   . ..o..*|
|    + . . o  . . |
|   E = . +     .o|
|  . o + S . . .oo|
+----[SHA256]-----+

Zwei Dateien sind entstanden, und der Unterschied entscheidet über deine Sicherheit:

$ ls -l ~/.ssh/
-rw------- 1 dr dr 411 id_ed25519        <- PRIVAT, bleibt bei dir
-rw-r--r-- 1 dr dr  97 id_ed25519.pub    <- oeffentlich, darf ueberall hin

Der private Schlüssel verlässt deinen Rechner nie. Nicht per Mail, nicht in eine Cloud, nicht in ein Git-Repository. Der öffentliche mit der Endung .pub ist dagegen völlig unkritisch – er wird auf jedem Server hinterlegt, auf den du willst.

Das -C setzt einen Kommentar, der am Ende des öffentlichen Schlüssels steht. Er hat keine technische Funktion, ist aber ausgesprochen nützlich: Wenn du in einem Jahr in authorized_keys auf dem Server fünf Schlüssel siehst, willst du wissen, welcher von welchem Gerät stammt.

Warum ed25519 und nicht RSA

Beide Verfahren gelten als sicher, aber die Größenunterschiede sind beachtlich. Im Test dieselben Schlüssel im Vergleich:

Der öffentliche ed25519-Schlüssel passt in eine Zeile, die man noch überblicken kann:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICNiseKa4W2VXMAQyhkZCeN+8IGMPizHSo0rtKsVJzm7 dr@arbeitsplatz

RSA brauchst du nur noch für sehr alte Server oder Geräte, die ed25519 nicht kennen. Dann aber mit ssh-keygen -t rsa -b 4096 – alles unter 4096 Bit ist nicht mehr zeitgemäß. Die früher verbreiteten Verfahren dsa und ecdsa solltest du nicht mehr verwenden; OpenSSH hat DSA inzwischen ganz entfernt.

Passphrase: ja oder nein?

Eine Passphrase verschlüsselt den privaten Schlüssel auf deiner Platte. Wer die Datei kopiert, kann ohne sie nichts damit anfangen.

Setze eine – auf einem Notebook unbedingt, das kann abhandenkommen. Der scheinbare Nachteil, sie ständig eintippen zu müssen, wird vom ssh-agent gelöst (Schritt 5). Nur für Schlüssel, die unbeaufsichtigt in Skripten oder Sicherungsläufen arbeiten, ist ein Schlüssel ohne Passphrase vertretbar – und der sollte dann so wenig Rechte wie möglich haben.

Schritt 2: Öffentlichen Schlüssel auf den Server bringen

Der bequeme Weg ist ein einziger Befehl:

ssh-copy-id dein-benutzer@dein-server

Er fragt einmal nach deinem Passwort, legt auf dem Server ~/.ssh/authorized_keys an, hängt deinen Schlüssel an und setzt die Rechte richtig. Danach:

ssh dein-benutzer@dein-server

Kommt keine Passwortfrage mehr, hat es funktioniert.

Wenn ssh-copy-id nicht verfügbar ist

Auf manchen Systemen – etwa bei Netzwerkgeräten oder in eingeschränkten Umgebungen – fehlt es. Dann von Hand:

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

Die Rechte sind kein Zierwerk: Ist ~/.ssh für andere zugänglich oder authorized_keys beschreibbar, weist der Server den Schlüssel stillschweigend ab. Das ist eine der häufigsten Ursachen für „der Schlüssel funktioniert einfach nicht".

Schritt 3: Der Rechte-Fehler, der alle einmal trifft

Kopierst du deinen Schlüssel auf einen anderen Rechner – etwa per USB-Stick oder aus einer Sicherung –, verliert er oft seine Rechte. Das Ergebnis ist unmissverständlich:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/dr/.ssh/id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
Load key "/home/dr/.ssh/id_ed25519": bad permissions

Im Test trat das bei 644, 640, 660 und 666 auf – also bei jedem gesetzten Bit für Gruppe oder andere. Nur mit 600 funktioniert es. Die Behebung:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Ein Hinweis zum Testen, der viel Verwirrung erspart: Beim Ausprobieren eines bestimmten Schlüssels reicht -i nicht. SSH probiert nämlich zusätzlich alle Standardschlüssel und nimmt stillschweigend einen, der funktioniert – du testest dann etwas anderes, als du glaubst. Erst diese Kombination testet wirklich nur den genannten Schlüssel:

ssh -i ~/pfad/zum/key -o IdentitiesOnly=yes benutzer@server

Genau darüber bin ich beim Schreiben dieses Artikels selbst gestolpert: Der erste Versuch zeigte den Rechte-Fehler nicht, weil SSH im Hintergrund den funktionierenden Standardschlüssel benutzte.

Schritt 4: Kurznamen statt langer Befehle

Wer mehrere Server hat, tippt schnell zu viel. Die Datei ~/.ssh/config nimmt dir das ab:

Host heim
    HostName 192.168.1.50
    User dr
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host webserver
    HostName mein-server.de
    User admin
    IdentityFile ~/.ssh/id_webserver
    IdentitiesOnly yes

chmod 600 ~/.ssh/config

Danach genügt ssh heim. Und weil sich scp und rsync dieselbe Datei ansehen, funktioniert auch scp datei.txt heim:~/.

Was SSH aus einem Kurznamen tatsächlich macht, verrät ein sehr nützlicher Schalter:

$ ssh -G heim
hostname 192.168.1.50
user dr
port 22
identityfile ~/.ssh/id_ed25519
identitiesonly yes

Das ist die aufgelöste Konfiguration – ideal, wenn du dich fragst, warum SSH etwas anderes tut als erwartet.

Schritt 5: ssh-agent – Passphrase nur einmal

Der Agent hält deinen entsperrten Schlüssel im Arbeitsspeicher. Du gibst die Passphrase einmal pro Sitzung ein, danach nie wieder.

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

Enter passphrase for /home/dr/.ssh/id_ed25519:
Identity added: /home/dr/.ssh/id_ed25519 (dr@arbeitsplatz)

Was gerade geladen ist, zeigt:

$ ssh-add -l
256 SHA256:i+j/RmuYB9CIWHwu5gjUNZJWbGeYKRG0QzdFLwQI7Hc dr@arbeitsplatz (ED25519)

Auf einem Desktop-Linux läuft der Agent meist schon und fragt beim ersten Zugriff grafisch nach der Passphrase – dann musst du gar nichts tun. Auf einem Server ohne grafische Oberfläche brauchst du die beiden Befehle oben; mit ssh-add -t 8h vergisst der Agent den Schlüssel nach acht Stunden von selbst.

Nicht verwechseln mit Agent-Weiterleitung: ssh -A gibt deinen Agenten an den Server weiter. Das ist praktisch, um von dort aus weiterzuspringen – aber wer auf diesem Server Root-Rechte hat, kann deinen Agenten mitbenutzen. Auf fremden Servern besser ProxyJump verwenden.

Schritt 6: Passwort-Login abschalten – und der Ubuntu-Fallstrick

Solange Passwörter erlaubt sind, bringt der Schlüssel sicherheitstechnisch wenig: Angreifer probieren weiter Passwörter durch. Erst das Abschalten macht den Unterschied.

Vorher unbedingt prüfen, dass dein Schlüssel funktioniert – sonst schließt du dich aus. Und lass während der ganzen Änderung eine zweite SSH-Sitzung offen. Solange die steht, kommst du zurück, selbst wenn du etwas kaputt machst.

Der naheliegende Weg – und warum er auf Ubuntu versagt

Üblicherweise bearbeitet man /etc/ssh/sshd_config, setzt PasswordAuthentication no, lädt den Dienst neu und ist fertig. Auf Debian funktioniert das. Auf Ubuntu nicht, und zwar ohne jede Fehlermeldung.

Im Test habe ich genau das gemacht:

$ sudo grep -n "^PasswordAuthentication" /etc/ssh/sshd_config
78:PasswordAuthentication no
$ sudo sshd -t
$ sudo systemctl reload ssh

Kein Fehler, kein Hinweis. Aber was gilt wirklich?

$ sudo sshd -T | grep -i "^passwordauthentication"
passwordauthentication yes

Immer noch erlaubt. Die Ursache steht weiter oben in derselben Datei:

$ sudo grep -nE "^Include|PasswordAuthentication" /etc/ssh/sshd_config
24:Include /etc/ssh/sshd_config.d/*.conf
78:PasswordAuthentication no

Und in diesem Verzeichnis liegt bei Ubuntu:

$ sudo cat /etc/ssh/sshd_config.d/50-cloud-init.conf
PasswordAuthentication yes

Jetzt greift eine Regel von OpenSSH, die man kennen muss: Bei mehrfach gesetzten Einstellungen gilt die erste, nicht die letzte. Die Include-Zeile steht in Zeile 24, deine Änderung in Zeile 78 – also wird zuerst die Datei aus dem Verzeichnis gelesen, und die sagt „yes". Deine Zeile wird gelesen und verworfen.

Auf Debian ist dasselbe Verzeichnis leer, deshalb wirkt dort die Hauptdatei. Im Test bestätigt: nach derselben Änderung meldete Debian passwordauthentication no.

Die saubere Lösung

Nicht die cloud-init-Datei bearbeiten – sie kann bei Updates zurückkommen. Lege stattdessen eine eigene Datei an, die vorher einsortiert wird. Die Dateien werden in alphabetischer Reihenfolge gelesen, also gewinnt 10- gegen 50-:

sudo tee /etc/ssh/sshd_config.d/10-haerten.conf <<EOF
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
EOF
sudo chmod 600 /etc/ssh/sshd_config.d/10-haerten.conf

Die zweite Zeile ist kein Beiwerk: Ohne KbdInteractiveAuthentication no kann der Server über einen Umweg weiterhin nach Passwörtern fragen. Beide Zeilen gehören zusammen.

Prüfen und neu laden – in dieser Reihenfolge:

sudo sshd -t
sudo systemctl reload ssh

Und dann kontrollieren, was gilt:

$ sudo sshd -T | grep -iE "^(passwordauthentication|permitrootlogin|pubkeyauthentication)"
passwordauthentication no
permitrootlogin no
pubkeyauthentication yes

Das ist der Zustand, den du willst. Zur Gegenprobe im Test, von einem anderen Rechner aus mit erzwungenem Passwort-Login:

$ ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no dr@server
dr@server: Permission denied (publickey).

Der Server bietet nur noch Schlüssel an. Gleichzeitig funktionierte die Schlüssel-Anmeldung unverändert weiter.

sshd -t und sshd -T – der wichtigste Unterschied

Der kleine Buchstabe schützt dich vor einem kaputten Dienst, der große vor falscher Sicherheit. Genau dieser Unterschied ist der Grund, warum das Ubuntu-Problem so oft unentdeckt bleibt: -t sagt „alles in Ordnung", obwohl die Einstellung nicht greift.

Häufige Fragen

Wo finde ich meinen SSH-Key?

In ~/.ssh/. Der private heißt üblicherweise id_ed25519, der öffentliche id_ed25519.pub. Unter Windows liegt das Verzeichnis unter C:\Users\DeinName\.ssh.

Wie erstelle ich einen SSH-Key unter Windows?

Genauso. Windows 10 und 11 bringen OpenSSH mit – ssh-keygen -t ed25519 funktioniert in PowerShell unverändert. Für den Agenten musst du den Dienst „OpenSSH Authentication Agent" einmalig starten und auf automatisch stellen. PuTTY mit seinem eigenen Schlüsselformat brauchst du dafür nicht mehr.

Kann ich denselben Schlüssel auf mehreren Servern nutzen?

Ja, das ist der Normalfall: ein Schlüssel pro Gerät, hinterlegt auf allen Servern, die du nutzt. Umgekehrt – ein Schlüssel pro Server auf demselben Rechner – bringt keinen Sicherheitsgewinn und macht nur Arbeit. Sinnvoll getrennt wird nach Vertrauensbereich: privat und dienstlich zum Beispiel.

Was mache ich, wenn ich den privaten Schlüssel verliere?

Neuen erzeugen und den alten öffentlichen Schlüssel aus ~/.ssh/authorized_keys auf allen Servern entfernen. Deshalb lohnt der Kommentar mit -C: Nur so weißt du hinterher, welche Zeile welchem Gerät gehörte.

Passphrase vergessen – kann ich sie zurücksetzen?

Nein. Die Passphrase verschlüsselt den Schlüssel; ohne sie ist die Datei wertlos. Ändern lässt sie sich mit ssh-keygen -p -f ~/.ssh/id_ed25519, aber nur wenn du die alte kennst. Andernfalls: neuer Schlüssel.

Warum wird mein Schlüssel vom Server abgewiesen?

In dieser Reihenfolge prüfen: Rechte auf deinem Rechner (600 für den privaten Schlüssel), Rechte auf dem Server (700 für ~/.ssh, 600 für authorized_keys), und ob der Schlüssel wirklich vollständig in einer Zeile dort steht. ssh -v benutzer@server zeigt Schritt für Schritt, was passiert.

Ist ein Schlüssel auf einem Hardware-Token noch besser?

Ja. Mit ssh-keygen -t ed25519-sk erzeugst du einen Schlüssel, dessen geheimer Teil einen FIDO2-Stick nie verlässt – kopieren ist damit unmöglich. Voraussetzung sind OpenSSH 8.2 oder neuer auf beiden Seiten.

Soll ich den SSH-Port ändern?

Es reduziert den Lärm automatisierter Scans, ist aber kein Sicherheitsgewinn – wer zielt, findet den Port. Wirksam sind abgeschaltetes Passwort-Login und ein Sperrmechanismus wie fail2ban.

Fazit

Der Schlüssel selbst ist in zehn Sekunden erzeugt: ssh-keygen -t ed25519, ssh-copy-id, fertig. Wer nur das macht, hat schon gewonnen – bequemer und sicherer als jedes Passwort.

Der Schritt, der wirklich schützt, ist das Abschalten des Passwort-Logins. Und dort gilt die eine Regel, die diesen Artikel zusammenfasst: Glaube nicht der Datei, die du bearbeitet hast, sondern sudo sshd -T. Auf Ubuntu liegt eine cloud-init-Datei über deiner Einstellung, ohne dass irgendetwas eine Warnung ausgibt.

Sinnvolle nächste Schritte: fail2ban einrichten, damit Angreifer nach wenigen Fehlversuchen gesperrt werden, und Tailscale, wenn du von außen zugreifen willst, ohne einen Port zu öffnen. Die Grundbefehle für die Arbeit auf dem Server stehen in Linux-Befehle für den Alltag.