SSH-Schlüssel: Anmeldung am Server ohne Passwort einrichten

Ein SSH-Schlüssel besteht aus einem Dateipaar: Der private Schlüssel bleibt bei Ihnen, der öffentliche kommt auf den Server. Beim Verbinden prüft der Server, ob Sie den zu einem erlaubten öffentlichen Schlüssel passenden privaten Schlüssel besitzen, und lässt Sie ohne Passwort hinein. Das ist bequemer und deutlich sicherer als ein Passwort: Einen Schlüssel durch Ausprobieren zu erraten ist praktisch unmöglich. Im Folgenden die Einrichtung von SSH-Schlüsseln von der Erzeugung bis zum Abschalten der Passwort-Anmeldung, mit den Fehlern, an denen man am häufigsten hängen bleibt.

So funktioniert die Authentifizierung per Schlüssel

Schlüssel sind asymmetrisch. Der öffentliche Schlüssel (id_ed25519.pub) kann jedem gezeigt werden — aus ihm lässt sich der private nicht rekonstruieren. Der private Schlüssel (id_ed25519) verlässt Ihren Rechner nie und wird nicht über das Netzwerk übertragen.

Beim Anmelden teilt der Client dem Server mit, welchen Schlüssel er verwenden will. Der Server sucht diesen öffentlichen Schlüssel in der Datei ~/.ssh/authorized_keys des Benutzers und fordert bei Erfolg den Client auf, die Sitzungsdaten mit dem privaten Schlüssel zu signieren. Die Signatur wird mit dem öffentlichen Schlüssel geprüft, und die Anmeldung wird erlaubt. Ein Passwort wird dabei gar nicht übertragen.

Schritt 1. Schlüssel erzeugen: ssh-keygen

Auf Ihrem Rechner (Linux, macOS oder Windows 10/11 mit dem integrierten OpenSSH) führen Sie aus:

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

Die Option -t legt den Algorithmus fest, -C einen Kommentar, der ans Ende des öffentlichen Schlüssels geschrieben wird und später hilft zu erkennen, wem der Schlüssel gehört. Ed25519 ist der moderne empfohlene Algorithmus: Schlüssel sind kurz, schnell und sicher. Ist der Server sehr alt und unterstützt Ed25519 nicht, nehmen Sie RSA mit mindestens 3072 Bit: ssh-keygen -t rsa -b 4096.

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/alena/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/alena/.ssh/id_ed25519
Your public key has been saved in /home/alena/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:Xq3v0m6c1y2pVv8m3N0uYv9yQm0e6dFv5gH2rZt1aBc alena@laptop

Brauchen Sie eine Passphrase?

Die Passphrase verschlüsselt den privaten Schlüssel auf der Festplatte. Wird das Notebook gestohlen oder die Datei geleakt, ist der Schlüssel ohne sie nutzlos. Für einen persönlichen Schlüssel lohnt sich eine Passphrase; damit Sie sie nicht bei jeder Verbindung eintippen müssen, verwenden Sie ssh-agent: Er hält den entschlüsselten Schlüssel bis zum Ende der Sitzung im Speicher.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh-add -l      # geladene Schlüssel anzeigen

Schlüssel ohne Passphrase sind für Automatisierung gerechtfertigt — etwa für CI oder ein Backup-Skript. Einen solchen Schlüssel sollte man auf dem Server einschränken (dazu unten mehr).

Schritt 2. Öffentlichen Schlüssel auf den Server kopieren: ssh-copy-id

Am einfachsten geht es mit ssh-copy-id. Es verbindet sich ein letztes Mal mit Passwort, hängt Ihren öffentlichen Schlüssel an ~/.ssh/authorized_keys auf dem Server an und setzt die richtigen Rechte.

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/alena/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
deploy@203.0.113.10's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'deploy@203.0.113.10'"
and check to make sure that only the key(s) you wanted were added.

Lauscht der Server auf einem nicht standardmäßigen Port, ergänzen Sie -p 2222.

Wenn ssh-copy-id nicht verfügbar ist

Unter Windows gibt es kein ssh-copy-id. Den Schlüssel übertragen Sie dann mit einem Befehl von Hand:

cat ~/.ssh/id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Cloud-Anbieter fragen den öffentlichen Schlüssel meist schon beim Anlegen des Servers ab — er landet dann über cloud-init in authorized_keys.

Schritt 3. Die Anmeldung testen

ssh deploy@203.0.113.10

Wenn kein Passwort mehr verlangt wird (oder nur die Passphrase des Schlüssels), funktioniert alles. Beim ersten Verbinden mit einem neuen Server zeigt SSH den Fingerabdruck des Host-Schlüssels und fragt, ob Sie ihm vertrauen. Nach der Antwort yes wird der Fingerabdruck in ~/.ssh/known_hosts gespeichert, und künftig warnt SSH, falls sich der Schlüssel des Servers ändert.

Um zu sehen, welche Schlüssel der Client ausprobiert und warum der Server ablehnt, starten Sie die Verbindung mit ausführlicher Ausgabe:

ssh -v deploy@203.0.113.10

Die Datei ~/.ssh/config: kurze Namen für Server

Bei mehreren Servern ist es mühsam, jedes Mal Benutzer, IP, Port und Schlüsselpfad einzutippen. All das beschreiben Sie in ~/.ssh/config:

Host prod
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host bastion
    HostName bastion.example.com
    User alena

Host db-intern
    HostName 10.0.0.15
    User admin
    ProxyJump bastion

Host *
    ServerAliveInterval 60
    AddKeysToAgent yes

Jetzt genügt ssh prod, und auch scp, rsync und Git verstehen diese Namen: rsync -av ./site/ prod:/var/www/.

• IdentitiesOnly yes — nur den angegebenen Schlüssel verwenden. Ohne diese Zeile probiert der Client alle Schlüssel aus dem Agenten, und der Server kann Sie wegen zu vieler Versuche trennen, bevor der richtige drankommt.
• ProxyJump — eine Verbindung zu einem internen Server über einen Zwischenserver (Bastion) in einem einzigen Befehl.
• ServerAliveInterval — alle 60 Sekunden ein „Ping“ senden, damit die Verbindung bei Inaktivität nicht abreißt.

Die Datei muss die Rechte 600 haben, sonst weigert sich SSH unter Umständen, sie zu lesen: chmod 600 ~/.ssh/config.

Agent Forwarding: wann es nötig ist und warum es riskant ist

Manchmal muss man von einem Server aus weiterverbinden — etwa um git pull aus einem privaten Repository auszuführen. Den privaten Schlüssel dorthin zu kopieren ist keine Option. Stattdessen verwenden Sie ssh -A oder ForwardAgent yes: Der Server erhält für die Dauer der Sitzung Zugriff auf Ihren Agenten. Doch wer auf diesem Server root-Rechte hat, kann den Agenten ebenfalls nutzen, solange Sie verbunden sind. Aktivieren Sie das Weiterleiten daher nur für vertrauenswürdige Hosts; für den Sprung über einen Zwischenserver nehmen Sie besser ProxyJump, denn dabei wird der Agent nicht geöffnet.

Schritt 4. Passwort-Anmeldung abschalten

Solange die Anmeldung per Passwort erlaubt ist, bleibt der Server ein Ziel für Brute-Force-Angriffe. Sobald Sie sich sicher per Schlüssel anmelden können, schalten Sie Passwörter ab. Wichtig: Schließen Sie die aktuelle Sitzung nicht, bevor Sie die Anmeldung in einem neuen Fenster getestet haben — sonst verlieren Sie womöglich den Zugang.

Öffnen Sie /etc/ssh/sshd_config (oder legen Sie eine Datei in /etc/ssh/sshd_config.d/ an, falls die Hauptkonfiguration sie mit Include einbindet) und setzen Sie:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

PermitRootLogin no verbietet die Anmeldung als root ganz: Administratoren melden sich mit ihren eigenen Benutzern an und erhalten Rechte über sudo. Ist die Anmeldung als root unverzichtbar, nehmen Sie PermitRootLogin prohibit-password — nur per Schlüssel.

Prüfen Sie die Syntax und laden Sie den Dienst neu:

sudo sshd -t
sudo systemctl reload ssh      # auf Debian/Ubuntu; auf RHEL-artigen Systemen — sshd

Der Befehl sshd -t gibt nichts aus, wenn die Konfiguration korrekt ist. Stellen Sie nun in einem neuen Terminal sicher, dass die Anmeldung per Schlüssel funktioniert und der Server die Anmeldung per Passwort ablehnt:

$ ssh -o PubkeyAuthentication=no deploy@203.0.113.10
deploy@203.0.113.10: Permission denied (publickey).

Zusätzlicher Schutz

Das Abschalten der Passwörter ist die wichtigste Maßnahme. Danach begrenzt man den Zugriff auf Port 22 mit einer Firewall (ufw allow from 198.51.100.0/24 to any port 22) und installiert fail2ban, das eine IP-Adresse nach einer Reihe fehlgeschlagener Versuche sperrt. Den Status des SSH-Schutzes zeigt sudo fail2ban-client status sshd.

Einen Schlüssel für die Automatisierung kann man direkt in authorized_keys mit Optionen vor dem Schlüssel einschränken: Zum Beispiel erlaubt from="198.51.100.7",no-port-forwarding,no-pty ssh-ed25519 AAAA... backup die Anmeldung nur von einer einzigen Adresse und ohne interaktive Shell.

Typische Fehler und ihre Behebung

Permission denied (publickey)

Der häufigste Fehler. Die Ursachen, von häufig zu selten:

1. Falsche Rechte auf dem Server. sshd ignoriert authorized_keys, wenn das Verzeichnis oder die Datei für andere schreibbar ist. Abhilfe: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, und das Home-Verzeichnis darf nicht für Gruppe oder andere schreibbar sein.
2. Falscher Besitzer. Haben Sie Dateien mit sudo angelegt, gehören sie root. Abhilfe: sudo chown -R deploy:deploy /home/deploy/.ssh.
3. Der Schlüssel liegt beim falschen Benutzer. Sie haben den Schlüssel für root kopiert, melden sich aber als deploy an, oder umgekehrt.
4. Der Client bietet den falschen Schlüssel an. Schauen Sie mit ssh -v nach: In den Zeilen Offering public key sehen Sie, welche Schlüssel probiert werden. Geben Sie den richtigen mit -i oder IdentityFile an.
5. Der Schlüssel ist beim Kopieren beschädigt. Der öffentliche Schlüssel muss in einer einzigen Zeile stehen. Ein Zeilenumbruch aus der Zwischenablage zerstört ihn.

Den serverseitigen Grund der Ablehnung zeigt das Protokoll: sudo journalctl -u ssh -n 30 (unter RHEL — -u sshd). Dort findet man Zeilen wie Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

UNPROTECTED PRIVATE KEY FILE

Der Client verweigert einen privaten Schlüssel, den andere Benutzer lesen können. Abhilfe: chmod 600 ~/.ssh/id_ed25519.

REMOTE HOST IDENTIFICATION HAS CHANGED

Der Host-Schlüssel stimmt nicht mit dem in known_hosts gespeicherten überein. Das passiert nach einer Neuinstallation des Servers oder einem Wechsel der IP, sieht aber genauso aus wie ein Man-in-the-Middle-Angriff. Vergewissern Sie sich, dass der Server tatsächlich neu aufgesetzt wurde, und entfernen Sie den alten Eintrag: ssh-keygen -R 203.0.113.10.

Too many authentication failures

Der Agent hat dem Server zu viele Schlüssel angeboten, und dieser hat die Verbindung wegen MaxAuthTries geschlossen. Die Lösung sind IdentitiesOnly yes und ein ausdrücklicher IdentityFile in ~/.ssh/config.

Fazit

Das Einrichten von SSH-Schlüsseln dauert fünf Minuten: ssh-keygen -t ed25519, ssh-copy-id, Test der Anmeldung, dann PasswordAuthentication no und das Neuladen von sshd, während eine zweite Sitzung offen bleibt. Die Datei ~/.ssh/config erspart lange Befehle, und die Rechte 700/600 lösen die meisten Fehler „Permission denied“. SSH, rsync sowie der Schutz des Servers mit Firewall und fail2ban werden in unserem Linux-Kurs praxisnah behandelt.