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ßnahme | Wirkung |
|---|---|
| SSH-Keys statt Passwörter | Schutz gegen Brute-Force und schwache Passwörter |
| SSH-Server härten | Root-Login sperren, nur bestimmte Benutzer zulassen |
| SSH-Config nutzen | Komfortabler Zugang ohne lange Befehle |
| Jump Hosts | Sichere Erreichbarkeit interner Systeme |
| Mehrere Keys verwalten | Trennung nach Projekt und System |
| Fail2Ban | Automatische Sperrung nach Fehlversuchen |
| Port ändern | Weniger 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@serverAlternativ 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 sshdEmpfohlene Einstellungen
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers jens deploy
X11Forwarding noPermitRootLogin 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 60Danach reicht ein einfaches:
ssh webserverKein 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 zielserverIn der SSH-Config
Host jumphost
HostName bastion.dunzweiler.me
User jens
Host interner-server
HostName 10.0.0.20
User admin
ProxyJump jumphostDamit 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_ed25519Unter 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 fail2banKonfiguration
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 = 600maxretry 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 sshdZeigt 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 2222In 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.