SSH Key erstellen und sicher verwenden

Stellen Sie sich vor, Sie betreuen ein Dutzend Server.Stellen Sie sich vor, Sie betreuen ein Dutzend Server. Ständig Passwörter eintippen? Das ist nicht nur lästig, sondern auch ein riesiges Sicherheitsrisiko. Brute-Force-Angriffe haben hier leichtes Spiel. Ein SSH Key macht Schluss damit: Er ersetzt das klassische Passwort durch ein hochsicheres, kryptografisches Schlüsselpaar und schafft so das Fundament für eine moderne und sichere IT-Landschaft.

Warum SSH-Schlüssel die bessere Wahl als Passwörter sind

In der Serveradministration ist der Abschied vom Passwort keine Bequemlichkeit, sondern eine Notwendigkeit. Selbst die komplexesten Passwörter können durch Phishing, Diebstahl oder automatisierte Attacken geknackt werden. Ein SSH-Schlüsselpaar setzt stattdessen auf asymmetrische Kryptografie – ein von Grund auf sichereres Prinzip.

Das Prinzip von Schloss und Schlüssel

Man kann sich das ganz einfach wie ein echtes Schloss mit dem passenden Schlüssel vorstellen. Sie erzeugen zwei Schlüssel, die mathematisch fest miteinander verbunden sind: einen öffentlichen und einen privaten.

• Der öffentliche Schlüssel (das Schloss): Diesen platzieren Sie auf dem Server, auf den Sie zugreifen möchten. Man kann ihn bedenkenlos teilen, denn er dient nur dazu, Daten zu verschlüsseln – nicht, um sie wieder zu entschlüsseln.
• Der private Schlüssel (der Schlüssel): Dieser bleibt streng geheim auf Ihrem lokalen Computer. Er ist das einzige Werkzeug, das die Verschlüsselung, die mit dem öffentlichen Schlüssel erstellt wurde, wieder aufheben kann.

Wenn Sie nun eine Verbindung zum Server aufbauen, schickt dieser Ihnen eine Art „Rätsel“, das er mit Ihrem öffentlichen Schlüssel erstellt hat. Nur Ihr privater Schlüssel kann die korrekte „Antwort“ darauf liefern. So beweisen Sie Ihre Identität, ohne dass Ihr privater Schlüssel oder gar ein Passwort jemals über das Netzwerk gesendet wird.

Sicherheit, die weit über den Login hinausgeht

Der Einsatz von SSH-Schlüsseln hört aber nicht beim Einloggen auf. Er ist die Basis für jede professionelle Automatisierung. Ob Backup-Skripte, Konfigurationsmanagement mit Tools wie Ansible oder CI/CD-Pipelines – sie alle brauchen einen sicheren Weg, um sich automatisiert an Servern anzumelden. SSH-Schlüssel machen genau das möglich, ohne dass man Passwörter im Klartext in Skripten hinterlegen muss, was eine gravierende Sicherheitslücke wäre.

Ein SSH-Schlüssel ist mehr als nur ein Passwort-Ersatz. Er ist ein digitaler Ausweis, der beweist, dass Sie derjenige sind, der Sie vorgeben zu sein, und schafft gleichzeitig die Grundlage für eine sichere, automatisierte Kommunikation zwischen Systemen.

Darüber hinaus sichern SSH-Schlüssel die gesamte Datenübertragung während einer Sitzung ab. Die komplette Kommunikation zwischen Ihrem Rechner und dem Server wird verschlüsselt, was Man-in-the-Middle-Angriffe praktisch unmöglich macht. Während viele den Fokus auf die Absicherung durch ein VPN legen, bietet SSH eine gezielte Verschlüsselung auf Anwendungsebene für den direkten Serverzugriff. Mehr zur Funktionsweise verschlüsselter Tunnel erfahren Sie in unserem Artikel, der erklärt, wie eine VPN-Verbindung funktioniert.

Die Umstellung auf SSH-Schlüssel ist also ein fundamentaler Schritt, um Ihre digitale Identität und Ihre Systeme wirklich abzusichern. Es ist der Wechsel von reaktiven Maßnahmen hin zu einem „Security by Design“-Ansatz, wie er in modernen Umgebungen nach ISO 27001 oder NIS-2 nicht mehr wegzudenken ist.

Den richtigen Algorithmus für Ihren SSH-Schlüssel wählen

Bevor Sie gleich den Befehl zur Erstellung Ihres neuen SSH-Schlüssels abfeuern, müssen Sie eine wichtige Entscheidung treffen, die über Sicherheit und Geschwindigkeit Ihrer Verbindung entscheidet: Welchen kryptografischen Algorithmus nehmen wir? Das klingt vielleicht nach trockener Theorie, aber die Wahl hat direkte praktische Auswirkungen.

Im Grunde läuft es auf einen Zweikampf zwischen den beiden Platzhirschen hinaus: Ed25519 und RSA. RSA ist der alte, erprobte Haudegen, den jeder kennt. Ed25519 ist der moderne, agilere Herausforderer. Ihre Entscheidung ist letztlich ein Abwägen zwischen maximaler Sicherheit und Performance auf der einen Seite und absoluter Kompatibilität mit älteren Systemen auf der anderen.

Ed25519: Die moderne und klare Empfehlung

Wenn Sie heute einen neuen SSH-Schlüssel anlegen, gibt es eigentlich nur eine Antwort: Ed25519. Dieser Algorithmus basiert auf moderner elliptischer Kurven-Kryptografie und hat gegenüber dem klassischen RSA-Verfahren handfeste Vorteile.

• Sicherer bei weniger Ballast: Ein Ed25519-Schlüssel bietet extrem hohe Sicherheit, ist dabei aber viel kürzer als ein vergleichbar sicherer RSA-Schlüssel. Das macht ihn in der Handhabung deutlich schneller.
• Spürbar bessere Performance: Die Berechnungen bei der Authentifizierung laufen mit Ed25519 einfach effizienter. Der Verbindungsaufbau ist flotter, was sich vor allem bei Skripten oder Tools bemerkbar macht, die im Sekundentakt neue SSH-Verbindungen aufbauen.
• Robusteres Design: Ed25519 ist von Haus aus unempfindlicher gegenüber bestimmten Angriffsarten (Side-Channel-Angriffe), die bei fehlerhaft implementierten Algorithmen ein theoretisches Risiko darstellen könnten.

Kurz gesagt: In jeder modernen IT-Landschaft, die auf halbwegs aktueller Software läuft, gibt es keinen vernünftigen Grund, nicht auf Ed25519 zu setzen. Das ist der zukunftssichere Standard.

RSA: Der Klassiker für maximale Kompatibilität

RSA ist der Dinosaurier unter den Public-Key-Algorithmen – und das meine ich positiv. Er ist seit Jahrzehnten im Einsatz und seine größte Stärke ist die schier unendliche Kompatibilität. Wenn Sie sich mit wirklich alten Servern, exotischer Netzwerk-Hardware oder irgendwelchen Embedded Systems verbinden müssen, die seit Jahren kein Update gesehen haben, ist RSA oft die einzige Option, die funktioniert.

Wichtig: Wenn es RSA sein muss, dann aber richtig. Die Schlüssellänge ist hier alles entscheidend. Ein RSA-Schlüssel muss heute mindestens 3072 Bit, besser noch 4096 Bit, lang sein. Alles darunter, wie die früher oft genutzten 2048 Bit, gilt nicht mehr als sicher für die Zukunft.

Der Kompromiss bei RSA ist die Effizienz. Die riesigen Schlüssel machen die Erstellung und die Verifizierung spürbar langsamer. Im Alltag fällt das bei einer einzelnen manuellen Verbindung kaum auf, aber in automatisierten Umgebungen kann dieser kleine Unterschied in der Summe durchaus ins Gewicht fallen.

Vergleich der SSH-Schlüsselalgorithmen Ed25519 und RSA

Um die Entscheidung zu erleichtern, hier noch einmal die wichtigsten Merkmale und typischen Einsatzgebiete von Ed25519 und RSA im direkten Vergleich.

Merkmal	Ed25519 (Empfohlen)	RSA (Legacy-kompatibel)
Sicherheit	Exzellent, gilt als sehr widerstandsfähig	Stark, aber nur bei ausreichender Schlüssellänge (mind. 3072 Bit)
Performance	Sehr schnell, geringe CPU-Last	Langsamer, besonders bei der Schlüsselerstellung und Verifizierung
Schlüssellänge	Kurz und effizient (256 Bit)	Lang und ressourcenintensiv (3072 oder 4096 Bit)
Kompatibilität	Sehr gut bei modernen Systemen (ab OpenSSH 6.5)	Exzellent, wird von nahezu allen Systemen unterstützt
Anwendungsfall	Standard für neue Setups, Cloud-Server, moderne Infrastruktur	Verbindung zu älteren Servern, Netzwerk-Hardware oder speziellen Systemen

Gerade in Deutschland, wo Datensicherheit einen hohen Stellenwert hat, hat sich Ed25519 in professionellen Umgebungen und Rechenzentren schnell durchgesetzt. Institutionen wie die Friedrich-Alexander-Universität Erlangen-Nürnberg raten explizit zur Verwendung moderner Algorithmen und warnen vor veralteten Standards. Mehr dazu finden Sie in den offiziellen Empfehlungen für SSH-Keys an der FAU.

Genug der Theorie, jetzt geht's ans Eingemachte. Einen SSH-Schlüssel zu erstellen, ist zum Glück kein Hexenwerk. Je nachdem, ob Sie unter Linux, macOS oder Windows arbeiten, unterscheidet sich der Weg nur minimal. Ich zeige Ihnen, wie Sie auf jedem System schnell und sicher zu Ihrem ersten Schlüsselpaar kommen.

Die Wahl des richtigen Algorithmus ist dabei der erste und vielleicht wichtigste Schritt.

Man sieht es hier ganz gut: Für alles, was modern ist, ist Ed25519 aufgrund seiner Kombination aus Geschwindigkeit und Sicherheit die klare Empfehlung. RSA bleibt ein solider Fallback, wenn man es mit älteren Systemen zu tun hat.

SSH-Schlüssel unter Linux und macOS erstellen

Wer auf einem Unix-System wie Linux oder macOS unterwegs ist, hat es besonders einfach. Das Kommandozeilen-Tool ssh-keygen ist hier schon vorinstalliert und der bewährte Standard.

Öffnen Sie einfach ein Terminal und tippen Sie folgenden Befehl ein. Wir setzen dabei direkt auf den modernen Ed25519-Algorithmus:

ssh-keygen -t ed25519 -C "ihre_email@beispiel.com"

Kurz zur Erklärung: Der Parameter -t legt den Schlüsseltyp fest (hier ed25519). Mit -C hängen wir einen Kommentar an – meist die eigene E-Mail-Adresse. Das ist ungemein praktisch, um später den Überblick über verschiedene Schlüssel zu behalten.

Nachdem Sie den Befehl abgesetzt haben, meldet sich ssh-keygen mit ein paar Fragen:

1. Wo soll der Schlüssel gespeichert werden?
   Enter file in which to save the key (~/.ssh/id_ed25519):
   Hier können Sie einfach mit Enter bestätigen. Der Standardpfad im versteckten .ssh-Ordner Ihres Home-Verzeichnisses ist perfekt.

2. Möchten Sie eine Passphrase vergeben?
   Enter passphrase (empty for no passphrase):
   Meine dringende Empfehlung: Tun Sie es! Eine starke Passphrase ist Ihre zweite Verteidigungslinie. Selbst wenn jemand Ihren privaten Schlüssel in die Finger bekommt, ist er ohne dieses Passwort nutzlos.

3. Bestätigen Sie die Passphrase.
   Tippen Sie die Passphrase zur Sicherheit einfach noch einmal ein.

Das war's auch schon. ssh-keygen bestätigt die Erstellung und zeigt Ihnen den Speicherort sowie den "Fingerabdruck" des Schlüssels an. In Ihrem ~/.ssh/ Verzeichnis liegen jetzt zwei neue Dateien: id_ed25519 (Ihr geheimer, privater Schlüssel) und id_ed25519.pub (der öffentliche Teil, den Sie weitergeben).

SSH-Schlüssel unter Windows erstellen

Auf Windows gibt es im Grunde zwei etablierte Wege zum Ziel. Entweder Sie nutzen die modernen Bordmittel von Windows oder Sie gehen den klassischen Weg über das Urgestein PuTTY.

Der moderne Weg: PowerShell oder WSL

In aktuellen Windows-Versionen (ab Windows 10) ist ein OpenSSH-Client fest integriert. Das bedeutet, Sie können ssh-keygen genauso verwenden, wie ich es eben für Linux und macOS beschrieben habe – direkt in der PowerShell oder der guten alten Eingabeaufforderung (CMD).

Eine super Alternative ist das Windows Subsystem for Linux (WSL). Damit holen Sie sich eine vollwertige Linux-Umgebung auf Ihren Windows-Rechner, in der ssh-keygen natürlich ebenfalls zur Verfügung steht. Gerade für Entwickler, die sowieso viel auf der Kommandozeile arbeiten, ist das oft der bequemste Weg.

Der klassische Weg: PuTTYgen

Seit Ewigkeiten ist PuTTY der De-facto-Standard für SSH unter Windows. Zum Lieferumfang gehört auch ein kleines, aber mächtiges Tool zur Schlüsselverwaltung: PuTTYgen.

So geht's Schritt für Schritt:

1. Algorithmus wählen: Starten Sie PuTTYgen und stellen Sie sicher, dass ganz unten bei „Parameters“ der Typ „Ed25519“ ausgewählt ist.
2. Schlüssel generieren: Klicken Sie auf „Generate“. Jetzt müssen Sie die Maus ein wenig über den leeren Bereich bewegen – das erzeugt die nötige Zufälligkeit für einen sicheren Schlüssel.
3. Passphrase setzen: Vergeben Sie in den Feldern „Key passphrase“ und „Confirm passphrase“ ein starkes Passwort.
4. Schlüssel speichern: Jetzt wird es wichtig. Speichern Sie Ihren privaten Schlüssel mit einem Klick auf „Save private key“. PuTTYgen legt ihn im eigenen .ppk-Format (PuTTY Private Key) ab. Diese Datei brauchen Sie später, um sich mit dem PuTTY-Client zu verbinden.
5. Öffentlichen Schlüssel kopieren: Der öffentliche Schlüssel wird direkt im Textfeld oben angezeigt. Markieren Sie den kompletten Inhalt und kopieren Sie ihn in die Zwischenablage. Genau diesen Textblock fügen Sie später auf dem Server in die authorized_keys-Datei ein.

Aus der Praxis: Denken Sie daran, dass PuTTY und OpenSSH unterschiedliche Formate nutzen. Ein mit ssh-keygen erstellter privater Schlüssel muss erst mit PuTTYgen ins .ppk-Format umgewandelt werden, bevor PuTTY ihn verwenden kann – und umgekehrt.

Gerade in Deutschland, wo die Rechenzentrumsinfrastruktur boomt, ist sichere Serververwaltung entscheidend. Bis 2025 soll die installierte Leistung auf fast 3.000 MW ansteigen – ein Zuwachs von rund 250 MW. Diese enorme Kapazität wird zu einem großen Teil über sichere SSH-Verbindungen gemanagt. Mehr zu dieser Entwicklung finden Sie in der Bitkom-Studie zu Rechenzentren in Deutschland.

Egal, für welchen Weg Sie sich entschieden haben, Sie halten jetzt ein einsatzbereites Schlüsselpaar in den Händen. Der nächste logische Schritt ist, Ihren öffentlichen Schlüssel auf dem Zielserver zu hinterlegen, um die passwortlose Anmeldung endlich zu aktivieren.

Den öffentlichen Schlüssel auf dem Server hinterlegen

Ein frisch erstelltes SSH-Schlüsselpaar ist wie ein neuer Hausschlüssel, der noch nicht zum Schloss passt. Ihr privater Schlüssel liegt sicher auf Ihrem Rechner, aber der Server hat noch keine Ahnung von seinem Gegenstück, dem öffentlichen Schlüssel. Erst wenn dieser auf dem Zielserver korrekt hinterlegt ist, kann die passwortlose Anmeldung ihre Magie entfalten.

Dieser Schritt ist absolut entscheidend – und erstaunlich oft die Ursache für spätere Login-Probleme. Es geht hier nicht nur darum, eine Textdatei zu kopieren. Es geht um Präzision und vor allem um die richtigen Dateiberechtigungen. Ein kleiner Fehler an dieser Stelle, und der Server verweigert aus Sicherheitsgründen sofort den Zugang.

Die eleganteste Methode: ssh-copy-id

Für alle, die von einem Linux- oder macOS-System arbeiten, gibt es ein Werkzeug, das wie für diese Aufgabe gemacht ist: ssh-copy-id. Dieses kleine, aber mächtige Tool ist die mit Abstand sicherste und einfachste Methode, um Ihren öffentlichen Schlüssel zu installieren.

Der Befehl erledigt alles Notwendige in einem Rutsch:

• Er verbindet sich zum Server (hierfür brauchen Sie einmalig Ihr Passwort).
• Er prüft, ob das .ssh-Verzeichnis existiert, und erstellt es bei Bedarf.
• Er legt die Datei authorized_keys an, falls sie fehlt.
• Er fügt Ihren öffentlichen Schlüssel an die Datei an, ohne bestehende Schlüssel zu überschreiben.
• Und das Wichtigste: Er setzt automatisch die korrekten, restriktiven Dateiberechtigungen.

Um das Tool zu nutzen, öffnen Sie einfach Ihr Terminal und geben Folgendes ein:

ssh-copy-id benutzername@server-adresse

Ersetzen Sie benutzername und server-adresse mit Ihren echten Zugangsdaten. Nachdem Sie Ihr Passwort eingegeben haben, ist der Schlüssel installiert. Von nun an können Sie sich ohne Passwort anmelden.

Der entscheidende Vorteil von ssh-copy-id liegt in seiner Zuverlässigkeit. Manuelles Kopieren ist fehleranfällig – ein falscher Befehl, und man überschreibt versehentlich bestehende Schlüssel. ssh-copy-id verhindert genau das und sorgt für die perfekten Berechtigungen, die für die Sicherheit unerlässlich sind.

Die manuelle Installation für Windows und andere Fälle

Was aber, wenn ssh-copy-id nicht verfügbar ist? Das ist oft der Fall, wenn man von einem Windows-System ohne WSL arbeitet. Dann müssen wir den Prozess eben von Hand erledigen. Das ist nicht kompliziert, erfordert aber Sorgfalt.

Zuerst brauchen Sie den Inhalt Ihres öffentlichen Schlüssels. Auf Linux oder macOS bekommen Sie ihn mit diesem Befehl angezeigt:

cat ~/.ssh/id_ed25519.pub

Kopieren Sie die gesamte Ausgabe – von ssh-ed25519 bis zu Ihrer E-Mail-Adresse am Ende – in die Zwischenablage. Falls Sie PuTTYgen verwendet haben, kopieren Sie den Schlüssel direkt aus dem Programmfenster.

Danach loggen Sie sich wie gewohnt mit Ihrem Passwort auf dem Zielserver ein. Dort führen Sie eine Befehlskette aus, die das Verzeichnis und die Datei anlegt und die Berechtigungen richtig setzt:

mkdir -p ~/.ssh && chmod 700 ~/.ssh && touch ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys

Dieser Befehl stellt sicher, dass alles mit den richtigen Rechten vorbereitet ist.

Jetzt fügen wir Ihren kopierten öffentlichen Schlüssel hinzu:

echo "IHR_KOPIERTER_ÖFFENTLICHER_SCHLÜSSEL" >> ~/.ssh/authorized_keys

Achten Sie hier unbedingt auf die doppelten Anführungszeichen (") um den Schlüssel und die doppelten Größer-als-Zeichen (>>). Letztere sorgen dafür, dass der Schlüssel angehängt und nicht die gesamte Datei überschrieben wird.

Warum Dateiberechtigungen so kritisch sind

Der SSH-Dienst auf dem Server ist extrem sicherheitsbewusst. Sind die Berechtigungen für das .ssh-Verzeichnis oder die authorized_keys-Datei zu offen, geht er vom Schlimmsten aus: Jemand könnte die Dateien manipuliert haben. Als Konsequenz verweigert er die Anmeldung per Schlüssel.

Die Regeln sind streng und einfach zu merken:

• Das ~/.ssh-Verzeichnis: Muss die Berechtigung 700 haben. Das bedeutet, nur Sie als Besitzer dürfen lesen, schreiben und das Verzeichnis betreten.
• Die ~/.ssh/authorized_keys-Datei: Muss die Berechtigung 600 haben. Nur Sie als Besitzer dürfen die Datei lesen und beschreiben.

Eine falsche Berechtigung ist der häufigste Grund für die Fehlermeldung „Permission denied (publickey)“. Wenn Sie also auf Probleme stoßen, sind diese beiden chmod-Befehle Ihre erste Anlaufstelle zur Fehlerbehebung. Für Administratoren, die einen sicheren Shell-Server unter Windows einrichten, gelten ganz ähnliche Prinzipien bei der Verwaltung von Benutzerrechten im Dateisystem.

SSH-Schlüssel im Alltag sicher verwalten

Ein SSH-Schlüssel ist schnell erstellt. Doch die eigentliche Herausforderung – und der Schlüssel zu langfristiger Sicherheit – liegt im professionellen Umgang damit. Nur wer seine Schlüssel sauber verwaltet, schöpft ihr volles Potenzial aus und macht sich den Arbeitsalltag leichter.

Genau hier kommt der ssh-agent ins Spiel. Man kann ihn sich wie einen kleinen, temporären Tresor vorstellen, der im Hintergrund auf dem System läuft und die entschlüsselten privaten Schlüssel bereithält.

Der Vorteil ist enorm praktisch: Statt bei jeder Verbindung die Passphrase neu einzutippen, geben Sie diese nur ein einziges Mal pro Sitzung ein, zum Beispiel direkt nach dem Hochfahren des Rechners. Der ssh-agent speichert den entschlüsselten Schlüssel dann sicher im Arbeitsspeicher. Jede weitere SSH-Verbindung, die Sie aufbauen, greift automatisch darauf zu. Kein lästiges Tippen mehr.

Den ssh-agent effektiv nutzen

Bei den meisten modernen Linux-Systemen und auch unter macOS ist der ssh-agent schon so konfiguriert, dass er automatisch mit der Desktop-Sitzung startet. Um ihm einen Schlüssel bekannt zu machen, genügt ein simpler Befehl im Terminal:

ssh-add ~/.ssh/id_ed25519

Sie werden nach Ihrer Passphrase gefragt, und sobald die eingegeben ist, steht der Schlüssel für die gesamte Sitzung zur Verfügung. Das beschleunigt nicht nur das manuelle Arbeiten, sondern ist oft die Grundvoraussetzung für automatisierte Skripte, die sich ohne menschliche Interaktion auf Servern anmelden müssen.

Schlüsselrotation: Ein einfaches, aber wirksames Ritual

Kein SSH-Schlüssel sollte ewig leben. Die regelmäßige Schlüsselrotation, also das Austauschen alter Schlüssel gegen neue, ist eine der wichtigsten Sicherheitsdisziplinen. Sollte ein privater Schlüssel – allen Vorsichtsmaßnahmen zum Trotz – doch einmal in die falschen Hände geraten, begrenzt die Rotation den potenziellen Schaden auf ein kurzes Zeitfenster.

Als Faustregel für Unternehmensumgebungen hat sich ein jährlicher Austausch bewährt. In hochsensiblen Bereichen, etwa bei Zugriffen auf kritische Infrastruktur, kann man den Zyklus auch auf drei bis sechs Monate verkürzen.

Ein solcher Austausch sollte immer nach einem festen Schema ablaufen:

• Neues Paar generieren: Zuerst wird ein frisches Schlüsselpaar erstellt.
• Neuen Schlüssel verteilen: Dann wird der neue öffentliche Schlüssel auf allen Zielsystemen hinterlegt.
• Login testen: Ganz wichtig – testen, ob der Login mit dem neuen Schlüssel reibungslos klappt.
• Alten Schlüssel entfernen: Erst wenn alles funktioniert, wird der alte öffentliche Schlüssel von den Servern gelöscht.

Berufliches und Privates strikt trennen

Ein absolutes No-Go ist die Verwendung desselben SSH-Schlüssels für den Job und für private Projekte. Diese strikte Trennung ist ein Grundpfeiler der Informationssicherheit.

Stellen Sie sich vor, Ihr privater Hobby-Server wird kompromittiert. Wenn der dort hinterlegte Schlüssel auch Zugang zur Firmeninfrastruktur hat, haben Sie ein gewaltiges Problem. Die Verwaltung getrennter Schlüssel ist dank der ~/.ssh/config-Datei zum Glück ein Kinderspiel und sollte zur Selbstverständlichkeit werden. Diese logische Trennung von Zugängen ist übrigens auch ein zentraler Punkt, den man aus dem Bereich professionelles Mobile Device Management kennt, wo private und geschäftliche Daten auf Endgeräten sauber getrennt werden müssen.

Compliance und die Sache mit dem Backup

Ein durchdachtes Schlüsselmanagement ist keine reine Fleißaufgabe, sondern oft eine handfeste Anforderung. Standards wie die ISO 27001 oder die NIS-2-Richtlinie fordern klare, nachweisbare Prozesse für die Verwaltung von Zugangsdaten – und SSH-Schlüssel gehören definitiv dazu.

Dazu gehört auch eine Backup-Strategie. Ein verlorener privater Schlüssel ist wie ein verlorener Generalschlüssel: Der Zugriff ist weg. Bewahren Sie daher immer eine verschlüsselte Kopie Ihres privaten Schlüssels an einem sicheren, getrennten Ort auf. Ein Passwort-Manager oder ein verschlüsselter USB-Stick im Tresor sind hier gute Kandidaten. Gerade im Kontext professioneller Lösungen für Remote Management ist ein ausfallsicherer und dokumentierter Prozess für den Schlüsselzugriff unerlässlich.

Fragen aus der Praxis: Typische Probleme mit SSH-Schlüsseln

Im Alltag mit SSH-Schlüsseln tauchen immer wieder die gleichen Fragen und Stolpersteine auf. Ich habe hier mal die häufigsten Probleme und die dazugehörigen Lösungen für Sie zusammengefasst – direkt aus der Praxis, damit Sie schnell wieder ans Ziel kommen.

Was mache ich, wenn mein privater SSH-Schlüssel weg ist?

Erstmal die schlechte Nachricht: Ein verlorener privater Schlüssel ist unwiederbringlich futsch. Es gibt keine "Passwort vergessen"-Funktion. Der Zugriff auf alle Server, die den zugehörigen öffentlichen Schlüssel kennen, ist damit erstmal blockiert.

Keine Panik, gehen Sie einfach systematisch vor:

1. Alternativen Zugang nutzen: Melden Sie sich anders am Server an. Meistens geht das noch über das klassische Passwort oder über die Web-Konsole Ihres Hosters.
2. Alten Schlüssel sperren: Das ist der wichtigste Schritt. Löschen Sie sofort den alten öffentlichen Schlüssel aus allen authorized_keys-Dateien. Damit stellen Sie sicher, dass niemand den verlorenen Schlüssel missbrauchen kann, falls er in falsche Hände gerät.
3. Neues Schlüsselpaar anlegen: Erzeugen Sie auf Ihrem lokalen Rechner ein frisches, neues Schlüsselpaar.
4. Neuen Schlüssel verteilen: Kopieren Sie den neuen öffentlichen Schlüssel auf alle Server, auf die Sie zugreifen müssen.

Dieser Vorfall ist der beste Weckruf dafür, wie wichtig ein sicheres, verschlüsseltes Backup Ihrer privaten Schlüssel ist.

Kann ich denselben SSH-Schlüssel für mehrere Server verwenden?

Klar, technisch ist das überhaupt kein Problem. Sie können den gleichen öffentlichen Schlüssel auf zehn, hundert oder tausend Servern hinterlegen und sich überall mit Ihrem einen privaten Schlüssel anmelden. Das ist auch ziemlich bequem.

Aus Sicherheitssicht ist das allerdings ein zweischneidiges Schwert. Wenn dieser eine private Schlüssel kompromittiert wird, hat ein Angreifer sofort den Jackpot geknackt und potenziell Zugriff auf alle Systeme, die Sie mit diesem Schlüssel verwalten. Ein klassisches "Single Point of Failure"-Problem.

Mein Rat aus der Praxis: Trennen Sie die Welten. Nutzen Sie mindestens einen separaten Schlüssel für die Arbeit und einen für private Projekte. In wirklich kritischen Umgebungen gehen wir sogar so weit, für jeden wichtigen Server ein eigenes Schlüsselpaar zu verwenden. Das minimiert das Risiko enorm.

Wie schalte ich die Passwort-Anmeldung auf dem Server komplett ab?

Sobald Sie sichergestellt haben, dass Ihr Login per SSH-Schlüssel einwandfrei funktioniert, sollten Sie die Passwort-Authentifizierung unbedingt deaktivieren. Das ist einer der wirksamsten Hebel, um Brute-Force-Angriffe auf Ihren Server ins Leere laufen zu lassen.

Dafür passen Sie die zentrale Konfigurationsdatei des SSH-Dienstes an, die fast immer unter /etc/ssh/sshd_config liegt. Öffnen Sie die Datei (mit Root-Rechten) und suchen Sie nach der Zeile PasswordAuthentication. Den Wert ändern Sie von yes auf no:

PasswordAuthentication no

Anschließend speichern und den SSH-Dienst neu starten, meist mit einem Befehl wie sudo systemctl restart sshd.

Ganz wichtiger Tipp: Bevor Sie Ihre aktuelle Sitzung beenden, machen Sie ein zweites Terminalfenster auf und testen Sie den Login mit Ihrem SSH-Schlüssel. So stellen Sie sicher, dass Sie sich nicht versehentlich selbst ausgesperrt haben. Das passiert öfter, als man denkt!

Warum klappt mein SSH-Login nicht, obwohl alles richtig aussieht?

In 9 von 10 Fällen, in denen ich bei Permission denied (publickey) um Hilfe gebeten werde, liegt es an den Dateiberechtigungen auf dem Server. Der SSH-Dienst ist da extrem penibel, und das aus gutem Grund.

Prüfen Sie auf dem Zielserver diese beiden Punkte:

• Das Verzeichnis ~/.ssh muss die Berechtigung 700 haben (drwx------). Nur Sie als Besitzer dürfen darauf zugreifen.
• Die Datei ~/.ssh/authorized_keys muss die Berechtigung 600 haben (-rw-------). Auch hier gilt: nur für Sie les- und schreibbar.

Mit chmod 700 ~/.ssh und chmod 600 ~/.ssh/authorized_keys können Sie das schnell korrigieren. Falls es dann immer noch nicht geht: Haben Sie den öffentlichen Schlüssel wirklich vollständig und ohne zusätzliche Zeilenumbrüche in die authorized_keys-Datei kopiert? Ein kurzer Blick in die Server-Logs (meist unter /var/log/auth.log oder /var/log/secure) verrät oft, wo genau es hakt.

---

Die professionelle und sichere Verwaltung von SSH-Schlüsseln ist kein Hexenwerk, aber ein absolutes Muss für jede sichere IT-Infrastruktur. Als nach ISO 27001 zertifizierter Partner unterstützen wir von der Deeken.Technology GmbH Unternehmen dabei, ihre Systeme nach höchsten Standards abzusichern und Compliance-Anforderungen wie NIS-2 zu erfüllen. Erfahren Sie mehr über unsere IT-Security-Lösungen.