4 min read

SSH-Keys: Schluss mit Passwort-Login auf deinem Linux-Server

SSH-Keys: Schluss mit Passwort-Login auf deinem Linux-Server
Photo by rc.xyz NFT gallery / Unsplash

Wer einen Linux-Server betreibt – egal ob im Homelab oder irgendwo in der Cloud – loggt sich früher oder später mit Benutzername und Passwort ein. Funktioniert ja auch erstmal. Aber ehrlich gesagt ist das wie eine Haustür, bei der das Schloss ein vierstelliger PIN ist. Geht, aber es geht besser.

Die Lösung: SSH-Keys. Klingt kompliziert, ist es aber nicht. Und nach diesem Artikel wirst du nie wieder Passwörter für Server-Logins eingeben wollen.

Was sind SSH-Keys überhaupt – und warum sind die sicherer?

Kurze Erklärung, versprochen.

Bei einem normalen Passwort-Login schickst du bei jedem Login dein Passwort übers Netz. Klar, verschlüsselt – aber das Passwort existiert als String, kann erraten werden, kann geleakt werden, kann durch Brute-Force geknackt werden.

SSH-Keys funktionieren anders. Du erzeugst ein Schlüsselpaar:

  • Private Key – bleibt auf deinem Rechner. Niemals weitergeben. Niemals.
  • Public Key – kommt auf den Server. Der kann ruhig öffentlich sein.

Das Prinzip: Der Server kennt deinen Public Key. Wenn du dich einloggst, muss dein Rechner beweisen, dass er den dazugehörigen Private Key hat – ohne den Key selbst zu übertragen. Das ist Mathematik, kein Passwort. Ein Angreifer bräuchte deinen Private Key direkt von deiner Festplatte – kein Brute-Force der Welt kommt da ran.

Schritt 1: Das Schlüsselpaar erstellen (auf deinem Windows-Rechner)

Öffne PowerShell und gib das ein:

ssh-keygen -t ed25519 -C "mein-homelab-key"

Was bedeutet das?

  • -t ed25519 – der Algorithmus. Ed25519 ist modern, schnell und sicher. Besser als das alte RSA.
  • -C – ein Kommentar. Hilft dir später, den Key zu identifizieren. Kannst du nennen wie du willst.

Du wirst nach ein paar Dingen gefragt:

„Enter file in which to save the key" Hier kannst du einfach Enter drücken für den Standardpfad – oder einen eigenen Namen angeben. Wichtig: Wenn du einen eigenen Namen verwendest, musst du das später beim SSH-Befehl angeben. Der Einfachheit halber empfehle ich: einfach den Standardnamen nehmen und Enter drücken.

C:\Users\DeinName\.ssh\id_ed25519

„Enter passphrase" Eine zusätzliche Passphrase für den Key selbst. Optional, aber empfohlen. Falls jemand an deinen Rechner kommt und die Key-Datei klaut, kommt er ohne Passphrase trotzdem nicht rein.

Nach dem Vorgang liegen zwei Dateien in C:\Users\DeinName\.ssh\:

  • id_ed25519 – dein privater Key. Nicht anfassen, nicht weiterschicken.
  • id_ed25519.pub – dein öffentlicher Key. Der kommt auf den Server.

Schritt 2: Den Public Key auf den Server kopieren

Jetzt müssen wir den Inhalt von id_ed25519.pub auf den Debian-Server in eine bestimmte Datei eintragen.

Zuerst den Inhalt anzeigen:

powershell

type C:\Users\DeinName\.ssh\id_ed25519.pub

Du siehst eine einzelne, lange Zeile die ungefähr so aussieht:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... mein-homelab-key

Diese komplette Zeile kopieren.

Jetzt per SSH auf den Server einloggen (noch mit Passwort, zum letzten Mal 😄) und:

bash

mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys

Die kopierte Zeile einfügen. Speichern mit Strg+O, Enter, dann Strg+X.

Dann noch die Berechtigungen setzen – das ist wichtig, sonst ignoriert SSH die Datei kommentarlos:

bash

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Warum diese Berechtigungen? SSH ist aus Sicherheitsgründen sehr pingelig. Wenn die Datei für andere Benutzer lesbar wäre, verweigert SSH den Key-Login komplett – ohne Fehlermeldung. Das Debugging macht dann keinen Spaß.

Schritt 3: Testen

Neue PowerShell öffnen und:

powershell

ssh user@server-ip

Wenn alles geklappt hat, loggst du dich ohne Passwort ein – oder wirst nur nach der Key-Passphrase gefragt (falls du eine gesetzt hast).

Falls es nicht klappt, hilft der Verbose-Modus:

powershell

ssh -v user@server-ip

Hier siehst du genau was passiert. Häufige Fehlerquellen:

  • identity file ... type -1 – der Key wurde nicht gefunden, weil du ihn anders benannt hast. Lösung: ssh -i C:\Users\DeinName\.ssh\DEIN-KEY-NAME user@server-ip
  • Passwort wird trotzdem abgefragt – meistens falsche Berechtigungen auf dem Server. Nochmal chmod 700 ~/.ssh und chmod 600 ~/.ssh/authorized_keys ausführen.

Schritt 4: Passwort-Login deaktivieren

Sobald der Key-Login funktioniert, kann der Passwort-Login komplett abgeschaltet werden. Damit entfällt die gesamte Angriffsfläche für Brute-Force-Attacken.

Auf dem Server:

bash

sudo nano /etc/ssh/sshd_config

Diese Zeile suchen und auf no setzen:

PasswordAuthentication no

Falls die Zeile mit einem # beginnt (also auskommentiert ist), das # einfach entfernen.

Dann SSH neu starten:

bash

sudo systemctl restart sshd

Bitte unbedingt: Die aktuelle SSH-Session offen lassen und in einem neuen Fenster testen ob der Login noch klappt. Erst wenn das funktioniert die alte Session schließen. Sonst sperrst du dich selbst aus – und das macht keinen Spaß um 23 Uhr.

Was, wenn ich meinen Key verliere?

Gute Frage. Denn wenn Passwort-Login aus ist und der Key weg ist: kein Zugang mehr.

Ein paar Absicherungen die ich empfehle:

Key-Backup anlegen Die Datei id_ed25519 (der private Key) irgendwo sicher ablegen. Ich nutze dafür Bitwarden – einfach den Inhalt der Datei in eine sichere Notiz kopieren. Im Notfall raus kopieren, als Datei speichern, fertig.

Zweiten Key eintragen Falls du von mehreren Geräten arbeitest: einfach von jedem Gerät einen Key generieren und alle Public Keys in ~/.ssh/authorized_keys eintragen – jeder in einer eigenen Zeile. Dann hast du mehrere unabhängige Zugangswege.

Notfallzugang kennen

  • Homelab/eigener Server: im Worst Case Monitor und Tastatur dran, Problem gelöst.
  • VPS/Cloud-Server: Anbieter wie Hetzner, Netcup oder IONOS haben alle eine Notfall-Konsole im Webinterface. Am besten einmal kurz raussuchen wo die ist – bevor man sie braucht.

Bonus-Tipp: SSH Config – nie wieder lange Befehle tippen

Wenn du mehrere Server hast, wird das schnell unübersichtlich.

Du kannst dir eine Config-Datei anlegen: C:\Users\DeinName\.ssh\config (einfach als Textdatei, keine Dateiendung).

Inhalt zum Beispiel:

Host homelab
    HostName 10.1.0.1
    User deinUser
    IdentityFile C:\Users\dein_Benutzer\.ssh\id_ed25519

Host vps-extern.de
    HostName 123.456.789.0
    User deinUser
    IdentityFile C:\Users\dein_Benutzer\.ssh\id_ed25519

Danach reicht einfach:

powershell

ssh homelab
ssh vps-extern.de

Für jeden Server einen Block, fertig. Gerade wenn man mehrere Maschinen betreibt ist das ein echter Komfortgewinn — und man muss sich keine IP-Adressen mehr merken.

Fazit

SSH-Keys sind keine Raketenwissenschaft. Einmal eingerichtet, loggst du dich bequemer ein als vorher – und der Server ist dabei deutlich sicherer. Kein Passwort das geleakt werden kann, kein Brute-Force der greift.

Gerade wenn du mehrere Server betreibst lohnt es sich, das von Anfang an sauber aufzusetzen. Der Aufwand ist überschaubar, der Gewinn an Sicherheit und Komfort ist es definitiv wert.

Einmal gemacht – läuft einfach.

Published by:

Sven Müller