Benutzer- und Passwortmanagement ist auf Cisco Switches ein Kernbestandteil der Netzwerksicherheit. In kleinen Umgebungen reichen lokale Accounts oft aus, in professionellen Netzen sind AAA-Setups (TACACS+ oder RADIUS) praktisch Pflicht: zentrale Benutzerverwaltung, Rollen, Accounting und nachvollziehbare Änderungen. Dieses Tutorial erklärt die Unterschiede, zeigt praxistaugliche Konfigurationen und typische Best Practices, damit Remote-Zugriff (SSH) sicher und zuverlässig funktioniert.
Grundbegriffe: Lokale Accounts, Enable Secret und AAA
Auf Cisco IOS/IOS XE gibt es zwei „Ebenen“ der Zugangskontrolle: den Login (User) und die privilegierte Ebene (Enable). Lokale Accounts liegen direkt auf dem Gerät, AAA bindet externe Authentifizierungsserver ein.
- Lokaler Benutzer:
username ... secret ...auf dem Switch - Enable Secret: schützt den Privileged EXEC Mode (
#) - AAA: Authentication, Authorization, Accounting – zentral gesteuert
Warum „secret“ statt „password“?
secret wird gehasht gespeichert (deutlich sicherer). password ist schwächer und sollte im professionellen Betrieb vermieden werden.
show running-config | include username|enable secret|service password-encryption
Lokale Accounts: Einfach, schnell, aber begrenzt
Lokale Benutzer sind ideal für Labs, kleine Standorte oder als Notfall-Fallback, wenn AAA nicht erreichbar ist. Der Nachteil: Benutzerpflege ist manuell und skaliert schlecht.
Lokalen Admin-Account und Enable Secret konfigurieren
configure terminal
enable secret <SICHERES_ENABLE_SECRET>
username admin privilege 15 secret
service password-encryption
end
VTY-Lines für SSH mit lokalem Login
Damit SSH-Logins den lokalen Benutzer verwenden, musst du auf den VTY-Lines login local setzen und Telnet deaktivieren.
configure terminal
ip domain-name corp.local
crypto key generate rsa modulus 2048
ip ssh version 2
line vty 0 15
login local
transport input ssh
exec-timeout 10 0
exit
end
Read-Only Nutzer (einfacher Ansatz)
Für einfache Rollen kannst du niedrigere Privilege-Level nutzen. Für echte Rollenmodelle ist AAA/TACACS+ meist die bessere Lösung.
configure terminal
username readonly privilege 5 secret <PASSWORT>
end
AAA im Überblick: Authentication, Authorization, Accounting
AAA trennt sauber, wer sich anmelden darf (Authentication), welche Befehle erlaubt sind (Authorization) und was protokolliert wird (Accounting). Das ist besonders wichtig für Teams und Compliance.
- Authentication: Wer bist du?
- Authorization: Was darfst du tun?
- Accounting: Was hast du getan?
TACACS+ vs. RADIUS (Praxisorientierung)
TACACS+ wird häufig für Device-Administration genutzt, da es Command Authorization/Accounting gut unterstützt. RADIUS ist stark bei Netzwerkzugang (802.1X), wird aber auch für Device-Logins genutzt.
- TACACS+: häufig für Admin-Zugriffe und Command-Accounting
- RADIUS: häufig für 802.1X/NAC, auch für Admin möglich
AAA sicher einführen: Immer mit Fallback, um Lockouts zu vermeiden
Der größte Fehler bei AAA ist, sich auszusperren. Baue daher immer eine lokale Fallback-Methode ein und teste zunächst nur über eine aktive SSH-Session – nicht über die Konsole allein.
- Lokalen Admin-User als Fallback behalten
- AAA zuerst für VTY testen, dann optional auch für Console
- Time-Outs und Server-Dead-Handling sinnvoll setzen
AAA aktivieren und lokale Fallback-Methoden definieren
Dieses Beispiel aktiviert AAA und nutzt primär TACACS+, fällt aber auf lokal zurück, wenn der Server nicht erreichbar ist.
configure terminal
aaa new-model
username admin privilege 15 secret <LOCAL_FALLBACK_PASSWORT>
enable secret <SICHERES_ENABLE_SECRET>
aaa authentication login VTY_AUTH group tacacs+ local
aaa authorization exec VTY_EXEC group tacacs+ local
aaa accounting exec VTY_ACCT start-stop group tacacs+
end
VTY-Lines auf AAA umstellen
Wichtig: login authentication verweist auf die AAA-Methode. SSH bleibt der Transport.
configure terminal
line vty 0 15
login authentication VTY_AUTH
authorization exec VTY_EXEC
transport input ssh
exec-timeout 10 0
exit
end
TACACS+ konfigurieren: Praxisbeispiel mit zwei Servern
Nutze mindestens zwei TACACS+ Server für Redundanz. Setze ein Source-Interface (Management-VLAN), damit Policies/Firewall-Regeln stabil matchen.
TACACS+ Server definieren (klassischer Stil)
configure terminal
tacacs server TAC1
address ipv4 192.168.99.80
key <SHARED_SECRET>
exit
tacacs server TAC2
address ipv4 192.168.99.81
key
exit
ip tacacs source-interface vlan 99
end
Connectivity prüfen
Wenn Auth fehlschlägt, liegt es häufig an Routing/ACLs oder am falschen Source-Interface. Prüfe zuerst die Erreichbarkeit.
ping 192.168.99.80
ping 192.168.99.81
show ip interface brief
show ip route
RADIUS konfigurieren: Praxisbeispiel (alternativ)
Wenn deine Umgebung RADIUS nutzt, ist der Aufbau ähnlich: Server definieren, Key setzen, Source-Interface festlegen und AAA-Methoden referenzieren.
configure terminal
radius server RAD1
address ipv4 192.168.99.90 auth-port 1812 acct-port 1813
key <SHARED_SECRET>
exit
radius server RAD2
address ipv4 192.168.99.91 auth-port 1812 acct-port 1813
key <SHARED_SECRET>
exit
ip radius source-interface vlan 99
aaa authentication login VTY_AUTH group radius local
aaa authorization exec VTY_EXEC group radius local
aaa accounting exec VTY_ACCT start-stop group radius
end
Best Practices: Passwörter, Rollen, Logging und Zugriffskontrolle
Unabhängig von lokal oder AAA gilt: sichere Credentials, klare Rollen und sauberes Logging sind Pflicht. Ergänze AAA durch Zugriffsbeschränkung und sichere Transportwege.
- SSH-only: Telnet deaktivieren (
transport input ssh) - VTY-Zugriff per ACL auf Admin-Netze begrenzen (
access-class) - Lokaler Admin als Fallback (Break-Glass) behalten
- AAA-Accounting aktivieren (wer hat wann was getan)
- Konfig sichern und versionieren (pre-/post-change)
VTY per ACL absichern (Beispiel)
configure terminal
ip access-list standard ACL-MGMT-SSH
permit 192.168.99.0 0.0.0.255
deny any
exit
line vty 0 15
access-class ACL-MGMT-SSH in
end
Login-Events protokollieren
configure terminal
login on-success log
login on-failure log
end
show logging | include LOGIN|AUTH|SEC
Verifikation und Troubleshooting: Wenn AAA nicht wie erwartet funktioniert
Gehe bei Problemen strukturiert vor: erst AAA-Methoden, dann Server-Definition, dann Reachability und zuletzt Logs. Häufige Fehler sind falsche Keys, falsches Source-Interface oder blockierte Ports.
show running-config | include aaa|tacacs|radius
show running-config | section line vty
show access-lists
show logging
Typische Ursachen schnell erkennen
- Keine Erreichbarkeit zum AAA-Server (Routing/ACL/Firewall)
- Falsches Shared Secret (Key) zwischen Switch und Server
- Kein Source-Interface gesetzt, Server sieht „falsche“ Client-IP
- AAA ohne lokalen Fallback führt zu Lockout bei Server-Ausfall
ping 192.168.99.80
show ip route
show ip interface brief
show logging | include TACACS|RADIUS|AAA|AUTH|FAIL
Minimaler, sicherer Standard: Lokaler Fallback + AAA für VTY
Für viele produktive Netze ist ein hybrider Ansatz ideal: AAA als Standard, lokaler Admin als Notfallzugang. So ist Betrieb sicher, skalierbar und robust gegen AAA-Ausfälle.
configure terminal
aaa new-model
enable secret <SICHERES_ENABLE_SECRET>
username admin privilege 15 secret <LOCAL_FALLBACK_PASSWORT>
aaa authentication login VTY_AUTH group tacacs+ local
aaa authorization exec VTY_EXEC group tacacs+ local
aaa accounting exec VTY_ACCT start-stop group tacacs+
line vty 0 15
login authentication VTY_AUTH
authorization exec VTY_EXEC
transport input ssh
exec-timeout 10 0
exit
end
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.
