SSH Keys unter Linux erstellen und richtig nutzen

SSH Keys unter Linux erstellen klingt erstmal nach trockenem Kryptokram. Ist es ein bisschen auch, aber zum Glück nur auf den ersten Blick. Wenn du dich per SSH auf Server einloggst, mit Git arbeitest oder kleine Automatisierungen baust, sind SSH-Schlüssel schnell deutlich angenehmer als Passwörter. Und sicherer sind sie in der Regel auch, wenn man sie sauber nutzt.

Ich nutze SSH Keys inzwischen fast überall. Für Serverzugriffe, Git-Repositories, Backup-Jobs und manchmal auch für kleine Scripte, die einfach zuverlässig laufen sollen. Trotzdem sehe ich immer wieder alte id_rsa-Dateien, private Schlüssel ohne Passphrase oder Verwirrung bei der Frage: Welchen Key-Typ nimmt man denn heute eigentlich?

🔐 Was ist ein SSH Key überhaupt?

Ein SSH Key besteht immer aus zwei Teilen:

• Privater Schlüssel: bleibt auf deinem Rechner und wird niemals weitergegeben.
• Öffentlicher Schlüssel: darf auf Server, Git-Plattformen oder andere Zielsysteme kopiert werden.

Der Server speichert also nur deinen öffentlichen Schlüssel. Beim Login prüft SSH dann, ob dein privater Schlüssel dazu passt. Dein privater Schlüssel verlässt dabei nicht deinen Rechner. Genau das ist der große Vorteil gegenüber einem normalen Passwort.

Wichtig ist nur: Wenn jemand deinen privaten Schlüssel bekommt, ist das ungefähr so, als würdest du ihm deinen Haustürschlüssel in die Hand drücken. Deshalb gehört auf private SSH Keys fast immer eine Passphrase.

🛠️ SSH Keys unter Linux erstellen

Für die meisten aktuellen Systeme ist Ed25519 heute meine erste Wahl. Der Schlüssel ist kurz, schnell, modern und wird von aktuellen OpenSSH-Versionen sehr gut unterstützt.

ssh-keygen -t ed25519 -a 100 -C "deinname@notebook"

Die Optionen kurz übersetzt:

• -t ed25519 legt den Schlüsseltyp fest.
• -a 100 erhöht den Aufwand zum Knacken der Passphrase, falls der private Schlüssel gestohlen wird.
• -C setzt einen Kommentar, damit du später noch weißt, wofür der Schlüssel gedacht war.

Beim Dateinamen kannst du den Vorschlag übernehmen oder bewusst einen eigenen Namen vergeben. Wenn du mehrere Schlüssel nutzt, ist ein sprechender Name sehr praktisch.

~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub

Die Datei ohne .pub ist privat. Die Datei mit .pub ist öffentlich. Die öffentliche Datei darfst du kopieren, teilen und auf Server legen. Die private Datei bleibt bei dir. Immer.

🧭 Welcher SSH Key für welchen Zweck?

Hier wird es meistens unnötig kompliziert gemacht. In der Praxis reicht diese Einordnung fast immer:

Ed25519: meine Empfehlung für neue Schlüssel

Wenn du heute einen neuen SSH Key für Linux, Git, Server oder dein Homelab erstellst, nimm in den meisten Fällen Ed25519.

• kurze Schlüssel
• schnelle Authentifizierung
• sehr gute Unterstützung in modernen Systemen
• angenehm für den Alltag

Für normale Serverzugriffe ist das meine Standardantwort. Schön, wenn Technik auch mal nicht unnötig sperrig ist.

RSA: sinnvoll für alte Systeme und Kompatibilität

RSA ist nicht automatisch schlecht. Wichtig ist aber die Einordnung. Alte RSA-Schlüssel mit 1024 Bit gehören ins Museum. Neue RSA-Schlüssel sollten mindestens 3072 Bit haben, ich nehme meistens 4096 Bit, wenn ich RSA wirklich brauche.

ssh-keygen -t rsa -b 4096 -a 100 -C "deinname@legacy-system"

RSA ist vor allem dann praktisch, wenn du mit älteren Appliances, alten NAS-Systemen, Netzwerkhardware oder betagten Linux-Installationen arbeiten musst. Also genau mit den Dingen, die man eigentlich längst aktualisieren wollte. Du kennst das.

Wichtig: Wenn irgendwo von ssh-rsa die Rede ist, geht es oft um die alte RSA-Signatur mit SHA-1. Das ist nicht dasselbe wie ein moderner RSA-Schlüssel, der mit rsa-sha2-256 oder rsa-sha2-512 verwendet wird. Trotzdem gilt: Wenn Ed25519 funktioniert, nimm Ed25519.

ECDSA: funktioniert, ist aber selten meine erste Wahl

ECDSA ist ebenfalls ein elliptisches Kurvenverfahren und wird von OpenSSH unterstützt. In der Praxis sehe ich aber wenig Gründe, neue normale Benutzer-Keys noch mit ECDSA zu erstellen, wenn Ed25519 verfügbar ist.

ECDSA kann sinnvoll sein, wenn eine Umgebung diesen Typ ausdrücklich erwartet oder Ed25519 dort nicht sauber unterstützt wird. Sonst bleibt es bei mir eher zweite Reihe.

DSA: bitte nicht mehr verwenden

DSA ist veraltet und in aktuellen OpenSSH-Versionen praktisch raus aus dem Spiel. Falls du noch irgendwo id_dsa findest, ist das ein guter Moment für einen neuen Schlüssel. Kaffee holen, neuen Key bauen, alten Zugriff sauber ersetzen.

FIDO2 und Security Keys: wenn es besonders sauber sein soll

Wenn du einen Hardware-Sicherheitsschlüssel wie einen YubiKey nutzt, kannst du auch SSH Keys erstellen, bei denen der private Schlüssel an den Security Key gebunden ist. OpenSSH kennt dafür unter anderem ed25519-sk und ecdsa-sk.

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

Der Vorteil: Ein Login braucht dann nicht nur eine Datei auf deinem Rechner, sondern auch den physischen Security Key. Für Admin-Zugänge, besonders wichtige Server oder Git-Signing ist das richtig interessant.

Der Nachteil: Du brauchst die passende Hardware und solltest dir vorher Gedanken über Ersatzschlüssel und Wiederherstellung machen. Sonst sperrst du dich im schlimmsten Fall selbst aus. Das ist sicher, aber nicht unbedingt lustig.

📋 Den öffentlichen Schlüssel auf den Server kopieren

Am einfachsten geht das mit ssh-copy-id. Dabei wird dein öffentlicher Schlüssel in die Datei ~/.ssh/authorized_keys des Zielbenutzers geschrieben.

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

Danach testest du den Login:

ssh benutzer@server

Wenn du einen speziellen Dateinamen verwendet hast, gib den Schlüssel direkt mit an:

ssh -i ~/.ssh/server_ed25519 benutzer@server

🗂️ Mehrere SSH Keys sauber verwalten

Wenn du mehrere Server, Git-Accounts oder Kundenumgebungen nutzt, wird es mit einem einzigen Schlüssel schnell unübersichtlich. Ich trenne solche Zugänge gerne bewusst.

~/.ssh/id_ed25519_home
~/.ssh/id_ed25519_git
~/.ssh/id_ed25519_kunde_a

Dazu passt eine aufgeräumte SSH-Konfiguration:

Host mein-server
    HostName 203.0.113.10
    User patrick
    IdentityFile ~/.ssh/id_ed25519_home
    IdentitiesOnly yes

Danach reicht:

ssh mein-server

IdentitiesOnly yes sorgt dafür, dass SSH nicht wild mehrere Schlüssel aus deinem Agent ausprobiert. Das ist besonders hilfreich, wenn ein Server nach zu vielen falschen Versuchen die Verbindung beendet.

🔑 Passphrase und ssh-agent

Eine Passphrase schützt deinen privaten Schlüssel. Ja, sie ist ein zusätzlicher Schritt. Nein, sie ist nicht nur Deko.

Damit du die Passphrase nicht bei jeder Verbindung neu eintippen musst, gibt es den ssh-agent. Der hält den entsperrten Schlüssel für deine laufende Sitzung bereit.

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

Auf vielen Desktop-Systemen übernimmt das inzwischen der Schlüsselbund der grafischen Oberfläche. Auf Servern oder minimalen Linux-Systemen ist es aber gut zu wissen, wie es manuell funktioniert.

✅ Berechtigungen prüfen

SSH ist bei Dateirechten recht pingelig. Das ist gut so. Wenn dein Key nicht akzeptiert wird, lohnt sich ein Blick auf die Rechte:

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

Auf dem Zielserver muss außerdem das Home-Verzeichnis des Benutzers sinnvoll abgesichert sein. Wenn alles auf 777 steht, wird SSH nicht beeindruckt sein. Und ehrlich gesagt: Ich auch nicht.

♻️ Alte SSH Keys austauschen

Wenn du noch alte Schlüssel hast, musst du nicht panisch alles löschen. Besser ist ein ruhiger Wechsel:

1. Neuen Ed25519-Key erstellen.
2. Öffentlichen Schlüssel auf den Server kopieren.
3. Login mit dem neuen Schlüssel testen.
4. Alten Schlüssel aus authorized_keys entfernen.
5. Erst danach alte private Schlüssel archivieren oder löschen.

Gerade bei produktiven Servern gilt: Erst testen, dann aufräumen. Andersherum ist es zwar mutig, aber Mut ersetzt keinen zweiten Zugang.

💡 Meine kurze Empfehlung

Wenn du einfach nur wissen willst, was du nehmen sollst:

• Neue normale SSH-Zugänge: Ed25519
• Alte Systeme oder Appliances: RSA mit 4096 Bit
• Besonders schützenswerte Zugänge: Ed25519-SK mit Security Key
• Neue DSA-Keys: gar nicht

Dazu eine Passphrase, ordentliche Dateirechte und eine saubere ~/.ssh/config. Damit bist du für den Alltag schon sehr gut aufgestellt.

🎯 Fazit

SSH Keys sind eines dieser Themen, die am Anfang größer wirken, als sie eigentlich sind. Du brauchst kein Kryptografie-Studium, um sie sinnvoll einzusetzen. Für die meisten Fälle reicht ein moderner Ed25519-Key, eine gute Passphrase und ein bisschen Ordnung im ~/.ssh-Ordner.

Wenn du ältere Systeme betreust, bleibt RSA mit 4096 Bit ein brauchbarer Rettungsanker. Wenn du es noch besser absichern willst, lohnt sich ein Blick auf FIDO2-Keys mit Hardware-Token. Und DSA? Das darf in Ruhe in Rente bleiben.

Am Ende zählt vor allem: Der private Schlüssel bleibt privat. Klingt banal, ist aber genau der Punkt.

💬 Techniverse Community

Lust auf Austausch rund um Matrix, Selfhosting und andere smarte IT-Lösungen?
In der Techniverse Community triffst du Gleichgesinnte, kannst Fragen stellen oder einfach nerdigen Talk genießen.

Jetzt der Gruppe auf Matrix beitreten
~ Direkte Raumadresse: #community:techniverse.net

Für lockere Gespräche abseits der Kernthemen komm in den Talkraum
~ Direkte Raumadresse: #talk:techniverse.net

Wir freuen uns, wenn du dabei bist!