Einleitung

SSH-Zugriff gehört zu den grundlegenden administrativen Aufgaben auf Linux-Systemen. Trotzdem wird er in der Praxis oft unsauber eingerichtet: Root-Login per Passwort bleibt aktiv, private Schlüssel liegen versehentlich auf dem Server, oder alte PuTTY-/OpenSSH-Formate sorgen für vermeidbare Fehler.

Dieser Artikel zeigt, wie eine SSH-Key-Authentifizierung auf einem Debian-Node sauber eingerichtet, getestet und abgesichert wird. Die Beispiele sind anonymisiert.

Verwendete Platzhalter:

Hinweis: Die IP-Adresse 192.0.2.10 stammt aus einem Dokumentationsnetz und ist nicht produktiv nutzbar.

Zielbild

Am Ende soll Folgendes gelten:

• Der Debian-Node ist per SSH erreichbar.
• Die Anmeldung erfolgt per SSH-Key.
• Der private Schlüssel liegt ausschließlich auf dem Client.
• Auf dem Debian-Node liegt nur der öffentliche Schlüssel in authorized_keys.
• Passwort-Login wird nach erfolgreichem Test deaktiviert.
• Root-Zugriff wird entweder deaktiviert oder nur noch per Key erlaubt.

Voraussetzungen

Auf dem Debian-Node wird ein funktionierender Paketmanager benötigt. Außerdem sollte ein administrativer Zugang bestehen, zum Beispiel lokal, über bestehendes SSH oder über eine Konsole.

Auf dem Debian-Node:

apt update

Falls OpenSSH noch nicht installiert ist:

apt install openssh-server

systemctl enable --nowssh

systemctl status ssh--no-pager

Prüfen, ob der SSH-Dienst auf Port 22 lauscht:

ss -tlnp | grep':22'

Benutzer für den SSH-Zugriff vorbereiten

Es ist empfehlenswert, nicht dauerhaft direkt als root zu arbeiten, sondern einen normalen administrativen Benutzer zu verwenden.

adduser adminuser

Falls sudo genutzt werden soll:

apt install sudo

usermod -aGsudo adminuser

Danach muss sich der Benutzer einmal neu anmelden, damit die Gruppenmitgliedschaft aktiv wird.

Prüfen:

id adminuser

SSH-Key auf dem Client erzeugen

Der SSH-Key wird auf dem Client erzeugt, nicht auf dem Debian-Node.

Unter Windows kann dafür PowerShell genutzt werden:

ssh-keygen -ted25519 -a100 -f C:\Users\user\.ssh\id_ed25519_debian_node

Dabei entstehen zwei Dateien:

C:\Users\user\.ssh\id_ed25519_debian_node privater Schlüssel

C:\Users\user\.ssh\id_ed25519_debian_node.pub öffentlicher Schlüssel

Der private Schlüssel bleibt auf dem Client. Er wird nicht auf den Server kopiert.

Public Key auf den Debian-Node übertragen

Wenn ssh-copy-id auf dem Client verfügbar ist, kann der öffentliche Schlüssel direkt übertragen werden:

ssh-copy-id -i ~/.ssh/id_ed25519_debian_node.pub adminuser@192.0.2.10

Unter Windows ist ssh-copy-id häufig nicht vorhanden. Dann wird der Inhalt der .pub-Datei manuell übertragen.

Auf dem Windows-Client:

type C:\Users\user\.ssh\id_ed25519_debian_node.pub

Die Ausgabe beginnt typischerweise mit:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA…

Auf dem Debian-Node als Zielbenutzer:

mkdir-p ~/.ssh

chmod700 ~/.ssh

nano ~/.ssh/authorized_keys

Den öffentlichen Schlüssel in authorized_keys einfügen und speichern.

Danach Rechte setzen:

chmod600 ~/.ssh/authorized_keys

Wenn die Datei als root für einen anderen Benutzer vorbereitet wurde:

chown-R adminuser:adminuser /home/adminuser/.ssh

Anmeldung per SSH-Key testen

Vom Client aus:

ssh -iC:\Users\user\.ssh\id_ed25519_debian_nodeadminuser@192.0.2.10

Nach erfolgreichem Login prüfen:

whoami

hostname

Erwartung:

adminuser

debian-node

SSH-Config auf dem Windows-Client vereinfachen

Damit nicht jedes Mal der komplette Befehl eingegeben werden muss, kann eine SSH-Config angelegt werden.

Datei:

C:\Users\user\.ssh\config

Inhalt:

Host debian-node

HostName 192.0.2.10

User adminuser

IdentityFile C:\Users\user\.ssh\id_ed25519_debian_node

IdentitiesOnly yes

Danach genügt:

sshdebian-node

Screenshot 6: SSH-Config mit Host-Alias
Dateiname-Vorschlag: 06-windows-ssh-config.png

Sonderfall: PuTTY und OpenSSH-Keyformat

Bei PuTTY kann folgende Meldung auftreten:

Unable to use key file „C:\Users\user\Documents\id_ed25519_debian_node“

(OpenSSH SSH-2 private key (new format))

Ursache: PuTTY erwartet je nach Version ein .ppk-Format oder kann den OpenSSH-Key nicht direkt verwenden.

Lösung:

1. PuTTYgen starten.
2. Load auswählen.
3. Dateityp auf All Files (*.*) stellen.
4. OpenSSH-Key laden.
5. Als .ppk speichern.
6. In PuTTY unter Connection > SSH > Auth > Credentials den .ppk-Key auswählen.

Alternativ kann unter Windows direkt OpenSSH genutzt werden:

ssh -iC:\Users\user\.ssh\id_ed25519_debian_nodeadminuser@192.0.2.10

Screenshot 7: PuTTYgen-Konvertierung nach .ppk
Dateiname-Vorschlag: 07-puttygen-ppk-conversion.png

SSH-Server absichern

Erst wenn der Key-Login erfolgreich getestet wurde, sollte der SSH-Server gehärtet werden. Wichtig: Eine bestehende SSH-Sitzung offen lassen und in einem zweiten Fenster testen.

Konfiguration öffnen:

nano /etc/ssh/sshd_config

Empfohlene Einstellungen:

PubkeyAuthentication yes

PasswordAuthentication no

KbdInteractiveAuthentication no

PermitRootLogin prohibit-password

UsePAM yes

Bedeutung:

Konfiguration testen:

sshd -t

Wenn keine Ausgabe erscheint, ist die Syntax gültig.

SSH neu laden:

systemctl reload ssh

Dann in einem zweiten Terminal testen:

sshdebian-node

Screenshot 8: SSH-Konfiguration erfolgreich getestet
Dateiname-Vorschlag: 08-sshd-config-test.png

Private Keys auf dem Node finden und entfernen

Ein häufiger Fehler ist, den privaten SSH-Key versehentlich auf den Server zu kopieren. Auf dem Debian-Node sollten normalerweise nur Public Keys in authorized_keys liegen.

Private Keys erkennen:

—–BEGIN OPENSSH PRIVATE KEY—–

Public Keys erkennen:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA…

Auf dem Debian-Node nach SSH-Key-Dateien suchen:

find /root /home -type f \( \

-name’authorized_keys‘-o \

-name’id_rsa*‘-o \

-name’id_ed25519*‘-o \

-name’id_ecdsa*‘-o \

-name’*.ppk‘ \

\) -ls2>/dev/null

Übersichtlicher:

find /root /home -type f \( \

-name’authorized_keys‘-o \

-name’id_*‘-o \

-name’*.ppk‘ \

\) 2>/dev/null

Erste Zeile prüfen, ohne komplette Schlüssel offenzulegen:

find /root /home -type f -name’id_*‘-execsh-c’echo „### $1“; head -n 1 „$1″‚ _ {} \; 2>/dev/null

Verdächtige private Keys auf dem Server löschen:

rm-f /pfad/zum/private-key

Nicht löschen:

/root/.ssh/authorized_keys

/home/adminuser/.ssh/authorized_keys

Diese Dateien enthalten öffentliche Schlüssel und sind für den Login erforderlich.

Screenshot 9: Suche nach versehentlich abgelegten privaten SSH-Keys
Dateiname-Vorschlag: 09-find-private-keys-on-node.png

Empfohlene Zielstruktur

Auf dem Client:

C:\Users\user\.ssh\id_ed25519_debian_node privater Schlüssel

C:\Users\user\.ssh\id_ed25519_debian_node.pub öffentlicher Schlüssel

C:\Users\user\.ssh\config SSH-Client-Konfiguration

Auf dem Debian-Node:

/home/adminuser/.ssh/authorized_keys erlaubte Public Keys

Nicht auf dem Debian-Node:

id_ed25519_debian_node

id_ed25519_debian_node.ppk

id_rsa

id_ecdsa

Troubleshooting

Key wird ignoriert

Client-seitig Debug aktivieren:

ssh -vvv -iC:\Users\user\.ssh\id_ed25519_debian_nodeadminuser@192.0.2.10

Server-seitig Logs prüfen:

journalctl -ussh-n100--no-pager

Rechte auf dem Server prüfen

ls-ld /home/adminuser

ls-ld /home/adminuser/.ssh

ls-l /home/adminuser/.ssh/authorized_keys

Empfohlene Rechte:

/home/adminuser/.ssh 700

/home/adminuser/.ssh/authorized_keys 600

Falscher Benutzer

Wenn der Public Key unter /home/adminuser/.ssh/authorized_keys liegt, muss auch als adminuser verbunden werden:

sshadminuser@192.0.2.10

Nicht versehentlich:

sshroot@192.0.2.10

PuTTY-Keyformat passt nicht

Wenn PuTTY den OpenSSH-Key nicht laden kann, den privaten Schlüssel mit PuTTYgen nach .ppk konvertieren oder direkt Windows OpenSSH verwenden.

Fazit

Eine saubere SSH-Key-Authentifizierung besteht nicht nur daraus, einen Schlüssel zu erzeugen. Entscheidend ist die Trennung der Rollen:

• Der private Key bleibt ausschließlich auf dem Client.
• Der Debian-Node enthält nur den Public Key in authorized_keys.
• Passwort-Logins werden erst nach erfolgreichem Key-Test deaktiviert.
• Root-Zugriff wird bewusst eingeschränkt.
• Die Konfiguration wird vor dem Neuladen mit sshd -t geprüft.

Damit ist der SSH-Zugriff wartbar, nachvollziehbar und deutlich sicherer als eine reine Passwortanmeldung.