SSH: Sicherer Fernzugriff

SSH – Secure Shell ist das wichtigste Protokoll für den sicheren Fernzugriff auf Linux- und Unix-Server. Es ersetzt die unsicheren Vorgänger Telnet und rsh, die Befehle und Passwörter im Klartext übertragen haben. Mit SSH baust du eine verschlüsselte Verbindung zur Kommandozeile eines entfernten Rechners auf – als wärst du direkt davor. Als IT-Fachkraft wirst du SSH täglich nutzen: zum Verwalten von Servern, zum Übertragen von Dateien via SFTP, zum Einrichten von Tunneln und in automatisierten Deployments.

SSH läuft standardmäßig auf Port 22 und nutzt ein asymmetrisches Schlüsselpaar für die Authentifizierung – du hast einen privaten Schlüssel (bleibt bei dir) und einen öffentlichen Schlüssel (wird auf dem Server hinterlegt). Das Grundprinzip der Kryptografie dahinter erklärt Kurs K08 – Verschlüsselung und Kryptografie.

1) SSH-Verbindung aufbauen

Der einfachste SSH-Befehl verbindet dich mit Benutzername und Passwort zu einem entfernten Server. In der Praxis – und für Automatisierungen – nutzt man stattdessen SSH-Schlüssel, weil sie sicherer und bequemer sind. Die folgende Simulation zeigt beide Wege.

SSH-Verbindung – Passwort und Key-Authentifizierung

Verbindung mit Passwort-Authentifizierung

# Grundsyntax: ssh benutzer@host $ ssh max@192.168.1.50 The authenticity of host '192.168.1.50' can't be established. ED25519 key fingerprint is SHA256:abc123xyz... Are you sure you want to continue connecting? yes Warning: Permanently added '192.168.1.50' to known_hosts. max@192.168.1.50's password: **** Welcome to Ubuntu 24.04 LTS max@ubuntu-srv:~$ # jetzt auf dem entfernten Server

Beim ersten Verbinden wird der Fingerprint des Server-Schlüssels angezeigt – du solltest ihn verifizieren. Er wird in ~/.ssh/known_hosts gespeichert. Ändert sich der Schlüssel beim nächsten Verbinden, warnt SSH vor einem möglichen Man-in-the-Middle-Angriff.

SSH-Schlüsselpaar generieren

2) Passwort vs. SSH-Key – der Vergleich

Für die IHK wird häufig gefragt, welche Authentifizierungsmethode sicherer ist und warum. SSH-Keys sind dem Passwort in fast allen Punkten überlegen – insbesondere für Server-Administration und Automatisierung.

Passwort-Authentifizierung

Einfach einzurichten
Anfällig für Brute-Force
Passwort wird über Netzwerk gesendet (verschlüsselt)
Passwort-Wiederverwendung ein Risiko
Phishing möglich
Keine Automatisierung ohne gespeichertes PW

SSH-Key-Authentifizierung

Sicherer durch asymmetrische Kryptografie
Kein Passwort über das Netzwerk
Kein Brute-Force möglich
Ideal für Automatisierung (kein interaktiver Login)
Verschiedene Keys für verschiedene Server
Revocation einfach (Key aus authorized_keys löschen)

3) SSH-Server konfigurieren und absichern

Die Konfigurationsdatei des SSH-Servers (/etc/ssh/sshd_config) enthält zahlreiche Sicherheitseinstellungen. In der Praxis sind folgende Anpassungen Standard, um einen SSH-Server gegen Angriffe zu härten.

SSH-Serverkonfiguration härten

# /etc/ssh/sshd_config – wichtige Sicherheitseinstellungen Port 22 # ggf. ändern (Security through Obscurity) PermitRootLogin no # Root-Login verbieten! PasswordAuthentication no # nur Key-Auth erlauben PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys MaxAuthTries 3 # max. 3 Versuche LoginGraceTime 30 # 30 Sekunden für Login-Versuch AllowUsers max deploy # nur diese User dürfen sich einloggen X11Forwarding no # GUI-Forwarding deaktivieren # Konfiguration neu laden (ohne Verbindung zu trennen) root@srv:~# systemctl reload sshd

Tipp: Vor dem Ändern von PasswordAuthentication auf „no" sicherstellen, dass der SSH-Key funktioniert – sonst sperrt man sich selbst aus!

4) SSH-Tunnel und Port-Forwarding

SSH kann nicht nur eine Kommandozeile bereitstellen – es kann auch als verschlüsselter Tunnel für beliebigen anderen Netzwerkverkehr dienen. Das ist besonders nützlich, um auf interne Dienste zuzugreifen, die nicht direkt erreichbar sind, oder um unsichere Verbindungen zu verschlüsseln.

SSH Port-Forwarding – drei Varianten

Local Port Forwarding – lokalen Port weiterleiten

# Datenbankport 5432 auf Remoteserver lokal erreichbar machen $ ssh -L 5432:localhost:5432 max@server.firma.de # Jetzt lokal mit der DB verbinden (über SSH-Tunnel) $ psql -h localhost -p 5432 -U dbuser

Der lokale Port 5432 wird durch den SSH-Tunnel an den Remote-Port 5432 weitergeleitet. Praktisch für: Datenbankzugriff, interne Webserver, RDP über SSH.

Remote Port Forwarding – Remote-Port auf local weiterleiten

# Lokalen Entwicklungsserver von außen erreichbar machen $ ssh -R 8080:localhost:3000 max@server.firma.de # Jetzt kann server.firma.de:8080 auf localhost:3000 zugreifen

Umgekehrter Weg: Der Remote-Server leitet einen Port zurück an deinen lokalen Rechner. Nützlich für Demos und Webhooks in Entwicklungsumgebungen.

Dynamic Port Forwarding – SOCKS-Proxy

# SSH als SOCKS5-Proxy nutzen $ ssh -D 1080 max@server.firma.de # Browser auf SOCKS5 localhost:1080 einstellen # → der gesamte Browser-Verkehr läuft durch den SSH-Tunnel

Der gesamte Netzwerkverkehr des Browsers wird durch den SSH-Tunnel geleitet – ähnlich wie ein einfaches VPN. Wird genutzt, um Zensur zu umgehen oder unsichere Netzwerke sicher zu nutzen.

SSH bildet die Grundlage für weitere Protokolle und Werkzeuge: SFTP für Dateiübertragung, rsync für synchronisiertes Backup und Git-Remotes für Versionsverwaltung nutzen alle SSH als Transportschicht. Wer RDP als grafische Alternative kennenlernen möchte, findet das in der nächsten Lektion: RDP: Remote Desktop Protocol.