Ed25519 SSH-Schlüssel, Multiplexing & OpenSSH-Hardening auf Netcup einrichten

Klassische RSA-2048-Schlüssel sind sperrig und langsamer in der Prüfung; selbst RSA-4096 erzeugt über 740 Zeichen lange Public Keys, während ECDSA-NIST-P-256-Kurven bei schwachen Zufallszahlengeneratoren (RNG) anfällig für Nonce-Lecks sind. Ed25519 (Curve25519 Edwards-Curve Digital Signature Algorithm, entwickelt von Daniel J. Bernstein) erzeugt kompakte, nur 68 Zeichen lange öffentliche Schlüssel mit 128-Bit-Sicherheitsniveau, deterministischen Signaturen und vollständiger Constant-Time-Resistenz gegen Timing-Seitenkanalangriffe.

Bei der Schlüsselerzeugung übergeben wir zusätzlich den Parameter -a 100. OpenSSH speichert Ihren privaten Schlüssel (~/.ssh/id_ed25519_netcup) im modernen OpenSSH-Key-Format und verschlüsselt ihn über die Schlüsselableitungsfunktion bcrypt_pbkdf mit Ihrer Passphrase. Mit -a 100 erzwingen wir 100 KDF-Runden: Für Sie als Administrator dauert das Entsperren des Schlüssels beim ersten Login nur rund 0,2 Sekunden, für einen Angreifer, der Ihre verschlüsselte Schlüsseldatei von einem gestohlenen Laptop erbeutet hat, verteuert sich ein GPU-gestützter Wörterbuchangriff hingegen um mehrere Größenordnungen.

Wenn Sie einen Hardware-Sicherheitsschlüssel wie einen YubiKey 5 oder Nitrokey 3 besitzen, unterstützt OpenSSH 9.6+ unter Ubuntu 24.04 und Windows 11 nativ den Schlüsseltyp -t ed25519-sk (FIDO2/U2F Security Key). Bei einem ed25519-sk-Schlüssel verbleibt das kryptografische Geheimnis dauerhaft im Secure Element des USB-Tokens, und jede SSH-Anmeldung erfordert eine physische Berührung des Hardware-Keys am Arbeitsplatz.

Auf Ihrer lokalen Workstation (erzeugen Sie private Hauptschlüssel niemals auf dem Remote-Server!) richten wir anschließend in der Datei ~/.ssh/config zwei wichtige Optimierungen ein: IdentitiesOnly yes verhindert, dass Ihr SSH-Agent dem Netcup-Server nacheinander fünf andere lokal geladene Schlüssel anbietet und dadurch versehentlich MaxAuthTries 3 überschreitet. Gleichzeitig bündelt ControlMaster auto mit ControlPersist 600 alle weiteren SSH-, scp- und rsync-Aufrufe über einen bereits aufgebauten TCP/TLS-Tunnel, sodass neue Terminalsitzungen in weniger als 15 Millisekunden öffnen:

# 1. Ed25519-Schlüsselpaar mit 100 bcrypt-KDF-Runden auf Ihrem lokalen Computer erzeugen
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_netcup -C "admin@netcup-prod-2026"

# 2. ~/.ssh/config auf Ihrer Workstation für Kurz-Login & TCP-Multiplexing konfigurieren
mkdir -p ~/.ssh/sockets && chmod 0700 ~/.ssh ~/.ssh/sockets
cat << 'EOF' >> ~/.ssh/config
Host nc-prod
    HostName 203.0.113.10
    User deployadmin
    Port 22
    IdentityFile ~/.ssh/id_ed25519_netcup
    IdentitiesOnly yes
    ForwardAgent no
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h-%p
    ControlPersist 600
    ServerAliveInterval 60
EOF
chmod 0600 ~/.ssh/config

Generating public/private ed25519 key pair.
Your identification has been saved in /home/user/.ssh/id_ed25519_netcup
Your public key has been saved in /home/user/.ssh/id_ed25519_netcup.pub

Auf Netcup stehen Ihnen zwei Wege offen, um Ihren öffentlichen Schlüssel (id_ed25519_netcup.pub) auf den Server zu bringen: Bei einer Neuinstallation können Sie den Public Key direkt im Netcup Server Control Panel (SCP) → Media → Official Images hinterlegen, sodass das Cloud-Init-Image den Schlüssel bereits beim ersten Booten in die authorized_keys schreibt. Auf einem bereits laufenden Server übertragen Sie den Schlüssel mit ssh-copy-id -i ~/.ssh/id_ed25519_netcup.pub [email protected].

Beim Härten des OpenSSH-Daemons unter Ubuntu 24.04 LTS müssen Sie zwingend die First-Match-Wins-Auswertungsreihenfolge von OpenSSH beachten: Ganz oben in der Hauptdatei /etc/ssh/sshd_config steht die Direktive Include /etc/ssh/sshd_config.d/*.conf. OpenSSH liest alle .conf-Dateien in diesem Verzeichnis in lexikalischer Reihenfolge ein und ignoriert jeden späteren Parameter, der bereits gesetzt wurde. Da Cloud-Init standardmäßig /etc/ssh/sshd_config.d/50-cloud-init.conf mit PasswordAuthentication yes anlegt, bleibt der Passwort-Login selbst dann aktiv, wenn Sie am Ende der /etc/ssh/sshd_config PasswordAuthentication no eintragen! Entfernen Sie daher 50-cloud-init.conf und prüfen Sie die effektiv wirksame Konfiguration immer mit sudo sshd -T.

In unserer Härtungsdatei /etc/ssh/sshd_config.d/99-netcup-crypto-hardening.conf deaktivieren wir außerdem AllowAgentForwarding no (sowie ForwardAgent no auf dem Client). Warum ist klassisches SSH-Agent-Forwarding (ssh -A) ein Sicherheitsrisiko? Wenn Sie Ihren lokalen ssh-agent auf einen Zielserver weiterleiten, legt sshd dort einen Unix-Domain-Socket unter /tmp/ssh-XXXX/agent.XXXX an. Erlangt ein Angreifer auf diesem Server Root-Rechte (oder Zugriff auf Ihr Benutzerkonto), kann er sich an diesen Socket hängen und über Ihren lokalen SSH-Agenten beliebige andere Produktionsserver kapern, solange Ihre Sitzung geöffnet ist. Nutzen Sie für Sprünge über Bastion-Hosts stattdessen immer ProxyJump (ssh -J bastion zielserver), das Ende-zu-Ende-verschlüsselt direkt von Ihrer Workstation aus authentifiziert.

Schließlich beschränken wir die Schlüsselaustausch-Algorithmen (KexAlgorithms), symmetrischen Chiffren (Ciphers) und Message Authentication Codes (MACs) auf moderne, kryptografisch gehärtete Verfahren – allen voran den hybriden Post-Quantum-Schlüsselaustausch [email protected] (Streamlined NTRU Prime kombiniert mit X25519) sowie [email protected] und [email protected]:

# 1. Öffentlichen Schlüssel von Ihrer Workstation auf Ihren Netcup-Server kopieren
ssh-copy-id -i ~/.ssh/id_ed25519_netcup.pub [email protected]

# 2. Auf dem Netcup-Server die Datei /etc/ssh/sshd_config.d/99-netcup-crypto-hardening.conf anlegen
cat << 'EOF' | sudo tee /etc/ssh/sshd_config.d/99-netcup-crypto-hardening.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
PermitEmptyPasswords no
MaxAuthTries 3
LoginGraceTime 20
AllowUsers deployadmin
X11Forwarding no
AllowAgentForwarding no
KexAlgorithms [email protected],curve25519-sha256,[email protected]
Ciphers [email protected],[email protected],[email protected]
MACs [email protected],[email protected]
EOF

# Cloud-Init-Passwort-Override entfernen, Syntax prüfen und aktive Parameter ausgeben
sudo rm -f /etc/ssh/sshd_config.d/50-cloud-init.conf
sudo sshd -t && sudo systemctl reload ssh
sudo sshd -T | grep -E "^(permitrootlogin|passwordauthentication|pubkeyauthentication|authenticationmethods)"

permitrootlogin no
pubkeyauthentication yes
passwordauthentication no
authenticationmethods publickey

Ab Ubuntu 22.10 und standardmäßig in Ubuntu 24.04 LTS (Noble Numbat) verwendet OpenSSH systemd Socket-Aktivierung (ssh.socket) anstelle eines permanent im Hintergrund lauschenden ssh.service-Daemons. Dabei bindet systemd selbst (PID 1) den TCP-Port 22 und startet den eigentlichen sshd-Prozess erst dann, wenn das erste TCP-SYN-Paket eintrifft. Das hat eine wichtige Konsequenz für Administratoren: Ein klassischer Eintrag Port 2222 in der /etc/ssh/sshd_config bewirkt unter Ubuntu 24.04 überhaupt nichts, weil der Socket-Listener von systemd gesteuert wird!

Wenn Sie SSH auf einen benutzerdefinierten Port (z. B. 2222) verlegen möchten, um 99 % des automatisierten Hintergrund-Rauschens durch Botnetze in Ihren journald-Logs auszublenden, müssen Sie ein systemd-Drop-in-Override unter /etc/systemd/system/ssh.socket.d/override.conf anlegen. Beachten Sie dabei eine wichtige Syntaxregel von systemd: Da ListenStream= eine additive Liste ist, müssen Sie zuerst eine leere Zeile ListenStream= schreiben, um den Standard-Listener auf Port 22 zu löschen, bevor Sie ListenStream=0.0.0.0:2222 und ListenStream=[::]:2222 definieren.

Geben Sie den neuen Port zwingend vor dem Neustart von ssh.socket sowohl in Ihrer lokalen ufw-Firewall (sudo ufw allow 2222/tcp) als auch in der Netcup SCP Stateful Firewall frei. Vergessen Sie die Freigabe in einer der beiden Firewalls, verwirft der Paketfilter jede neue Verbindung auf Port 2222 sofort.

Sollten Sie sich bei einer Änderung an ssh.socket, AllowUsers oder den Firewall-Regeln dennoch einmal aussperren, verlieren Sie auf Netcup niemals den Zugriff auf Ihren Server: Öffnen Sie einfach das Netcup Server Control Panel (servercontrolpanel.de) → Server auswählen → Screen, um die HTML5-VNC-Notfallkonsole direkt im Browser zu starten. Da die VNC-Konsole eine virtuelle VGA-Tastatur/Bildschirm-Verbindung über den Hypervisor herstellt (tty1), ist sie komplett unabhängig vom Netzwerkstack, von UFW und von sshd:

# 1. Neuen SSH-Port in UFW (und in der Netcup SCP Firewall!) VOR dem Umschalten freigeben
sudo ufw allow 2222/tcp comment 'Custom OpenSSH Port'

# 2. systemd Socket-Override für ssh.socket erstellen
sudo mkdir -p /etc/systemd/system/ssh.socket.d
cat << 'EOF' | sudo tee /etc/systemd/system/ssh.socket.d/override.conf
[Socket]
ListenStream=
ListenStream=0.0.0.0:2222
ListenStream=[::]:2222
EOF

# 3. systemd neu laden und ssh.socket neu starten
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
sudo ss -tlpn | grep 2222

LISTEN 0      4096         0.0.0.0:2222       0.0.0.0:*    users:(("systemd",pid=1,fd=98))