12-22-2020 12:53 PM
I'm attempting to create a template for creating an NSO local user. For the secret, I want to copy paste and already encrypted value from an existing device to be used. The issue is that when I see the dry-run, NSO think's the encrypted value is using tailf encryption and thinks it needs to decrypt it. NSO does not realize this is using the devices encryption and should be sent to the device "as-is". Is there a way to send/store this value without NSO attempting to decrypt it?
sam@nso# show running-config devices template nso-user devices template nso-user ned-id cisco-ios-cli-6.67 config username nso algorithm-type sha256 secret type 8 secret secret $8$O/PPSu1pU/p4I.$tRl9TI7xVahHlivoO0pfNdsSy2UVYB3VMw9VGxo4ifM ! ! ! ! sam@nso# config Entering configuration mode terminal sam@nso(config)# devices device device1 apply-template template-name nso-user apply-template-result { device device1 result ok } sam@nso(config)# commit dry-run outformat native native { device { name device1 data ! meta-data :: /secret :: maapi-encrypted username nso algorithm-type sha256 secret 8 $8$O/PPSu1pU/p4I.$tRl9TI7xVahHlivoO0pfNdsSy2UVYB3VMw9VGxo4ifM } }
12-22-2020 01:30 PM
12-23-2020 07:15 AM
Hi Viktor, I had tried that, as a colleague said that works for using special characters in NSO, however it does not work for me here.
sam@nso(config)# devices device device1 apply-template template-name nso-user apply-template-result { device device1 result ok } sam@nso(config)# commit dry-run outformat native native { device { name device1 data username nso secret 8 $0$$8$O/PPSu1pU/p4I.$tRl9TI7xVahHlivoO0pfNdsSy2UVYB3VMw9VGxo4ifM } } sam@nso(config)# show full-configuration devices template nso-user devices template nso-user ned-id cisco-ios-cli-6.67 config username nso secret type 8 secret secret $0$$8$O/PPSu1pU/p4I.$tRl9TI7xVahHlivoO0pfNdsSy2UVYB3VMw9VGxo4ifM ! ! ! ! sam@nso(config)# commit Aborted: External error in the NED implementation for device device1: command: username nso secret 8 $0$$8$O/PPSu1pU/p4I.$tRl9TI7xVahHlivoO0pfNdsSy2UVYB3VMw9VGxo4ifM : ERROR: The secret you entered is not a valid encrypted secret. To enter an UNENCRYPTED secret, do not specify type 8 encryption. When you properly enter an UNENCRYPTED secret, it will be encrypted.
It looks as though NSO thinks the it is a string that starts with $0$, instead of using $0$ to denote that what follows should be the string and to not interpret what follows as tailf:encryption.
01-05-2021 11:01 AM
hi Samuel,
I would configure the target device with your target password and do a Sync-from to check how the NED is representing it. The template should have the same format. Be aware of some changes in recent releases on how to deal with passwords that start with the "$" character.
From NSO 5.5 CHANGE file:
- ncs: Encrypted strings that is of type tailf:aes-256-cfb-128-encrypted-string starting with "$", are now
accepted as input.
This reverts the earlier change that rejected such input, as this caused
issues with how some devices handles strings.
(ENG-24718)
01-05-2021 11:50 AM - edited 01-05-2021 11:51 AM
Hi Rogaglia,
I'm using NSO version 5.3.1.1 currently, not certain how large the difference between the two are. NSO 5.3.1.1 does accept strings starting with "$", but it is not a tailf:aes-256-cfb-128-encrypted-string.
I attempted what you said, configuring the username on the device, and then performing a sync-from. Below are my results.
user1@nso(config)# devices device my_device user1@nso(config-device-my_device)# sync-from user1@nso(config-device-my_device)# show full config username nso devices device my_device config username nso secret 8 $8$aCV/3E4pEUFIg.$k0LFhU5GLQbdm/KpQz2GFQfISy812cpx3kdLlQR0BSw ! ! user1@nso(config-device-my_device)# live-status exec any "show runn | in username nso" result username nso secret 8 $8$aCV/3E4pEUFIg.$k0LFhU5GLQbdm/KpQz2GFQfISy812cpx3kdLlQR0BSw my_device# user1@nso(config)# devices template local-user-test ned-id cisco-ios-cli-6.67 config user1@nso(config-config)# username nso secret type 8 secret $8$aCV/3E4pEUFIg.$k0LFhU5GLQbdm/KpQz2GFQfISy812cpx3kdLlQR0BSw user1@nso(config-username-nso)# commit user1@nso(config-username-nso)# show full devices template local-user-test ned-id cisco-ios-cli-6.67 config username nso secret type 8 secret secret $8$aCV/3E4pEUFIg.$k0LFhU5GLQbdm/KpQz2GFQfISy812cpx3kdLlQR0BSw ! ! ! ! user1@nso(config-username-nso)# top user1@nso(config)# devices device my_device apply-template template-name local-user-test apply-template-result { device my_device result ok } user1@nso(config)# commit dry-run outformat native % No modifications to commit. user1@nso(config)# no devices device my_device config username nso user1@nso(config)# commit no-networking Commit complete. user1@nso(config)# devices device my_device apply-template template-name local-user-test apply-template-result { device my_device result ok } user1@nso(config)# commit dry-run outformat native native { device { name my_device data ! meta-data :: /secret :: maapi-encrypted username nso secret 8 $8$aCV/3E4pEUFIg.$k0LFhU5GLQbdm/KpQz2GFQfISy812cpx3kdLlQR0BSw } } user1@nso(config)#
So NSO doesn't know the difference. In the trace NSO fails to maapi decrypt, and sends the string as is, so it works. It seems strange though that we have to rely on the failure to decrypt for proper function (from how I understand it). The other thing is since NSO understands $8$ to be tailf encryption, and device encryption is also stored as $8$ (as seen above), this means that on a rollback where NSO configures the username and secret to what is was (previously stored on the device), NSO thinks the string is tailf encrypted and tries to decrypt it (fails again, and sends string as is - so no issue yet).
So it fails because it's AES in NSO and SHA256 on the device, but if the output of the hash ever is matched by AES, then it would "decrypt" and send some random value to the device. So I don't think it will probably be a problem, as md5 and scrypt use a difference $num$, and I'm guessing SHA256 will never output a base-64 value for AES to accidentally recognize it and "decrypt" it.
I'm trying to figure out if this is an issue to be concerned about, and if I'm fully wrapping my head around it. Thought it'd be easiest to just tell NSO that it's a string and not tailf encrypted.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide