Here is a brief configuration snippet:
version 15.1
.
.
.
no aaa new-model
enable password 0 ******
enable secret 0 ******
.
.
.
line con 0
exec-timeout 0 0
password ******
stopbits 1
line aux 0
stopbits 1
line vty 0 4
password ******
login
length 0
line vty 5 15
password ******
login
Later on, someone changed the configuration via a telnet session (!) like so:
aaa new-model
username ******
password 0 ******
ip domain-name ******
generate rsa cyrpto-key
line vty 0 15
transport input ssh
Naturally, at that moment the telnet session was toast. ssh works, but the enable password doesn't work. It also doesn't work from the serial console.
I'm suspecting this behavior is being caused by a combination of the "aaa new-model" global command, the "login" vty line commands and (perhaps) the lack of level 15 privilege on the user account and/or the console & vty lines.
Since the information above seems to indicate that the last person in the switch with enable access was locked out before they could save the config changes, it seems like a reboot might restore enable access. The problem is that the switch is currently in production as a VSS cluster, and the owner of the switch is balking at taking an outage to try & correct this problem. Can anyone suggest a workaround to restore enable access, without rebooting the switch?
