Schritt-für-Schritt-Anleitung zur sicheren SSH-Schlüsselauthentifizierung

SSH-Schlüsselauthentifizierung schützt Ihren Server vor vielen passwortbasierten Angriffen, aber nur, wenn Sie den Schlüssel sorgfältig generieren, den öffentlichen Schlüssel korrekt installieren und den Zugriff testen, bevor Sie Servereinstellungen ändern.

Diese Anleitung führt Sie durch die ED25519-Schlüsselgenerierung, die Installation des öffentlichen Schlüssels, das Testen des Logins und sicherere SSH-Daemon-Einstellungen.

Grundlegendes zur SSH-Schlüsselauthentifizierung

Die SSH-Schlüsselauthentifizierung basiert auf einem Paar kryptografisch verknüpfter Schlüssel: einem privaten Schlüssel und einem öffentlichen Schlüssel.

Privater Schlüssel: Dieser Schlüssel muss geheim bleiben und auf Ihrem lokalen Rechner gesichert sein. Er ist wie ein hochkomplexes Passwort, das nur Sie besitzen.
Öffentlicher Schlüssel: Dieser Schlüssel kann frei geteilt werden und wird auf dem entfernten Server platziert, auf den Sie zugreifen möchten. Er wird vom Server verwendet, um Ihre Identität zu überprüfen.

Wenn Sie versuchen, eine Verbindung herzustellen, verwendet der Server Ihren öffentlichen Schlüssel, um Ihren lokalen Rechner herauszufordern. Ihr lokaler Rechner verwendet dann seinen privaten Schlüssel, um auf diese Herausforderung zu antworten und Ihre Identität nachzuweisen, ohne den privaten Schlüssel jemals über das Netzwerk zu senden. Diese Methode ist nicht nur sicherer, sondern auch bequemer, da sie nach korrekter Konfiguration die Eingabe eines Passworts für jede Verbindung überflüssig macht.

Schritt 1: Generieren Ihres SSH-Schlüsselpaares

Das Dienstprogramm ssh-keygen wird verwendet, um neue SSH-Schlüsselpaare zu erstellen. Es wird empfohlen, moderne, starke Algorithmen wie ED25519 zu verwenden.

Wählen Sie einen Schlüsseltyp und eine Stärke

Während RSA-Schlüssel immer noch weit verbreitet sind, bietet ED25519 hervorragende Sicherheit mit kürzeren Schlüssellängen und schnelleren Operationen. Für neue Einrichtungen wird ED25519 im Allgemeinen bevorzugt.

Generieren Sie das Schlüsselpaar

Öffnen Sie auf Ihrem lokalen Rechner (Client) Ihr Terminal und führen Sie den folgenden Befehl aus:

ssh-keygen -t ed25519 -C "[email protected]"

-t ed25519: Gibt den Schlüsseltyp als ED25519 an.
-C "[email protected]": Fügt dem öffentlichen Schlüssel einen Kommentar hinzu, der oft zur Identifikation verwendet wird. Ersetzen Sie dies durch Ihre tatsächliche E-Mail oder eine beschreibende Bezeichnung.

Der Befehl fordert Sie zur Eingabe eines Speicherorts für den Schlüssel und einer optionalen Passphrase auf.

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/youruser/.ssh/id_ed25519): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/youruser/.ssh/id_ed25519
Your public key has been saved in /home/youruser/.ssh/id_ed25519.pub
The key fingerprint is: SHA256:...
The key's randomart image is: ...

Legen Sie eine starke Passphrase fest (dringend empfohlen)

Legen Sie bei Aufforderung immer eine starke Passphrase für Ihren privaten Schlüssel fest. Diese Passphrase verschlüsselt Ihren privaten Schlüssel auf Ihrem lokalen Rechner und bietet eine zusätzliche Sicherheitsebene. Sollte Ihr privater Schlüssel jemals in falsche Hände geraten, ist er ohne die Passphrase nutzlos. Sie können ssh-agent verwenden, um die wiederholte Eingabe der Passphrase zu vermeiden (siehe Schritt 4).

Speicherorte der Schlüsseldateien

Standardmäßig speichert ssh-keygen Ihren privaten Schlüssel unter ~/.ssh/id_ed25519 und Ihren öffentlichen Schlüssel unter ~/.ssh/id_ed25519.pub.

Berechtigungen für Ihren privaten Schlüssel

Es ist entscheidend, dass Ihre private Schlüsseldatei sehr strenge Berechtigungen hat. Nur der Eigentümer sollte sie lesen können. ssh-keygen setzt dies normalerweise korrekt, aber es ist gut, dies zu überprüfen:

chmod 600 ~/.ssh/id_ed25519

Schritt 2: Verteilen Ihres öffentlichen Schlüssels auf dem Server

Sobald Sie Ihr Schlüsselpaar generiert haben, muss Ihr öffentlicher Schlüssel auf den entfernten Server kopiert werden, auf den Sie zugreifen möchten. Er sollte in einer Datei namens authorized_keys im Verzeichnis ~/.ssh/ Ihres Benutzers auf dem entfernten Server platziert werden.

Methode 1: Verwenden von `ssh-copy-id` (empfohlen)

ssh-copy-id ist die einfachste und sicherste Methode. Es meldet sich auf dem entfernten Server an (mit Ihrem Passwort), erstellt das Verzeichnis ~/.ssh, falls es nicht existiert, setzt die korrekten Berechtigungen und hängt Ihren öffentlichen Schlüssel an ~/.ssh/authorized_keys an.

ssh-copy-id user@your_server_ip

Ersetzen Sie user durch Ihren Benutzernamen auf dem entfernten Server und your_server_ip durch die IP-Adresse oder den Hostnamen des Servers. Sie werden nach Ihrem Passwort auf dem entfernten Server gefragt.

Methode 2: Manuelles Kopieren

Wenn ssh-copy-id nicht verfügbar ist, können Sie den öffentlichen Schlüssel manuell kopieren.

Kopieren Sie den Inhalt des öffentlichen Schlüssels von Ihrem lokalen Rechner:
```
cat ~/.ssh/id_ed25519.pub
```
Kopieren Sie die gesamte Ausgabe in Ihre Zwischenablage (sie beginnt mit ssh-ed25519 ...).
Melden Sie sich mit Ihrem Passwort auf dem entfernten Server an:
```
ssh user@your_server_ip
```
Erstellen Sie das Verzeichnis ~/.ssh, falls es nicht existiert, und setzen Sie die Berechtigungen:
```
mkdir -p ~/.ssh
chmod 700 ~/.ssh
```
Hängen Sie Ihren öffentlichen Schlüssel an authorized_keys an:
```
echo "PASTE_YOUR_PUBLIC_KEY_HERE" >> ~/.ssh/authorized_keys
```
Stellen Sie sicher, dass Sie PASTE_YOUR_PUBLIC_KEY_HERE durch den tatsächlichen Inhalt ersetzen, den Sie kopiert haben. Die Verwendung von >> (anhängen) ist wichtig, um vorhandene Schlüssel nicht zu überschreiben, falls welche vorhanden sind.
Setzen Sie die korrekten Berechtigungen für authorized_keys:
```
chmod 600 ~/.ssh/authorized_keys
```
- Warnung: Falsche Berechtigungen für ~/.ssh oder ~/.ssh/authorized_keys verhindern, dass die schlüsselbasierte Authentifizierung funktioniert.

Schritt 3: Testen Sie Ihre SSH-Schlüsselauthentifizierung

Bevor Sie die Passwortauthentifizierung deaktivieren, ist es absolut kritisch zu überprüfen, ob die schlüsselbasierte Authentifizierung korrekt funktioniert. Melden Sie sich vom entfernten Server ab, falls Sie noch von den manuellen Kopierschritten verbunden sind.

Versuchen Sie von Ihrem lokalen Rechner aus, eine Verbindung zum Server herzustellen, ohne ein Passwort anzugeben:

ssh user@your_server_ip

Wenn Sie eine Passphrase für Ihren privaten Schlüssel festgelegt haben, werden Sie aufgefordert, diese einzugeben.
Wenn die Verbindung ohne Passwortaufforderung (nach der Passphrase, falls zutreffend) erfolgreich ist, funktioniert Ihre schlüsselbasierte Authentifizierung. Sie sollten die Eingabeaufforderung des entfernten Servers sehen.

Fahren Sie NICHT mit Schritt 4 fort, wenn Sie sich nicht mit Ihrem SSH-Schlüssel anmelden können. Beheben Sie alle Probleme, bevor Sie die Passwortauthentifizierung deaktivieren, da Sie sich sonst vom Server ausschließen könnten.

Schritt 4: Erhöhung der Sicherheit – Deaktivieren der Passwortauthentifizierung

Sobald Sie bestätigt haben, dass die SSH-Schlüsselauthentifizierung funktioniert, können Sie die passwortbasierten Logins auf Ihrem Server deaktivieren, um die Sicherheit erheblich zu verbessern. Dies verhindert Brute-Force-Angriffe auf Ihr Passwort und stellt sicher, dass nur Personen mit gültigen SSH-Schlüsseln auf den Server zugreifen können.

Melden Sie sich mit Ihrem SSH-Schlüssel auf Ihrem entfernten Server an.
```
ssh user@your_server_ip
```
Bearbeiten Sie die Konfigurationsdatei des SSH-Daemons. Diese Datei befindet sich normalerweise unter /etc/ssh/sshd_config.
```
sudo nano /etc/ssh/sshd_config
```
(Sie können vi oder Ihren bevorzugten Texteditor anstelle von nano verwenden.)
Suchen und ändern Sie die folgenden Direktiven:
- Suchen Sie PasswordAuthentication und ändern Sie den Wert auf no.
```
#PasswordAuthentication yes
PasswordAuthentication no
```
  (Entfernen Sie das Kommentarzeichen #, falls die Zeile auskommentiert ist)
- Suchen Sie KbdInteractiveAuthentication und ändern Sie den Wert auf no. Bei älteren OpenSSH-Versionen kann die entsprechende Direktive ChallengeResponseAuthentication sein.
```
KbdInteractiveAuthentication no
```
- (Optional, aber empfohlen) Erwägen Sie, das direkte Root-Login über SSH zu deaktivieren, wenn Sie nach dem Einloggen als normaler Benutzer sudo verwenden möchten.
```
PermitRootLogin no
```
- (Optional) Erwägen Sie, den Standard-SSH-Port von 22 auf einen nicht standardmäßigen hohen Port (z. B. 2222) zu ändern. Dies erhöht nicht die Sicherheit gegen gezielte Angriffe, kann aber das Rauschen von automatischen Port-Scannern reduzieren.
```
#Port 22
Port 2222
```
  Wenn Sie den Port ändern, denken Sie daran, ihn beim Verbinden mit dem Flag -p anzugeben (z. B. ssh -p 2222 user@your_server_ip).
Speichern Sie die Änderungen und beenden Sie den Texteditor.
Starten Sie den SSH-Dienst neu, um die neue Konfiguration zu übernehmen. Der Befehl variiert je nach Betriebssystem (z. B. Ubuntu/Debian vs. CentOS/RHEL).
- Systemd-basierte Systeme (die meisten modernen Linux-Distributionen):
```
sudo sshd -t
sudo systemctl restart sshd
```
- Ältere SysVinit-basierte Systeme:
```
sudo service ssh restart
```
Öffnen Sie unbedingt ein neues Terminalfenster (schließen Sie Ihre aktuelle aktive SSH-Sitzung nicht!) und versuchen Sie, sich mit Ihrem Schlüssel anzumelden. Dies testet die neue Konfiguration, ohne sich auszuschließen, falls etwas schiefgeht.
```
ssh user@your_server_ip
```
Wenn Sie den Port geändert haben:
```
ssh -p 2222 user@your_server_ip
```
Wenn die Verbindung erfolgreich ist, können Sie jetzt Ihre ursprüngliche SSH-Sitzung sicher schließen.

Wenn der neue Login fehlschlägt, machen Sie die Änderungen in sshd_config in Ihrer ursprünglichen, noch aktiven SSH-Sitzung sofort rückgängig und starten Sie den SSH-Dienst erneut, und bewerten Sie dann die Situation neu.

Best Practices und Tipps

Verwenden Sie immer eine starke Passphrase für Ihren privaten Schlüssel. Dies ist Ihre letzte Verteidigungslinie, falls Ihr privater Schlüssel kompromittiert wird.
Schützen Sie Ihren privaten Schlüssel. Geben Sie ihn niemals weiter und stellen Sie sicher, dass er sicher mit strengen Dateiberechtigungen gespeichert ist (chmod 600 ~/.ssh/id_ed25519). Erwägen Sie Hardware-Sicherheitsmodule (HSMs) oder YubiKeys für ultimativen Schutz.
Verwenden Sie ssh-agent für mehr Komfort. ssh-agent ermöglicht es Ihnen, Ihren privaten Schlüssel in den Speicher zu laden und Ihre Passphrase nur einmal pro Sitzung einzugeben, selbst über mehrere SSH-Verbindungen hinweg. Fügen Sie Ihren Schlüssel mit ssh-add ~/.ssh/id_ed25519 zum Agenten hinzu.
Rotieren Sie Ihre SSH-Schlüssel regelmäßig. Generieren Sie regelmäßig neue Schlüsselpaare und entfernen Sie alte öffentliche Schlüssel von Ihren Servern, insbesondere wenn ein Teammitglied das Unternehmen verlässt oder die Sicherheit eines Schlüssels vermutet wird.
Setzen Sie PermitRootLogin auf no oder prohibit-password. Es ist im Allgemeinen besser, sich als normaler Benutzer anzumelden und sudo für administrative Aufgaben zu verwenden.
Konfigurieren Sie eine Firewall. Stellen Sie sicher, dass nur notwendige Ports (wie Ihr SSH-Port) für das Internet geöffnet sind. Tools wie ufw oder firewalld können dabei helfen.

Abschließende Erkenntnisse

Ihr privater Schlüssel ist jetzt Ihre wichtigste Login-Anmeldeinformation. Schützen Sie ihn daher mit einer Passphrase und strengen Dateiberechtigungen. Halten Sie eine getestete SSH-Sitzung offen, während Sie sshd_config ändern, validieren Sie die Konfiguration mit sshd -t, und schließen Sie die alte Sitzung erst, nachdem ein neuer schlüsselbasierter Login funktioniert.