Es ist Freitagabend, kurz vor dem Feierabend. Ein Junior-Admin sitzt vor seinem Terminal und soll schnell einen neuen Zugang für einen externen Entwickler einrichten. Er hat es eilig. Er erinnert sich vage an einen Befehl, wirft kurz die Suchmaschine an und führt den erstbesten Befehl aus, um Create An SSH Key Ubuntu zu erledigen. Er drückt bei der Passphrase einfach dreimal Enter, weil "das Tippen jedes Mal nervt", und kopiert den privaten Schlüssel direkt in einen Slack-Channel, um ihn dem Kollegen zu schicken. Drei Wochen später ist der Server Teil eines Botnetzes, die Datenbank wurde verschlüsselt und eine Lösegeldforderung über zwei Bitcoin prangt auf der Startseite. Das ist kein hypothetisches Schreckensszenario aus einem Lehrbuch. Ich habe genau diesen Ablauf in den letzten zehn Jahren bei mindestens fünf verschiedenen Firmen erlebt, vom kleinen Startup bis zum mittelständischen Dienstleister. Ein simpler Prozess, der falsch ausgeführt wird, kostet am Ende Zehntausende Euro an Wiederherstellungskosten und zerstört das Vertrauen der Kunden.
Der fatale Glaube an die Standardeinstellungen beim Create An SSH Key Ubuntu
Einer der häufigsten Fehler, die mir begegnen, ist das blinde Vertrauen in veraltete Tutorials. Viele Anleitungen im Netz kopieren seit 2010 denselben Befehl: ssh-keygen -t rsa. Das Problem dabei ist nicht, dass RSA per se kaputt ist, sondern dass die Standard-Bitlänge oft zu gering gewählt wird oder die Rechenleistung heutiger Angreifer einfach unterschätzt wird. Wer heute noch 1024-Bit RSA-Schlüssel verwendet, kann die Haustür auch gleich offen lassen.
In der Praxis sehe ich oft, dass Leute den Standardweg wählen, ohne zu verstehen, was im Hintergrund passiert. Ubuntu liefert zwar moderne Tools mit, aber die Bequemlichkeit siegt fast immer über die Sicherheit. Ein moderner Angreifer nutzt spezialisierte Hardware, um schwache Schlüssel durch Brute-Force-Attacken zu knacken. Wenn man sich die Mühe macht, Create An SSH Key Ubuntu professionell anzugehen, sollte man direkt auf Ed25519 setzen. Diese Schlüssel sind kürzer, schneller und bieten ein deutlich höheres Sicherheitsniveau bei geringerem Rechenaufwand. Es gibt keinen vernünftigen Grund mehr, auf RSA zu setzen, es sei denn, man muss ein antikes System aus den frühen 2000ern warten. Wer Sicherheit nur als lästige Pflichtaufgabe sieht, wird früher oder später den Preis dafür zahlen.
Warum eine fehlende Passphrase kein Komfortgewinn sondern ein Risiko ist
Der zweite große Fehler ist der Verzicht auf die Passphrase. Ich höre oft das Argument: "Ich will nicht jedes Mal mein Passwort eingeben, wenn ich mich verbinde." Das klingt logisch, ist aber brandgefährlich. Ein privater Schlüssel ohne Passphrase liegt unverschlüsselt auf deiner Festplatte. Wenn dein Laptop gestohlen wird oder eine Malware Zugriff auf dein Home-Verzeichnis bekommt, hat der Angreifer sofort uneingeschränkten Zugriff auf alle Server, auf denen dieser Schlüssel hinterlegt ist.
Ich habe Situationen erlebt, in denen Entwickler ihre ungeschützten Schlüssel in einem unverschlüsselten Backup auf einem USB-Stick verloren haben. Die Lösung ist nicht, die Sicherheit zu opfern, sondern Tools wie den ssh-agent zu verwenden. Man gibt die Passphrase einmal pro Sitzung ein, und das Tool kümmert sich um den Rest. Das ist der goldene Mittelweg zwischen Usability und Schutz. Wer glaubt, er könne durch das Weglassen der Passphrase Zeit sparen, rechnet nicht die Zeit ein, die er braucht, um nach einem Sicherheitsvorfall alle Server neu aufzusetzen und alle Passwörter zu ändern.
Der Irrglaube über den ssh-agent
Viele denken, der ssh-agent sei kompliziert einzurichten. Dabei ist er bei Ubuntu oft schon im Hintergrund aktiv. Man muss ihn nur füttern. Ein kurzer Befehl wie ssh-add reicht aus. Wenn man das ignoriert, zeigt das nur, dass man den Prozess nicht verstanden hat. In professionellen Umgebungen ist ein Schlüssel ohne Passphrase oft ein Grund für eine sofortige Abmahnung, und das aus gutem Grund. Es ist die einzige Barriere, die zwischen einem Dieb und deinen Produktionsdaten steht.
Die Gefahr des falschen Schlüssel-Versands
Stellen wir uns zwei Szenarien vor, wie man den Zugang zum Server verteilt.
Szenario A (Der Klassiker des Scheiterns):
Ein Admin generiert ein Schlüsselpaar auf seinem eigenen Rechner. Er nimmt die Datei id_rsa (den privaten Teil!) und schickt sie per E-Mail oder über einen Messenger an den neuen Mitarbeiter. Der Mitarbeiter speichert die Datei irgendwo auf seinem Desktop und nutzt sie fortan. Der private Schlüssel ist nun über mindestens zwei Postfächer und diverse Server des E-Mail-Anbieters gewandert. Er liegt auf zwei verschiedenen Endgeräten. Die Kontrolle über die Identität ist komplett verloren gegangen.
Szenario B (Der professionelle Weg):
Der Mitarbeiter führt Create An SSH Key Ubuntu selbst auf seinem eigenen Rechner aus. Er generiert sein eigenes Schlüsselpaar. Er schickt dem Admin ausschließlich den öffentlichen Teil (id_ed25519.pub). Der Admin trägt diesen öffentlichen Schlüssel in die Datei ~/.ssh/authorized_keys auf dem Zielserver ein. Der private Schlüssel verlässt niemals das Gerät des Mitarbeiters.
Der Unterschied ist gewaltig. In Szenario A ist die Sicherheit eine Illusion. In Szenario B wird das Prinzip der asymmetrischen Verschlüsselung korrekt angewendet. Ich sehe viel zu oft, dass Admins aus Bequemlichkeit Schlüssel für andere erstellen. Das ist Faulheit, die sich rächt. Wenn du einen Schlüssel für jemand anderen erstellst, kennst du dessen privaten Schlüssel. Damit ist die Nicht-Abstreitbarkeit hinfällig. Wenn etwas auf dem Server passiert, kannst du nicht beweisen, dass es der Kollege war und nicht du selbst.
Die Falle der Dateiberechtigungen auf Ubuntu
Ein technischer Fehler, der fast jeden Anfänger in den Wahnsinn treibt, sind die Berechtigungen im Dateisystem. Linux ist hier gnadenlos. Wenn die Rechte für den Ordner .ssh oder die Datei authorized_keys zu locker vergeben sind, wird der SSH-Dienst die Verbindung einfach ablehnen. Oft reagieren Admins dann mit blindem Aktionismus und setzen die Rechte auf 777 (jeder darf alles), nur damit es "endlich funktioniert".
Das ist so, als würde man ein Hochsicherheitsschloss einbauen, aber die Tür weit offen stehen lassen. SSH verlangt strikte Berechtigungen: Der Ordner .ssh muss dem Benutzer gehören und darf für niemanden sonst beschreibbar sein (chmod 700). Die Datei mit den öffentlichen Schlüsseln sollte ebenfalls restriktiv behandelt werden (chmod 600). In meiner Laufbahn habe ich Stunden damit verbracht, Server wieder abzusichern, die von "hilfsbereiten" Kollegen komplett für die Welt geöffnet wurden, nur weil sie eine Fehlermeldung nicht lesen wollten. Ubuntu protokolliert diese Fehler sehr genau in /var/log/auth.log. Wer dort nicht reinschaut, stochert im Dunkeln und macht alles nur noch schlimmer.
Das Märchen vom ewigen Schlüssel
Ein Schlüssel ist kein Diamant. Er hält nicht ewig. Ein großer Fehler im Schlüsselmanagement ist das Fehlen einer Rotationsstrategie. Ich habe Schlüssel gesehen, die seit acht Jahren im Einsatz waren, von Mitarbeitern, die die Firma längst verlassen hatten. Das ist ein administrativer Albtraum.
In einer sauberen Umgebung werden Schlüssel regelmäßig ausgetauscht. Mindestens einmal im Jahr, bei sensiblen Systemen öfter. Man sollte sich angewöhnen, den öffentlichen Schlüsseln einen Kommentar am Ende hinzuzufügen, der das Erstellungsdatum und den Zweck enthält. Ein Befehl wie ssh-keygen -t ed25519 -C "admin-laptop-2024-05" hilft enorm bei der Übersicht. Ohne diese Struktur weiß nach zwei Jahren niemand mehr, welcher Schlüssel zu wem gehört. Die Angst, den falschen Schlüssel zu löschen und sich selbst auszusperren, führt dann dazu, dass alte Leichen im System bleiben. Das ist ein Sicherheitsrisiko, das mit jedem Monat wächst.
Werkzeuge für die Verwaltung nutzen
Wenn man mehr als drei Server verwaltet, reicht die manuelle Pflege der authorized_keys nicht mehr aus. Man verliert den Überblick. Hier kommen Tools wie Ansible oder spezialisierte Identity-Management-Systeme ins Spiel. Wer versucht, SSH-Zugänge für ein Team von zehn Leuten auf zwanzig Servern von Hand zu verwalten, wird unweigerlich Fehler machen. Ein vergessener Schlüssel eines entlassenen Mitarbeiters ist die perfekte Hintertür für Spionage oder Sabotage.
Root-Login und Passwort-Authentifizierung deaktivieren
Der sicherste SSH-Schlüssel bringt nichts, wenn der Server weiterhin Passwörter akzeptiert. Das ist der Punkt, an dem die meisten Hobby-Admins aufhören. Sie richten den Schlüssel ein, freuen sich, dass es klappt, und lassen die Passwort-Authentifizierung in der /etc/ssh/sshd_config aktiviert.
Bots scannen das Internet rund um die Uhr nach offenen SSH-Ports. Sie probieren Millionen von Kombinationen aus Benutzernamen und Passwörtern aus. Wenn man den Schlüsselzugang eingerichtet hat, muss der nächste Schritt zwingend das Abschalten der Passwort-Authentifizierung sein (PasswordAuthentication no). Ebenso sollte der direkte Root-Login unterbunden werden (PermitRootLogin no). Man loggt sich als normaler Benutzer ein und nutzt sudo. Alles andere ist grob fahrlässig. Ich habe Server gesehen, die innerhalb von zehn Minuten nach der Bereitstellung im Netz bereits Tausende von fehlgeschlagenen Login-Versuchen hatten. Wer hier nicht konsequent ist, lädt zum Einbruch geradezu ein.
Realitätscheck
Am Ende des Tages ist Technik nur ein Werkzeug. Ein SSH-Schlüssel ist keine magische Barriere, die alle Probleme löst. Wenn du dich nicht disziplinierst, deine Workflows sauber zu halten, wird auch die beste Verschlüsselung dich nicht retten. Die Wahrheit ist: Echte Sicherheit ist anstrengend. Sie bedeutet, dass man Fehlermeldungen liest, statt sie zu ignorieren. Sie bedeutet, dass man Kollegen auf die Finger klopft, wenn sie Schlüssel unverschlüsselt verschicken. Und sie bedeutet, dass man Zeit in die Dokumentation investiert.
Erfolgreiches Arbeiten mit Ubuntu-Servern erfordert keine Genialität, sondern Sorgfalt. Wenn du meinst, du könntest Abkürzungen nehmen, indem du Passphrasen weglässt oder Berechtigungen ignorierst, dann spielst du russisches Roulette mit deinen Daten. Es geht nicht darum, ob du gehackt wirst, sondern wann. Die Kosten für eine saubere Einrichtung sind minimal im Vergleich zu den Kosten für eine Datenrettung oder den Reputationsverlust nach einem Leak. Wer das nicht begreift, sollte keine Server im Internet betreiben. Es gibt keine Abkürzung, die funktioniert. Nur den richtigen Weg – und der erfordert Disziplin bei jedem einzelnen Schritt. Es klappt nicht mit Halbwissen und ein bisschen Glück. Man muss das System verstehen oder man wird von ihm bestraft. So einfach ist das.
