Wie richte ich eine sichere SSH-Benutzerauthentifizierung auf einem Cisco Catalyst 9300 mit IOS-XE 17.15.05 ein?

**Sicher richtest du SSH-Zugriff auf einem Catalyst 9300 nicht nur mit `transport input ssh` ein, sondern mit lokaler AAA-Authentifizierung, einem echten Admin-User mit Secret, SSHv2, RSA-Schlüsseln und einer auf SSH beschränkten VTY-Konfiguration; genau das verhindert unsichere Telnet-/Line-Password-Setups.** ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-17/configuration_guide/sec/b_1717_sec_9300_cg/configuring_local_authentication_and_authorization.html)) ## Empfohlene Basiskonfiguration Für einen einzelnen Switch ohne externen TACACS+/RADIUS-Server ist **AAA mit lokaler User-Datenbank** der saubere und sichere Standard. Cisco beschreibt dafür die lokale AAA-Anmeldung und die SSH-Aktivierung getrennt; in der Praxis gehören beide Teile zusammen. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-17/configuration_guide/sec/b_1717_sec_9300_cg/configuring_local_authentication_and_authorization.html)) ```ios conf t ! hostname C9300-01 ip domain-name example.local ! aaa new-model aaa authentication login default local aaa authorization exec default local ! username admin privilege 15 secret <STARKES_PASSWORT> ! crypto key generate rsa modulus 3072 ip ssh version 2 ip ssh time-out 60 ip ssh authentication-retries 2 ! line vty 0 15 login authentication default authorization exec default transport input ssh exec-timeout 10 0 ! end write memory ``` ## Warum genau diese Punkte wichtig sind `aaa new-model` plus `aaa authentication login default local` sorgt dafür, dass der Login **über den lokalen Benutzer** läuft und nicht über ein altes Line-Passwort. Das ist der entscheidende Unterschied zu vielen veralteten Anleitungen, die nur `login local` oder sogar `password` unter `line vty` zeigen. Cisco dokumentiert die lokale AAA-Authentifizierung und -Autorisierung genau für diesen Zweck. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-17/configuration_guide/sec/b_1717_sec_9300_cg/configuring_local_authentication_and_authorization.html)) `username admin privilege 15 secret ...` ist wichtig, weil **`secret` sicherer als `password`** ist. Viele oberflächliche Beispiele im Netz zeigen noch `username ... password ...`; für einen echten Admin-Zugang solltest du stattdessen immer `secret` verwenden. Der praktische Effekt: Das gespeicherte Credential ist deutlich besser geschützt. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-15/configuration_guide/sec/b_1715_sec_9300_cg.pdf)) `transport input ssh` schließt Telnet auf den VTY-Leitungen aus. Das ist keine Kür, sondern Pflicht, wenn der Zugriff wirklich sicher sein soll. SSH benötigt außerdem Hostname, Domain-Name und ein RSA-Schlüsselpaar. Cisco weist darauf hin, dass das Gerät für SSH ein RSA-Schlüsselpaar braucht und dass die SSH-Aktivierung daran gekoppelt ist. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/16-8/configuration_guide/sec/b_168_sec_9300_cg/configuring_secure_shell__ssh.html)) ## Für IOS-XE 17.15 besonders relevant Ab IOS XE 17.x wurden ältere SSH-Algorithmen weiter eingeschränkt; seit 17.1.1 wird SHA-1 in diesem Kontext nicht mehr unterstützt. Außerdem nennt Cisco, dass ab 17.10 bestimmte KEX- und MAC-Algorithmen aus der Default-Liste entfernt wurden. Für 17.15.05 ist das gut: Ein aktueller SSH-Client funktioniert meist ohne Sonderkonfiguration, ein alter Client kann aber plötzlich scheitern. Wenn ein Login also trotz korrekter User-Daten nicht klappt, liegt es oft **nicht** am Benutzer, sondern an veralteten SSH-Algorithmen des Clients. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-15/configuration_guide/sec/b_1715_sec_9300_cg/ssh_algorithms_for_common_criteria_certification.html)) ## Sinnvolle Härtung Wenn der Switch nur aus einem Admin-Netz erreichbar sein soll, begrenze den SSH-Zugriff zusätzlich per ACL auf den VTY-Lines. Das bringt in der Praxis mehr Sicherheitsgewinn als viele kosmetische Einstellungen. ```ios conf t ip access-list standard SSH-MGMT permit 192.0.2.10 permit 192.0.2.11 deny any ! line vty 0 15 access-class SSH-MGMT in end write memory ``` Zusätzlich sinnvoll: - eigenes Management-VLAN oder dediziertes OOB-Management - kein gemeinsamer Admin-Account für mehrere Personen - starke Passwörter oder besser zentrale Authentifizierung - kurze `exec-timeout`-Werte - unbenutzte Management-Dienste deaktivieren ## Häufiger Fehler Der häufigste Denkfehler ist: „SSH läuft, also ist die Authentifizierung sicher.“ Das stimmt nicht. **SSH verschlüsselt nur die Verbindung.** Unsicher bleibt das Setup trotzdem, wenn du etwa nur ein VTY-Line-Passwort nutzt, Telnet offen lässt oder keinen individuellen Benutzer anlegst. ## Wenn du es noch sauberer willst Für produktive Umgebungen ist **TACACS+ statt nur lokaler User** die bessere Lösung, weil du damit personenbezogene Logins, zentrale Rechtevergabe und sauberes Accounting bekommst. Die lokale User-Datenbank bleibt dann nur als Fallback für Notfälle sinnvoll. Cisco trennt lokale AAA bewusst von serverbasierter AAA; genau daraus folgt die Empfehlung: lokal ist gut für Standalone oder Break-Glass, zentral ist besser für Betrieb und Nachvollziehbarkeit. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-17/configuration_guide/sec/b_1717_sec_9300_cg/configuring_local_authentication_and_authorization.html)) ## Kurzfassung Die sichere Minimal-Konfiguration auf deinem Catalyst 9300 mit IOS-XE 17.15.05 ist: - `aaa new-model` - Login-Authentifizierung auf `local` - Admin-User mit `secret` - RSA-Key erzeugen - nur `ip ssh version 2` - auf VTY ausschließlich `transport input ssh` - idealerweise Zugriff per ACL auf Management-IPs begrenzen Damit hast du eine **wirklich sichere User-Authentifizierung für SSH** und nicht nur einen verschlüsselten, aber schlecht abgesicherten Fernzugang.