SSH absichern und komfortabel nutzen

SSH absichern und komfortabel nutzen

SSH ist das wichtigste Werkzeug für die Fernwartung von Linux-Servern. Trotzdem läuft es auf vielen Systemen noch mit Standardkonfiguration: Passwort-Login aktiv, Root-Zugang offen, kein Schutz gegen Brute-Force. In diesem Beitrag zeige ich, wie man SSH sicher konfiguriert und gleichzeitig den täglichen Umgang komfortabler macht.

Die gezeigten Befehle und Pfade beziehen sich auf Debian-basierte Systeme (Debian, Ubuntu, Proxmox etc.). Auf anderen Distributionen können Pfade und Paketnamen abweichen.

Zusammenfassung

MaßnahmeWirkung
SSH-Keys statt PasswörterSchutz gegen Brute-Force und schwache Passwörter
SSH-Server härtenRoot-Login sperren, nur bestimmte Benutzer zulassen
SSH-Config nutzenKomfortabler Zugang ohne lange Befehle
Jump HostsSichere Erreichbarkeit interner Systeme
Mehrere Keys verwaltenTrennung nach Projekt und System
Fail2BanAutomatische Sperrung nach Fehlversuchen
Port ändernWeniger automatisierte Angriffe

Grundlagen: SSH-Keys statt Passwörter

Der erste und wichtigste Schritt: Passwort-Authentifizierung abschalten und stattdessen SSH-Keys verwenden.

Schlüsselpaar erzeugen

ssh-keygen -t ed25519 -C "jens@workstation"

Ed25519 ist aktuell der empfohlene Algorithmus: schnell, sicher und mit kurzen Schlüsseln. RSA funktioniert weiterhin, sollte dann aber mindestens 4096 Bit verwenden.

Öffentlichen Schlüssel übertragen

ssh-copy-id user@server

Alternativ manuell:

cat ~/.ssh/id_ed25519.pub | ssh user@server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

SSH-Server härten

Unter Debian liegt die Konfiguration des SSH-Servers in /etc/ssh/sshd_config. Nach Änderungen den Dienst neu laden:

sudo systemctl reload sshd

Empfohlene Einstellungen

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers jens deploy
X11Forwarding no

PermitRootLogin no verhindert direkte Root-Anmeldungen. Unter Debian ist sudo standardmäßig verfügbar, sodass man sich mit dem eigenen Benutzer anmeldet und bei Bedarf Root-Rechte erhält.

PasswordAuthentication no erzwingt Key-basierte Anmeldung. Vorher sicherstellen, dass der eigene Key funktioniert, sonst sperrt man sich aus.

AllowUsers beschränkt den Zugang auf bestimmte Benutzer. Alles andere wird abgelehnt, unabhängig davon ob ein gültiger Key vorliegt.


SSH-Config: Verbindungen komfortabel verwalten

Statt sich lange Hostnamen, Ports und Benutzernamen zu merken, kann man alles in ~/.ssh/config hinterlegen:

Host webserver
    HostName 192.168.1.10
    User jens
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
 
Host gitlab
    HostName gitlab.dunzweiler.me
    User git
    IdentityFile ~/.ssh/id_ed25519_gitlab
 
Host backup
    HostName 10.0.0.50
    User backup
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60

Danach reicht ein einfaches:

ssh webserver

Kein Tippen von IP-Adressen, Ports oder Benutzernamen mehr. Das funktioniert auch mit scp, rsync und git.


Jump Hosts: Zugang über Zwischenstationen

In vielen Netzwerken sind Server nicht direkt erreichbar, sondern nur über einen Bastion Host. SSH kann das transparent abbilden:

Per Kommandozeile

ssh -J jumphost zielserver

In der SSH-Config

Host jumphost
    HostName bastion.dunzweiler.me
    User jens
 
Host interner-server
    HostName 10.0.0.20
    User admin
    ProxyJump jumphost

Damit verbindet ssh interner-server automatisch über den Jump Host, ohne dass man den Zwischenschritt manuell ausführen muss.


Mehrere Keys verwalten

Bei mehreren Servern, Projekten oder Identitäten empfiehlt es sich, separate Schlüssel zu verwenden:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_gitlab -C "gitlab"
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_backup -C "backup"

In der SSH-Config wird dann pro Host der passende Key zugewiesen. So bleibt klar, welcher Schlüssel wo im Einsatz ist, und ein kompromittierter Key betrifft nicht alle Systeme.

SSH-Agent nutzen

Der SSH-Agent hält entschlüsselte Keys im Speicher, sodass die Passphrase nur einmal pro Session eingegeben werden muss:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Unter Linux-Desktops übernimmt das meist der Keyring automatisch.


Fail2Ban: Brute-Force-Schutz

Selbst mit deaktiviertem Passwort-Login erzeugen Brute-Force-Versuche unnötige Last und füllen die Logs. Fail2Ban sperrt IP-Adressen nach mehreren fehlgeschlagenen Anmeldeversuchen automatisch. Unter Debian ist es über die offiziellen Paketquellen verfügbar.

Installation

sudo apt install fail2ban

Konfiguration

Unter Debian liegt die Konfiguration in /etc/fail2ban/. Die Datei jail.conf nicht direkt bearbeiten, sondern eine lokale Überschreibung unter /etc/fail2ban/jail.local anlegen:

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log  # Debian-Pfad, unter RHEL/Fedora: /var/log/secure
maxretry = 3
bantime = 3600
findtime = 600

maxretry ist die Anzahl erlaubter Fehlversuche. bantime gibt die Sperrdauer in Sekunden an (hier eine Stunde). findtime definiert den Zeitraum, in dem die Fehlversuche gezählt werden.

Status prüfen

sudo fail2ban-client status sshd

Zeigt die Anzahl aktuell gesperrter IPs und die letzten Bans.


Port ändern (optional)

Den SSH-Port von 22 auf einen anderen Wert zu ändern ist kein Sicherheitsfeature im eigentlichen Sinne, reduziert aber das Grundrauschen in den Logs erheblich:

Port 2222

In der SSH-Config des Clients den Port entsprechend hinterlegen, dann bleibt der Zugang komfortabel.


Fazit

SSH richtig einzurichten kostet wenig Zeit und bringt viel Sicherheit. Die Kombination aus Key-Authentifizierung, gehärteter Konfiguration und Fail2Ban deckt die wichtigsten Angriffsvektoren ab. Mit einer gepflegten SSH-Config wird der tägliche Umgang zusätzlich deutlich angenehmer.