LinuxShellSite

Debian & Ubuntu | SSH-Authentifizierung auf Public-Key umstellen

Passwortbasierte SSH-Logins sind der primäre Angriffsvektor für Brute-Force-Attacken auf Linux-Server. Sobald Port 22 offen ist, hämmern Bots gegen die Authentifizierung. Die einzig nachhaltige Architektur-Entscheidung ist die Deaktivierung von Passwörtern zugunsten asymmetrischer Kryptographie (Public-Key-Verfahren).

In diesem Guide konfigurieren wir einen Debian Server so, dass der Login ausschließlich über ein kryptographisches Schlüsselpaar erfolgt. Wir nutzen hierbei den Workflow der serverseitigen Generierung und des Imports in den Windows-Client (PuTTY).

Schlüsselpaar generieren

Wir beginnen direkt auf dem Server. Hier erzeugen wir ein RSA-Schlüsselpaar mit einer Bitlänge von 4096. Diese Länge ist notwendig, um auch langfristig gegen Faktorisierungsangriffe resistent zu bleiben (Standard 2048 Bit gilt inzwischen als Minimum, 4096 als zukunftssicher).

Logge dich als der User ein, den du absichern willst (hier: root) und führe folgenden Befehl aus:

ssh-keygen -t rsa -b 4096

Das Tool fragt nach dem Speicherort und einer Passphrase.

  • Speicherort: Bestätige den Standard (/home/user/.ssh/id_rsa).
  • Passphrase: Hier definierst du ein Passwort, das den privaten Schlüssel lokal verschlüsselt. Sollte dein Private Key gestohlen werden, ist er ohne diese Passphrase wertlos. Setze hier zwingend ein starkes Passwort.

Die Ausgabe bestätigt die Erstellung des Fingerprints und des Randomart-Images.

grafik 50

Überprüfe die Erstellung der Dateien:

ls -l ~/.ssh/
  • id_rsa: Private Key. Er ist dein Identitätsnachweis. Er darf niemals in fremde Hände gelangen.
  • id_rsa.pub: Public Key. Dieser wird auf dem Server hinterlegt und darf öffentlich bekannt sein.
grafik 51

Public Key autorisieren

Damit der SSH-Daemon (sshd) den Schlüssel akzeptiert, muss der Inhalt des Public Keys in die Datei authorized_keys geschrieben werden. Der Daemon prüft beim Login, ob der Client den passenden privaten Schlüssel zu einem der hier gelisteten öffentlichen Schlüssel besitzt.

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Wichtig: SSH ist extrem strikt bei Dateiberechtigungen. Wenn die Datei authorized_keys oder der Ordner .ssh für andere User schreibbar ist, verweigert der Daemon aus Sicherheitsgründen den Dienst (Strict Modes). Wir setzen die Rechte daher restriktiv:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
  • 700: Nur der Besitzer darf das Verzeichnis öffnen.
  • 600: Nur der Besitzer darf die Datei lesen/schreiben.
grafik 52

Privaten Schlüssel auf den Client transferieren

Da wir das Schlüsselpaar auf dem Server generiert haben (Server-Side Generation), müssen wir nun den Private Key (id_rsa) sicher auf den Windows-Client bringen.

Nutze hierfür WinSCP oder einen ähnlichen SCP-Client.

  1. Verbinde dich mit deinem Server.
  2. Navigiere zu /home/[BENUTZER]/.ssh/. (Falls der Ordner unsichtbar ist: STRG + ALT + H in WinSCP).
  3. Lade die Datei id_rsa auf deinen lokalen Windows-PC herunter.

Architect-Note: Behandle die Datei id_rsa wie deine Kreditkartendaten. Lösche sie nach dem Transfer idealerweise vom Server, damit dort nur noch der Public Key liegt.

grafik 62

SSH-Daemon härten (Passwörter deaktivieren)

Solange die Passwort-Authentifizierung aktiv ist, bringt der Schlüssel keinen Sicherheitsgewinn gegen Brute-Force. Wir konfigurieren den Daemon nun so, dass er nur noch Schlüssel akzeptiert.

Öffne die Konfiguration:

sudo nano /etc/ssh/sshd_config

Suche und ändere (bzw. entkommentiere) folgende Parameter. Das Deaktivieren des Root-Logins ist eine zusätzliche „Defense-in-Depth“-Maßnahme, da der User „root“ auf jedem System existiert und daher ein beliebtes Ziel ist.

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no

Speichere die Datei (STRG+O, Enter) und schließe sie (STRG+X).

Damit die Änderungen greifen, muss der Dienst die Config neu einlesen. Bestehende Verbindungen werden dabei nicht getrennt, aber teste den Zugriff in einem neuen Terminal-Fenster, bevor du das aktuelle schließt.

sudo systemctl restart ssh.service
grafik 60
grafik 61

Client-Konfiguration mit PuTTY

Wenn du PuTTY für den Verbindungsaufbau nutzt, beachte bitte, dass dieses Tool eigene Schlüsselformate benötigt. Der erstellte OpenSSH-Key (id_rsa) ist nicht kompatibel und muss zuerst in das PuTTY-Format (.ppk) umgewandelt werden.

Verwendest du hingegen die PowerShell, kannst du den Private Key direkt im Originalformat nutzen, so wie er erstellt wurde.

– Konvertierung mit PuTTYgen

PuTTY Key Generator
  • Starte den PuTTY Key Generator (PuTTYgen).
  • Klicke auf Load und wähle im Dateifilter „All Files (*)“.
  • Wähle deine heruntergeladene id_rsa Datei aus.
  • Gib deine Passphrase ein (sofern in Schritt 1 vergeben).
load private key

Das Tool hat den Schlüssel nun importiert. Speichere ihn im PuTTY-Format:

  • Speichere die Datei als private_key.ppk.
  • Klicke auf Save private key.
Save private key
grafik 56

– Verbindungsaufbau mit PuTTy

grafik 58

Jetzt konfigurieren wir die Session in PuTTY.

  • Öffne PuTTY.
  • Navigiere im Baummenü links zu:
    Connection -> SSH -> Auth -> Credentials.
  • Wähle bei „Private key file for authentication“ deine eben erstellte .ppk-Datei aus.
grafik 59
  • Gehe zurück auf Session, trage IP und Port ein und speichere die Session optional ab.
  • Klicke auf Open und wenn es die erste Verbindung ist, bestätige mit yes den Fingerprint.
grafik 57

Verbindungsaufbau | Die Passwortabfrage des Servers entfällt. Stattdessen wird der SSH-Key genutzt.

Lediglich bei geschützten Keys musst du nun deren Passphrase eingeben (lokale Entschlüsselung).

– Verbindungsaufbau mit PowerShell

grafik 63

Anstatt PuTTY zu installieren, kannst du auf aktuellen Windows-Systemen den integrierten SSH-Client nutzen. Der große Vorteil: Dein id_rsa-Schlüssel funktioniert hier sofort, eine Konvertierung entfällt.

Verwende dazu einfach folgenden Befehl in der PowerShell:

ssh -i .\id_rsa USERNAME@IP des SERVERS

Fehlerbehebung: Dateiberechtigungen

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for 'id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "id_rsa": bad permissions
USERNAME@xxx.xxx.xxx.xxx: Permission denied (publickey).

Falls diese Fehlermeldung erscheint, sind die Berechtigungen deiner Private-Key-Datei nicht restriktiv genug gesetzt. Du hast zwei Möglichkeiten, dies zu beheben:

  • Option A (Einfach): Verschiebe die Key-Datei in deinen Ordner Dokumente. Durch die Windows-Rechtevererbung erhält die Datei dort automatisch die korrekten Berechtigungen.
  • Option B (Manuell): Ändere die Sicherheitseinstellungen der Datei händisch. Stelle sicher, dass dein aktueller Windows-Benutzer als Besitzer eingetragen ist und Vollzugriff besitzt. Alle anderen Benutzer sollten entfernt werden.

Fazit & Sicherheitseinschätzung

Durch diese Umstellung hast du die Angriffsoberfläche deines Debian-Servers massiv reduziert. Automatisierte Skripte, die Passwortlisten gegen deinen Port 22 testen, laufen nun ins Leere („Permission denied“).

Wichtige Sicherheits-Hinweise:

  1. Backup: Verliere niemals deinen Private Key. Da PasswordAuthentication auf no steht, sperrst du dich ohne Key permanent aus dem System aus (es sei denn, du hast Konsolenzugriff über den Hoster).
  2. Key-Management: Generiere idealerweise für jedes Gerät einen eigenen Key. Sollte ein Laptop gestohlen werden, musst du nur dessen spezifischen Public Key auf dem Server aus der authorized_keys entfernen, ohne alle anderen Zugänge neu konfigurieren zu müssen.

This post is also available in: Deutsch English