OpenSSH Hardening – SSH Server tief absichern | Enjyn Gruppe
Hallo Welt
→
→
Hallo Welt
Original Lingva Deutsch
Übersetzung wird vorbereitet...
Dieser Vorgang kann bis zu 60 Sekunden dauern.
Diese Seite wird erstmalig übersetzt und dann für alle Besucher gespeichert.
0%
DE Zurück zu Deutsch
Übersetzung durch Lingva Translate

330 Dokumentationen verfügbar

Wissensdatenbank

OpenSSH Hardening SSH Server Absichern

Zuletzt aktualisiert: 14.07.2026 um 12:29 Uhr

OpenSSH Hardening – SSH Server tief absichern

Standard SSH-Schwachstellen

SSH ist oft das Einfallstor für Hacker, da es das häufigste Verwaltungstool ist. Standardkonfiguration von OpenSSH enthält viele schwache Optionen:

  • Passwort-Authentifizierung aktiviert – ermöglicht Brute-Force-Attacken
  • Root-Login erlaubt – direkter Zugriff auf privilegierteste Account
  • X11-Forwarding aktiviert – potenzielle Sicherheitslücke
  • Port-Forwarding aktiviert – kann zum Tunneling missbraucht werden
  • Schwache Verschlüsselungs-Ciphers – ältere SSH-Versionen nutzen unsichere Algorithmen
  • SSH Protocol 1 aktiv – sehr unsicher, sollte nicht verwendet werden
⚠️ Wichtig: SSH-Brute-Force ist die häufigste Attacke auf Linux-Server. Ein unsecures SSH ist wie eine offene Türe für Hacker.

SSH Konfigurationsdatei – /etc/ssh/sshd_config

Dies ist die zentrale Konfigurationsdatei für den SSH-Server-Daemon (sshd).

Sicherheits-Konfiguration Schritt für Schritt

Erstellen Sie ein Backup:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

Bearbeiten Sie die Datei:

sudo nano /etc/ssh/sshd_config

Essenzielle Sicherheitsoptionen:

# === AUTHENTIFIZIERUNG ===

# DISABLE: Passwort-Authentifizierung
PasswordAuthentication no

# ENABLE: Public-Key-Authentifizierung (Standard)
PubkeyAuthentication yes

# DISABLE: Root Login
PermitRootLogin no

# DISABLE: Empty Passwords
PermitEmptyPasswords no

# ENABLE: Strict Mode (Überprüfe Dateiberechtigungen)
StrictModes yes

# === VERSCHLÜSSELUNG ===

# Nur Protocol 2
Protocol 2

# Nur moderne, starke Ciphers
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

# Nur sichere Key Exchange Algorithms
KexAlgorithms curve25519-sha256@libssh.org,curve25519-sha256,diffie-hellman-group-exchange-sha256

# Nur sichere MACs (Message Authentication Codes)
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256

# === BENUTZER & GRUPPEN ===

# Nur bestimmte Benutzer dürfen sich anmelden
AllowUsers admin@192.168.1.0/24 backup@10.0.0.0/8 deploy

# Oder Gruppen erlauben
AllowGroups ssh-users admin

# Bestimmte Benutzer blocken
DenyUsers root mysql www-data

# === VERBINDUNGS-MANAGEMENT ===

# Client-Inaktivitäts-Timeout (Minutin Sekunden)
ClientAliveInterval 300
ClientAliveCountMax 2

# Login-Grace-Time (Benutzer muss sich innerhalb dieser Zeit authentifizieren)
LoginGraceTime 30s

# Maximale gleichzeitige Verbindungen
MaxStartups 10:30:60  # Starte mit 10, erhöhe bei Bedarf, max 60

# === PORT FORWARDING & X11 ===

# DISABLE: X11 Forwarding
X11Forwarding no

# DISABLE: TCP Forwarding
AllowTcpForwarding no

# DISABLE: Agent Forwarding
AllowAgentForwarding no

# DISABLE: Stream Local Forwarding
AllowStreamLocalForwarding no

# === ANDERE SICHERHEIT ===

# Nur Port 22 (oder ändern Sie zu nicht-Standard, z.B. 2222)
Port 22

# Nur IPv4 oder IPv6 (oder beide)
AddressFamily any

# Kompression DISABLE (potenzielle Sicherheitslücke)
Compression no

# GSSAPI-Authentifizierung nur wenn nötig
GSSAPIAuthentication no

# Host-Based Authentication deaktivieren
HostbasedAuthentication no

# Reverse DNS Lookup deaktivieren (schneller)
UseDNS no

# Permit User Environment (meist unsicher)
PermitUserEnvironment no
💡 Tipp: Die Einstellungen für Ciphers, KexAlgorithms und MACs sind kritisch. Moderne Algorithmen schützen Sie vor Quantum-Computing-Angriffen und neuen Exploit-Techniken.

Konfiguration überprüfen und neu laden

Syntax überprüfen:

sudo sshd -t
# Keine Ausgabe bedeutet: OK

SSH-Service neu starten:

sudo systemctl restart ssh
# Auf RHEL/CentOS:
sudo systemctl restart sshd

VORSICHT: Führen Sie einen Test-Login durch, bevor Sie sich abmelden!

ssh -v user@localhost  # Test vor dem Abmelden

SSH Key-Management

Ed25519 Keys – Modern und schnell

EdDSA mit Curve25519 ist schneller und sicherer als RSA. Generieren Sie neue Keys:

ssh-keygen -t ed25519 -C "max@beispiel.de" -f ~/.ssh/id_ed25519
# Drücken Sie Enter für leere Passphrase oder geben Sie eine ein
# Passphrase ist EMPFOHLEN!

Output:

Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase): [Stark-Passphrase!]
Your identification has been saved in /home/max/.ssh/id_ed25519
Your public key has been saved in /home/max/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:3d6xN7Zk9mP1qR2sT4uV5wX6yZ7aB8cD9eF0gH1iJ max@beispiel.de

Öffentliche Keys verwalten – authorized_keys

Sichere Berechtigungen:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Mehrere Keys in authorized_keys:

cat >> ~/.ssh/authorized_keys << 'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDd6xN7Zk9mP1qR2sT4uV5wX6yZ7aB8cD9eF0gH1iJ max@laptop
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIe8yO8aL0nR3qS4tU5vW6xY7zB8cD9eF0gH1iJ max@desktop
EOF

Key-Rotation

Wechseln Sie Keys regelmäßig (z.B. jährlich):

#!/bin/bash
# /usr/local/bin/rotate-ssh-keys.sh

OLD_KEY="$HOME/.ssh/id_ed25519"
NEW_KEY="$HOME/.ssh/id_ed25519_$(date +%Y-%m-%d)"

# Neuen Key generieren
ssh-keygen -t ed25519 -C "rotation-$(date +%Y-%m-%d)" -f "$NEW_KEY" -N "$(date +%s)"

# Alten Key zu authorized_keys hinzufügen als Backup
if grep -q "$(cat $NEW_KEY.pub)" ~/.ssh/authorized_keys; then
    echo "New key bereits in authorized_keys"
else
    cat "$NEW_KEY.pub" >> ~/.ssh/authorized_keys
    echo "New key zu authorized_keys hinzugefügt"
fi

echo "Alten Key verwenden bis: $(date -d '+7 days' '+%Y-%m-%d')"
echo "Dann umstellen auf: $NEW_KEY"

SSH-Zertifikate (Zentrale Key Management)

Für größere Infrastrukturen verwenden Sie SSH-Zertifikate statt einzelne Keys:

#!/bin/bash
# SSH-Zertifikat erstellen (auf CA-Host)

USER="max"
PUBKEY="$USER.pub"
CERT_NAME="$USER-cert-$(date +%Y%m%d)"

# Signieren Sie den Public Key:
ssh-keygen -s /etc/ssh/ca_keys/host_ca \
  -I "$USER-$(date +%s)" \
  -n "$USER" \
  -V +365d \
  -z $(date +%s) \
  "$PUBKEY"

# Output: $USER-cert.pub ist das Zertifikat

Im Server erlauben Sie nur Zertifikate:

# In /etc/ssh/sshd_config:
TrustedUserCAKeys /etc/ssh/ca_keys/user_ca.pub

Zwei-Faktor-Authentifizierung (2FA) mit Google Authenticator

Auch mit Key-basierter Authentifizierung, fügen Sie 2FA hinzu:

Installation:

sudo apt install libpam-google-authenticator

Für jeden Benutzer einrichten:

google-authenticator

# Es werden QR-Code und Backup-Codes angezeigt
# Speichern Sie die Backup-Codes!

SSH-Konfiguration aktivieren:

sudo nano /etc/ssh/sshd_config

# Fügen Sie hinzu:
AuthenticationMethods publickey,password publickey,keyboard-interactive
PasswordAuthentication no
KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive:pam

# PAM-Konfiguration:
sudo nano /etc/pam.d/sshd

# Ändern Sie oder fügen Sie hinzu:
auth required pam_google_authenticator.so

Neustart und Test:

sudo sshd -t
sudo systemctl restart ssh

# Test: ssh sollte jetzt SSH-Key + Authenticator-Code fordern!

SSH Jump Hosts (Bastion Hosts)

Um Server hinter Firewalls sicher zu erreichen, verwenden Sie Jump Hosts:

Client-Seite (~/.ssh/config):

Host bastion
    HostName bastion.beispiel.de
    User admin
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

Host internal-server
    HostName internal.local
    User admin
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

# Verwendung:
ssh internal-server  # Verbindet automatisch über bastion

Server-Seite – Restricted Commands in authorized_keys:

# /root/.ssh/authorized_keys auf Bastion:
command="restrict-session",from="203.0.113.0/24",no-x11-forwarding ssh-ed25519 AAAA... user@laptop

Bevor/Nachher – Konfigurationsvergleich

Setting Standard (UNSICHER) Gehärtet (SICHER)
PasswordAuthentication yes no
PermitRootLogin yes no
X11Forwarding yes no
AllowTcpForwarding yes no
Ciphers Mit 3DES, RC4 (UNSICHER) Nur AES-GCM, ChaCha20
KexAlgorithms diffie-hellman-group1 (schwach) curve25519-sha256 (modern)
MACs hmac-md5 (UNSICHER) hmac-sha2-512-etm
Port 22 (offensichtlich) 2222+ (Optional, nicht Sicherheit)
AllowUsers (nicht gesetzt, alle erlaubt) admin deploy backup
✅ Gut zu wissen: Mit Curve25519-ECDH und ChaCha20-Poly1305 ist Ihr SSH nicht nur sicher gegen bekannte Attacken, sondern auch robust gegen zukünftige Quantum-Computing-Bedrohungen.

SSH-Audit und Konfigurationsprüfung

Verwendung von ssh-audit:

sudo apt install ssh-audit
# oder
curl https://raw.githubusercontent.com/jtesta/ssh-audit/master/ssh-audit.py > ssh-audit.py

# Ihr Server überprüfen:
python3 ssh-audit.py localhost
# oder
ssh-audit localhost

Dies zeigt Ihnen genau, welche Algorithms sicher sind und welche nicht.

SSH Hardening – Checkliste

Überprüfung Status
PasswordAuthentication = no Ja ☐ Nein ☐
PermitRootLogin = no Ja ☐ Nein ☐
X11Forwarding = no Ja ☐ Nein ☐
AllowTcpForwarding = no Ja ☐ Nein ☐
Nur moderne Ciphers (AES-GCM, ChaCha20) Ja ☐ Nein ☐
AllowUsers/AllowGroups definiert Ja ☐ Nein ☐
Ed25519 SSH Keys generiert Ja ☐ Nein ☐
authorized_keys mit restriktiven Rechten (600) Ja ☐ Nein ☐
2FA mit google-authenticator aktiviert Ja ☐ Nein ☐
sshd_config mit sshd -t überprüft Ja ☐ Nein ☐
ssh-audit durchgeführt Ja ☐ Nein ☐

Zusammenfassung

SSH ist eine der kritischsten Dienste auf Linux-Servern. Ein gehärtetes SSH:

  • Deaktiviert Passwort-Authentifizierung
  • Verbietet Root-Login
  • Verwendet nur moderne, starke Verschlüsselung
  • Implementiert Ed25519 Keys
  • Schützt vor Forwarding- und X11-Angriffen
  • Nutzt 2FA mit Google Authenticator
  • Nutzt SSH Zertifikate für zentrale Key Management

Weiterführende Links

Texterstellung mit KI-Unterstützung

Enjix Beta

Enjyn AI Agent

Hallo 👋 Ich bin Enjix — wie kann ich dir helfen?
LLMs können Fehler machen. Ihre Nachrichten werden an Google Gemini weitergeleitet.
120