I am using username secret to add users with encrypted passwords to our switches and firewall.

I have been battling with the same switches and firewall for a couple of hours trying to get securely generated hard passwords for all admins. Sometimes, the passwords would go into config, but wouldn't work for login.

According to the documentation for enable secret a password must not begin with a number and ? has to be entered as Ctrl-V then ? to escape it.

I followed that and still got passwords I could not use sometimes. There was no error when I ran username, but the password would be rejected on login by some, but not all of the switches. They are all WS-C2960-48PST-L. The passwords it didn't like contained back ticks "`" (that character under tilde ~ under Esc).

The "misbehaving" switches are running:

Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 12.2(50)SE5, RELEASE SOFTWARE (fc1)

The "working" switches are running:

Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 12.2(46)SE, RELEASE SOFTWARE (fc2).

The "misbehaving" switches are running a newer IOS, so this suggests a regression introduced somewhere between 12.2(46)SE and 12.2(50)SE5. I was unable to find any evidence of this being intentional in the release notes for 12.2(50)SE.

I would like to avoid this next time the passwords are changed :)

What characters are illegal in Cisco IOS username secret passwords?

Thank you for your help :)


Each type of password is case sensitive, can contain from 1 to 25 uppercase and lowercase alphanumeric characters, and can start with a numeral. Spaces are also valid password characters; for example, "two words" is a valid password. Leading spaces are ignored, but trailing spaces are recognized.

Taken from: http://www.cisco.com/en/US/docs/ios/preface/usingios.html

According to the documentation there aren't that many restrictions for creating passwords. Does a show login create a log for failed logon attempts? Is it possible that users are typing the passwords incorrectly?

  • Good eye. I didn't make the connection that the rules I was reading applied specifically to the enable password. Thank you Rowell :) – Alain O'Dea Nov 11 '11 at 18:24

I ran into a similar problem for a previous employer.

Instead of continually fighting with the issue I opted to go for strictly alphanumeric password. You do loose a couple bits of entropy in your password by going strictly alphanumeric but that is easy enough to compensate for by adding an additional two to three characters to your password.

This may not be possible based on your policies but I found it to be the cleanest solution for that hardware you couldn't trust with special characters. We actually worked up a dedicated clause for these devices based on maintaining a minimum amount of entropy instead of the standard 1 letter / 1 number / 1 symbol spiel.

  • I like that solution Tim. I discussed something similar with an information security expert a while back. It was something to the effect of basing the time between required password changes on the complexity of the password. Going into entropy calculations would make that even more effective. Thank you :) – Alain O'Dea Nov 11 '11 at 18:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.