Device out of sync - Password clear vs encrypted

[yale.prince@leidos.com]

Hi all,

can someone pls recommend the best way in which to handle the following

i have and snmp services in NSO that will go configure snmp users and there passwords on my target devices

how ever after applying the services its instantly out of sync.

i'm passing the password in clear text and the box is encrypting it which is what i would expect but that is detected as a change in config and the device goes out of sync

see attached

i had a similar issue when creating a VRF the end device would add some default multicast config that put the box out os sync, my work around was to include the default config that the device applied to its self in the template, but that approach won't work for the above

is there a best practices for handling occurrences such as this ?

Thanks

Yale

[joepak]

What would happen after you sync-from?

[kristian.larsson1]

This is a classic issue. One of the basic tenets of NETCONF is that the device is not allowed to mutate the configuration in the running datastore, yet this is exactly what happens in this case. It is very common that devices do this, in particular for:

* hashed passwords, for like user accounts on the device

* routing secrets, like bgp passwords, which are encrypted

One way of dealing with this is to simply generate all the content in NCS instead of sending it cleartext. It seems you are using a Cisco Nexus which I presume is using the standard hashing and encryption that cisco devices are typically using.

Passwords on Cisco IOS XR is based on Poul-Henning Kamp modified MD5 hashing which he originally wrote for FreeBSD. Those are easy to generate, for Python there's passlib:

from passlib.hash import md5_crypt

clear = "foobar"
cisco_5 = md5_crypt.using(salt_size=4).hash(clear)

For the "type 7" passwords which are encrypted using a vigenere crypto and a cisco static key (which was reverse engineered many years ago) you can generate those yourself. Here's somee code to do it: https://github.com/plajjan/pyvigenere/blob/master/pyvigenere.py

Similarly for JUNOS you have the same password hashes but with a 8 byte salt. Routing passwords are encrypted with a juniper proprietary algorithm instead but it is still known.

Some NEDs, like the alu-sr cli NED, ignore these types of changes so you won't end up out-of-sync even if you write cleartext and get back encrypted. This could be an option too but you would have to bring it up with your NED developer.