Kryptografische OpenSSH-Architektur: Bastions, ProxyJump & Verschlüsseltes Port-Forwarding

Erstellt: 08.11.2026 · Zuletzt aktualisiert: 08.11.2026 · Nejat Hakan

Management Summary: OpenSSH ist das primäre administrative Zugangstor zu jedem produktiven Linux-Server. Wer auf veraltete RSA-Schlüssel, ungehärtete Standard-Verschlüsselungsverfahren oder Passwort-Authentifizierung setzt, setzt geschäftskritische Infrastrukturen automatisierten Brute-Force-Angriffen und Credential-Stuffing aus. Professionelles Systems Engineering verlangt Ed25519-Schlüsselpaare über elliptische Kurven, post-quanten-resistenten Schlüsselaustausch, präzise sshd_config-Härtung, TCP-Verbindungs-Multiplexing via ControlMaster, sichere Bastion-Hosts mit ProxyJump sowie verschlüsseltes Port-Forwarding (Local, Remote und Dynamic SOCKS5).

Ed25519 & Kryptografie

Moderne Ed25519-Schlüssel mit hohen KDF-Runden (-a 100) generieren, Post-Quanten-KEX konfigurieren und alte RSA/DSA-Schlüssel verbannen.
Produktionsnahe sshd-Härtung

Passwörter und Root-Login sperren, Cipher-Suites auf ChaCha20-Poly1305 und AES-GCM beschränken und strenge Authentifizierungs-Limits setzen.
Bastions & ProxyJump

Isolierte DMZ- und LAN-Netzwerkzonen sicher über ProxyJump (-J) traversieren, ohne die fatalen Sicherheitsrisiken von altem Agent-Forwarding (-A) einzugehen.
Port-Forwarding (-L, -R, -D)

Lokale Datenbank-Clients verschlüsselt an Server-Loopbacks binden (-L), lokale Entwicklungsserver freigeben (-R) und SOCKS5-Proxies starten (-D).

1. Kryptografisches Schlüsselmanagement: Das Ende von RSA

Veraltete RSA-2048- und RSA-4096-Schlüssel leiden unter langsamer Schlüsselerzeugung, Anfälligkeit für Seitenkanalangriffe und unnötig großen Schlüssellängen. Der moderne Standard im Linux-Umfeld ist Ed25519 (Edwards-curve Digital Signature Algorithm über Curve25519):

Deterministische Signaturen: Verhindert das Auslesen privater Schlüssel durch fehlerhafte Zufallszahlengeneratoren.
Kompakter Footprint: Öffentliche Schlüssel sind nur 68 Zeichen lang, was die Überprüfung in authorized_keys massiv erleichtert.
Widerstandsfähige Key Derivation Function (KDF): Nutzt bcrypt PBKDF, um private Schlüssel auf lokalen Datenträgern gegen Offline-Brute-Force-Angriffe abzusichern.

Gehärtete `Ed25519`-Schlüsselpaare erzeugen

Erstelle ein Ed25519-Schlüsselpaar mit 100 bcrypt-KDF-Runden und einer aussagekräftigen Beschreibung:

# Ed25519-Schlüsselpaar mit hoher KDF-Rundenzahl generieren
ssh-keygen -t ed25519 -a 100 -C "nejat@infra-workstation" -f ~/.ssh/id_ed25519_infra

# Strikte Dateisystemberechtigungen setzen
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519_infra
chmod 644 ~/.ssh/id_ed25519_infra.pub

Den öffentlichen Schlüssel sicher auf den Ziel-Debian-Server übertragen:

ssh-copy-id -i ~/.ssh/id_ed25519_infra.pub nejat@192.168.1.50

2. Serverhärtung in der Praxis (`sshd_config.d`)

In Debian 11/12+ wird niemals die Datei /etc/ssh/sshd_config direkt editiert. Lege stattdessen eine gehärtete Konfigurationsdatei in /etc/ssh/sshd_config.d/99-hardening.conf an:

# Datei: /etc/ssh/sshd_config.d/99-hardening.conf
# 1. Authentifizierungs-Einschränkungen
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey

# Zugriff strikt auf definierte Administrationsbenutzer beschränken
AllowUsers nejat

# 2. Gehärtete kryptografische Algorithmen
# Post-Quanten-Hybrid-KEX (sntrup761) + klassisches Curve25519
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org

# Nur moderne AEAD-Verschlüsselungsverfahren (Authenticated Encryption)
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com

# Encrypt-then-MAC (ETM) Algorithmen
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# 3. Verbindungs-Limits & Brute-Force-Schutz
MaxAuthTries 3
LoginGraceTime 20
MaxSessions 2
ClientAliveInterval 300
ClientAliveCountMax 2

# 4. Ungenutzte Subsysteme deaktivieren
X11Forwarding no
AllowAgentForwarding no

Prüfe die Syntax vor jedem Dienst-Reload, um versehentliche Aussperrungen zu verhindern:

# Syntax überprüfen (bleibt bei Erfolg stumm)
sudo sshd -t

# Konfiguration ohne Unterbrechung bestehender Sessions aktivieren
sudo systemctl reload ssh

3. Bastion-Hosts & Multi-Hop-Zugriff: `ProxyJump` vs. Agent-Forwarding

Um interne Datenbank-Cluster oder Hypervisoren in isolierten Netzwerkzonen zu erreichen, führt der Weg über einen Bastion-Host (Jump Server) in der DMZ:

%%{init: {'flowchart': {'wrappingWidth': 350}}}%%
flowchart TB
    WORK["Workstation<br/>Lokaler privater Key"]
    BAST["Bastion-Host (DMZ)<br/>203.0.113.10:22<br/>Öffentliche WAN-IP"]
    INT["Interner DB-Server<br/>10.10.20.11:22<br/>Privates Subnetz"]

    WORK ==>|"1. SSH ProxyJump (-J)"| BAST
    BAST ==>|"2. Reines TCP stdio"| INT

Das fatale Sicherheitsrisiko von Agent-Forwarding (ssh -A)

In alten Anleitungen wird oft empfohlen, den SSH-Agenten weiterzuleiten (ssh -A bastion). Tue dies niemals auf geteilten Servern. Wird der Bastion-Host kompromittiert, kann ein Angreifer über deinen weitergeleiteten Unix-Domain-Socket ($SSH_AUTH_SOCK) in deinem Namen auf alle Server zugreifen, für die dein Schlüssel autorisiert ist!

Die moderne Lösung: `ProxyJump` (`-J`)

ProxyJump baut eine direkte Ende-zu-Ende-Verschlüsselung zwischen deiner Workstation und dem internen Zielhost auf. Der Bastion-Host fungiert lediglich als reiner TCP-Datenstrom-Vermittler (stdio) und sieht weder entschlüsselte Daten noch deinen privaten Schlüssel oder Agent-Socket.

# Ad-hoc-Verbindung über den Bastion-Host
ssh -J nejat@203.0.113.10 nejat@10.10.20.11

4. Client-Automatisierung: `~/.ssh/config`

Konfiguriere Multiplexing, Keepalives und automatische Jump-Hosts in deiner lokalen ~/.ssh/config:

# Datei: ~/.ssh/config

# Globale Einstellungen für alle Hosts
Host *
    # Verbindungs-Multiplexing (Bestehende TCP/SSH-Verbindung für neue Shells wiederverwenden)
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h:%p
    ControlPersist 10m

    # Keepalives gegen Verbindungsabbrüche durch Stateful NAT-Firewalls
    ServerAliveInterval 30
    ServerAliveCountMax 3

    # Strikte Schlüsselprüfung
    StrictHostKeyChecking ask
    IdentitiesOnly yes

# 1. Bastion-Host in der DMZ
Host bastion
    HostName 203.0.113.10
    User nejat
    Port 22
    IdentityFile ~/.ssh/id_ed25519_infra

# 2. Interner Datenbankserver (Wird automatisch durch den Bastion getunnelt)
Host db-primary
    HostName 10.10.20.11
    User nejat
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519_infra
    # Lokalen Port 15432 automatisch an entferntes 127.0.0.1:5432 weiterleiten
    LocalForward 127.0.0.1:15432 127.0.0.1:5432

Verbindung mit einem einzigen Befehl herstellen:

ssh db-primary

5. Die drei Portweiterleitungs-Modi: Local, Remote & Dynamic

%%{init: {'flowchart': {'wrappingWidth': 350}}}%%
flowchart TB
    subgraph L["1. Local Forwarding (-L)"]
        direction TB
        L_SRC["Lokal :15432"] -->|"SSH Tunnel"| L_DST["Remote DB :5432"]
    end
    subgraph R["2. Remote Forwarding (-R)"]
        direction TB
        R_SRC["Remote :8080"] -->|"SSH Tunnel"| R_DST["Lokale App :3000"]
    end
    subgraph D["3. Dynamic SOCKS5 (-D)"]
        direction TB
        D_SRC["Browser :1080"] -->|"SSH Tunnel"| D_DST["Internet via Remote"]
    end

    L --> R --> D

1. Lokale Portweiterleitung (`-L`)

Bindet einen Port auf deiner lokalen Maschine und leitet alle eingehenden Anfragen durch den SSH-Tunnel an einen Zielport auf dem entfernten Server:

# Syntax: ssh -L [bind_adresse:]lokaler_port:ziel_host:ziel_port server
# Lokalen Client (DBeaver/psql) mit der entfernten PostgreSQL-DB verbinden
ssh -N -L 127.0.0.1:15432:127.0.0.1:5432 nejat@db-primary

Lokal verbinden: psql -h 127.0.0.1 -p 15432 -U postgres

2. Entfernte Portweiterleitung (`-R`)

Bindet einen Port auf dem entfernten Server und leitet Anfragen zurück an einen Port auf deiner lokalen Maschine. Ideal, um lokale Webhook-Receiver oder Testumgebungen bereitzustellen:

# Syntax: ssh -R [bind_adresse:]remote_port:ziel_host:lokaler_port server
# Lokale Webanwendung (:3000) auf Port :8080 des Bastion-Servers bereitstellen
ssh -N -R 127.0.0.1:8080:127.0.0.1:3000 nejat@bastion

3. Dynamischer SOCKS5-Proxy (`-D`)

Verwandelt die SSH-Verbindung in einen verschlüsselten SOCKS5-Proxy. Browser oder curl können über 127.0.0.1:1080 den gesamten Internetverkehr über den entfernten Server tunneln:

# Lokalen SOCKS5-Proxy auf Port 1080 starten
ssh -N -D 127.0.0.1:1080 nejat@bastion

# Beliebige HTTP-Anfragen über den entfernten Server tunneln
curl --socks5-hostname 127.0.0.1:1080 https://icanhazip.com

(Der Parameter -N weist OpenSSH an, keine interaktive Shell zu öffnen, sondern die Verbindung rein für das Port-Forwarding zu reservieren).

6. Nächste Schritte

Nachdem der administrative Fernzugriff gehärtet und verschlüsselte Tunnel etabliert sind, folgt die Absicherung des Betriebssystems über Stateful-Paketfilter im Linux-Kernel:

Stateful Packet Filtering mit nftables & ufw

Netfilter-Kernel-Hooks, Dual-Stack inet-Tabellen, Connection Tracking (conntrack) und UFW-Profilmanagement.

Zum nftables & UFW Leitfaden

Kryptografische OpenSSH-Architektur: Bastions, ProxyJump & Verschlüsseltes Port-Forwarding

1. Kryptografisches Schlüsselmanagement: Das Ende von RSA

Gehärtete Ed25519-Schlüsselpaare erzeugen

2. Serverhärtung in der Praxis (sshd_config.d)

3. Bastion-Hosts & Multi-Hop-Zugriff: ProxyJump vs. Agent-Forwarding

Die moderne Lösung: ProxyJump (-J)

4. Client-Automatisierung: ~/.ssh/config