SSH Hardening: Ciphers, KEX, MACs und Key Management auf Cisco

SSH ist auf Cisco Routern der wichtigste Management-Zugriff – und damit ein primäres Angriffsziel. „SSH an“ reicht für Hardening nicht aus: In der Praxis geht es um die Kryptoparameter (Ciphers, KEX, MACs), um Key-Management (RSA/ECDSA, Rotation), um Zugriffspfad-Restriktionen (VTY ACL, VRF/OOB) und um Betriebsprozesse (Audit, Logging, Break-Glass). Ein gutes SSH-Hardening reduziert Risiko und hält gleichzeitig Automatisierung (Ansible/Netconf) kompatibel. Dieser Artikel zeigt ein praxisnahes Hardening-Design für Cisco IOS/IOS XE mit Fokus auf sichere Defaults und kontrollierte Kompatibilität.

Baseline: SSH wirklich als einziges Remote-Transportprotokoll

Hardening beginnt damit, die Angriffsfläche zu reduzieren: Telnet aus, SSH only auf VTY, kurze Timeouts, Login-Rate-Limits und Zugriff nur aus Admin-Netzen. Erst danach lohnt das Feintuning der Kryptosuiten.

• Telnet deaktivieren, SSH als einziges VTY-Transportprotokoll
• VTY Zugriff per ACL/VRF beschränken (OOB/MGMT bevorzugt)
• Session-Timeouts und Login-Block aktivieren

VTY Baseline (Pattern)

ip access-list standard VTY_MGMT_ONLY
 permit 10.99.0.0 0.0.0.255
 deny any
line vty 0 4

transport input ssh

access-class VTY_MGMT_ONLY in

exec-timeout 10 0

login local

SSH Version und Schlüsselbasis

Für moderne Hardening-Standards ist SSH Version 2 Pflicht. Zusätzlich ist die Schlüsselbasis entscheidend: RSA mit ausreichender Länge ist weit kompatibel, ECDSA ist effizient, aber nicht überall gleich unterstützt. Wichtig ist ein klarer Key-Rotation-Prozess.

• SSH v2 erzwingen
• RSA 2048/3072 als Kompatibilitätsstandard
• Optional ECDSA, wenn Tooling/Policy passt

SSH v2 aktivieren

ip ssh version 2

Keypair erzeugen (RSA Pattern)

crypto key generate rsa general-keys modulus 2048 label SSH-RSA-KEY

Krypto-Bausteine: KEX, Cipher, MAC – wofür steht was?

SSH verhandelt mehrere Kryptobausteine. KEX (Key Exchange) bestimmt, wie die Sitzungsschlüssel ausgehandelt werden. Cipher ist die symmetrische Verschlüsselung des Datenstroms. MAC (Message Authentication Code) schützt Integrität, sofern kein AEAD-Cipher genutzt wird.

• KEX: schützt den Schlüsselaustausch (z. B. ECDH)
• Cipher: verschlüsselt die Session (z. B. AES-CTR, AES-GCM)
• MAC: Integrität (z. B. HMAC-SHA2), entfällt praktisch bei AEAD

Merker

$\text{Sicherheit}\uparrow \iff \text{Kompatibilität}\downarrow \text{(bei zu strikter Suite)}$

Hardening-Zielbild: Moderne, aber praxistaugliche Suiten

Im Enterprise ist das Ziel meist: nur moderne KEX (ECDH), nur moderne Ciphers (AES-CTR oder AES-GCM, je nach Plattform) und nur SHA-2 MACs. Veraltete Algorithmen wie 3DES oder HMAC-SHA1 sollten vermieden werden, wenn dein Tooling es zulässt.

• KEX: ecdh-sha2-* bevorzugen
• Cipher: aes128-ctr/aes256-ctr (breit kompatibel)
• Optional: AES-GCM, wenn Plattform/Version es sauber unterstützt
• MAC: hmac-sha2-256/512 bevorzugen

Konfiguration: SSH KEX/Cipher/MAC auf Cisco (Pattern)

Die verfügbaren Befehle und exakten Namen können je nach IOS/IOS XE Release variieren. Das folgende Pattern zeigt das gängige Prinzip: erlaubte Algorithmen auf eine moderne Allow-List reduzieren. Prüfe danach immer Kompatibilität mit deinen Clients (OpenSSH, Automatisierung).

Beispiel Allow-List (Pattern)

ip ssh server algorithm kex ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521
ip ssh server algorithm encryption aes128-ctr aes256-ctr
ip ssh server algorithm mac hmac-sha2-256 hmac-sha2-512

Kompatibilitätsstrategie: „Strikt, aber mit Plan“

SSH-Hardening scheitert selten an Sicherheit, sondern an Tools: ältere Jump-Hosts, Legacy-Automation, alte OpenSSH-Versionen. Die professionelle Strategie ist: erst Inventarisieren, dann stufenweise härten und eine dokumentierte „Legacy-Exception“ nur dort zulassen, wo nötig.

• Phase 1: Logging/Monitoring, SSH v2, Telnet aus
• Phase 2: SHA-1/3DES entfernen
• Phase 3: nur noch moderne KEX/Cipher/MAC
• Legacy-Exceptions zeitlich begrenzen und tracken

Key Management: Rotation, Backup, Vertrauenskette

SSH-Keys sind Identitäten. Wenn du Geräte-Keys rotierst, müssen Clients ihre Known-Hosts aktualisieren, sonst entstehen „Man-in-the-middle“-Warnungen. Plane Rotation daher wie einen Change, nicht als Nebenbei-Aufgabe.

• Rotation geplant (Maintenance Window), nicht ad hoc
• Known-Hosts in Jump-Hosts/Automation aktualisieren
• Key-Labels und Inventar führen (welcher Key ist aktiv?)

Keys anzeigen (Pattern)

show crypto key mypubkey rsa
show ip ssh

Rotation (Beispielprozess)

crypto key generate rsa general-keys modulus 2048 label SSH-RSA-KEY-NEW
! Nach Validierung alte Keys entfernen (vorsichtig, Change!)
! crypto key zeroize rsa label SSH-RSA-KEY

Zusätzliche Härtung: AAA, RBAC und Source-Restrictions

SSH-Kryptosuiten schützen den Transport. Zugriffsschutz kommt aus AAA/RBAC: zentrale Authentifizierung (TACACS+), Command Authorization und minimale Rechte. Kombiniere das immer mit Source-Restrictions (VTY ACL, MGMT-VRF).

• AAA/TACACS+: keine shared Admin-Passwörter
• RBAC: Rollen statt Privilege 15 für alle
• MGMT-VRF/OOB: Zugriff nicht über Transitpfade

Timeouts, Login-Block und Brute-Force-Resilienz

SSH-Hardening ist auch „Betriebsschutz“. Kurze Idle-Timeouts reduzieren Risiko, Login-Block reduziert Brute Force. Achte darauf, dich nicht selbst auszusperren (Console/OOB als Break-Glass).

Login-Block (Pattern)

login block-for 120 attempts 3 within 60
login on-failure log
login on-success log

Troubleshooting: Wenn Clients sich plötzlich nicht mehr verbinden

Nach Suite-Hardening sind Verbindungsprobleme fast immer Algorithmus-Mismatch oder Key-Change. Debugge zuerst auf Client-Seite (welche KEX/Cipher bietet der Client?), dann auf Router-Seite (welche Algorithmen sind erlaubt?).

Router Checks

show ip ssh
show running-config | include ip ssh
show access-lists VTY_MGMT_ONLY
show line vty 0 4

Typische Fehlerbilder

• „No matching key exchange method“: KEX zu strikt
• „No matching cipher“: Cipher-Allow-List zu eng
• „REMOTE HOST IDENTIFICATION HAS CHANGED“: Key-Rotation ohne Client-Update
• Timeout: VTY ACL/VRF/Routing blockiert

Operational Best Practices: SSH als Standard-Produkt betreiben

SSH-Hardening ist dann robust, wenn es als Baseline-Template existiert: einheitliche Suiten, dokumentierte Exceptions, Rotation-Prozess und Monitoring. So vermeidest du, dass jedes Gerät „anders“ ist.

• Golden Config: einheitliche SSH-Algorithmen
• Jump-Host Standard: kompatible OpenSSH-Versionen
• Key-Rotation Runbook + Known-Hosts Pflege
• Monitoring: Login-Erfolge/Fehlschläge, Rate-Limits

Quick-Runbook: SSH Hardening verifizieren

Diese Checkliste zeigt, ob Transport, Zugriff und Kryptoparameter konsistent sind.

show ip ssh
show run | include ip ssh|login block-for
show line vty 0 4
show access-lists VTY_MGMT_ONLY
show logging | include SSH|SEC_LOGIN

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.