Cisco Ios-xe Type 6 Password

[Carlee Members]

Ideallywe want our customers to be leveraging a centralized AAA model, with individual members of the support team all having their own unique accounts, while granting them the minimum permissions required to fulfill their job functions. All sessions should be centrally logged and performed over a secure encrypted connection (SSH not telnet right!), and that unused management protocols are disabled (HTTP/HTTPS). Finally, we want to ensure that these management sessions are only permitted from trusted networks/subnets or from a fortified bastion host.

With that being said, there are occasions when local authentication can be advantages, such as for console connections or in the event of our centralized AAA servers not being accessible. I generally recommend that customers keep local accounts to a minimum and that their credentials are kept locked away, only do be used when absolutely necessary.

Lesson Learned: Service Password Encryption does not help us. It only thwarts the casual shoulder surfer. To all intents and purposes our passwords are still stored in plain text for anyone with access to our configs.

Then came Type 5 passwords. This was a big improvement over our previous two options. Passwords are combined with a random salt value and have a one-way MD5 hash function run over them. The salt value ensures that two identical passwords will have different hash outputs (see USER3 & 4 screenshot below), the salt also acts as a protection against attackers using simple precomputed hash table (known as rainbow tables) cracking.

Up until recently that is where the story would end. Enable Secrets with it's salted MD5 hashes was the preferred way to store local credentials in our Cisco devices. But time waits for no man or woman, and advances in chipsets and processing power continue to advance which results in our old algorithms becoming increasingly susceptible to compromise. And that is where we are with MD5 today. We needed something new to protect our passwords and that is where Type 8 and 9 come into the picture.

These new kids on the block were introduced in IOS 15.3(3)M which came out way back in July 2013. Although they have been available for a long time I very rarely see customers utilizing these algorithms in their configurations. This might have something to do with another password encryption method (Type 4) which was touted by Cisco back in the day to be the successor to Type 5. Things did not go to plan, and Cisco ended up with a little egg on their faces and had to pull code that supported type 4 encryption. But that might have to be a story for another day.

Lesson Learned: Type 9 is how all your local account passwords should be secured. Remember a stronger algorithm is no substitute for implementing a strong password policy, so keep those passwords random and rotated often.

Traditionally Cisco has used several different methods for storing passwords and keys in IOS. The older methods are Type 5 (MD5 hash) & Type7 (Vigenere obfuscation). We enabled Type 7 encryption with the CLI service password-encryption command.

The super-secret-password you used is very important. It's very important that you store the key somewhere offline. Be sure to keep in it KeePass, or 1Password or the password vault of your choice. Optimally each device you configure Type 6 on will have a unique Key.

But have you any idear how to change the password type to 6 on cat 2960X Switch, especially the keys in the Radius and TACACs section? Because its working for the username password but not for the Radius and TACACs Key... I have to remove the keys in the section and create a new key 6 entry and the hash I got from a working 9XXX Switch. But I dont think this is the correct way to do it, right?

No, I don't think the way you are doing it with the 2960 is the way to do it. I'm actually a little surprised it is converting your username password combo. I just tried the same with a 3750X w IOS 15.2(4)E7 and nothing was converted, not the username password and not the RADIUS or TACACS keys.

Do you have any idea why your instructions do not work on a C1000-8P-E-2G-L with 15.2(7)E6? The switch does not know the command "password encryption aes" nor "key config-key password-encrypt" in config mode.

I'm wanting to convert all my type 7 password right now and trying to figure out the best way to go about this. I want to use type 8 or 9 for my local "username" passwords and type 6 for my radius shared keys (as type 8/9 is not available for radius shared keys). Is this possible to use both in the same switch config?

If you can use both, and I've already converted my "username" command passwords to type 8 or 9, will entering the "password encryption aes" and "key config-key password-encrypt super-secret-password" commands convert those username password to type 6 or will it continue to use type 8/9 for "username" and only convert the radius shared keys to type 6?

You may have already answered this in the Q&A in you post and pasting below, but just wanted to confirm what to expect. Sounds like it should keep the local "username" passwords as 8 or 9 and only convert my radius server keys?

Type 8 is a HASH - which cannot be reversed back to the original plain-text and therefore cannot be used for something like radius. Type 8 is suitable for a user secret where the stored hash gets compared to the hash of what a user enters.

IOS converts it to type 6 in config but then reads it as type 7 so it breaks service. The workaround is to explicitly configure it with type 7 *after* you have enabled AES encryption and then it keeps working because IOS doesn't convert it.

@toormehdi ...

> Does this master key needs to be on the target box prior to pasting in or could it be entered after ? Trying to understand the order of operations.

- Yes the encrypted format can be copied and will work as long as and when the same master key is used. It can be entered before or after.

> Could there be a situation where a pasted config with encrypted password ends up getting encrypted twice ? Assume a newer or different router model or higher IOS version ?

- No, IOS will not re-encrypt a key/password already in type 6.

> Is there a way to decrypt the keys/password with the master key. Is there a tool on or off box ?

- Not that I know of although it would be theoretically possible if you had the Cisco algorithm and the key.

>Also noticed on ios xe some keys we created for PSKs just go in literally without getting encrypted even though aes password encryption is turned on ? What could be the reason for such behaviour ?

- AES encryption started with things like VPN keys and has gradually been extended to other passwords and keys in newer IOS versions. You still need "service password-encryption" for everything else.

Netmiko is a multi-vendor SSH Python library which makes connecting to network devices via SSH really easy and straightforward. The library simplifies SSH management to network devices is based on the Paramiko SSH library.

The question is: if we have Paramiko, why would be need something like Netmiko. As it turns out, Paramiko can sometimes be quite hard to work with. Netmiko is hiding many details of common devive communication. It uses Paramiko for the underlying SSH connectivity, but provides a higher abstraction for the communication with networking devices.

Disclaimer: this is not production-grade code obviously. One should never store the username and password in the clear, not in the source code itself. The examples in the post are merely conceptual and for informational purposes.

In the above example, we were using a "device_type": "cisco_xe". How do we know what device type to use and how do we know which devices are supported. Probably the easiest (albeit a little strange) method is to specify a wrong device type. In the example above, replace the following snippet:

We will essentially change the interface description of a particular port. It follows the same approach as the previous example. We store the devices in a list of dictionaries and we loop over them in a for-loop. Inside the for-loop, we use the send_config_set method (see documentation here). At a minimum, we need to pass the config_commands, which is an iterable contain all of the configuration commands. Hence, we have created a list called description_config which contains a list of all the commands we want to execute (in order).

The Jinja2 file is relative straightforward as well. Essentially, we use a for loop to iterate over the loopback interfaces. Each time, we use the data that is passed to this template from the Python file.

The Python file is first reading in the host information from the hosts.yml file. The interface information we read from the YML file. The host and interface information is now available to us in a Python dictionary.

Next, we simply loop over the devices (hosts) and for each host we create an SSH connection via Netmiko. And finally we use the send_config_set method to which we pass the loopback_config information (which contains nothing more than the commands to configure a loopback interface).

All the Cisco IOS XE modules are included in Ansible Core so no aditional effort is required to begin automating your Cisco IOS XE devices. As Ansible has an agentless architecture, once username and password are configured/provided, then the devices can be managed through Ansible. The username provided with the playbook must have the requisite role privilege to allow device configuration changes.

The host file is where the devices under management are listed. A single device can be in a single group or included in multiple groups. In the below hosts file we have two groups called cat3k and cat9k, whit two and three devices respectively. which has 3 devices, cat9k1, cat9k2 and cat9k3. Groups can be nested like the ios-xe group in the example which includes both cat3k and cat9k groups. The default connection is set to network_cli, which replaces the connection local starting with release 2.5.

3a8082e126