MAS Auto Config questions

[joel.mccotter]

I've been testing Auto Config on these switches, using 7.2.2.1 on my test bed.  The Auto Config process itself is working fine, using DHCP option 150, and placing a config file with the serial number as the name in the root folder of the TFTP server.  The switch pulls down the config file fine and applies it.

Where I'm having issues is being able to SSH into a switch after running auto-config.  Any values in the config file that are hashed, such as local user passwords, radius shared secrets, etc wouldn't be known for a switch that is brand new out of the box since they appear to be unique to each switch, so I wouldn't be able to place these hashed values in the config file on the TFTP server.  Obviously putting these items in plain text in the config file isn't necessarily very secure, though I tried that too and it didn't work.

I removed anything from aaa authentication mgmt to do away with any problems with the RADIUS shared secrets, and I'm looking down the path of just logging in using a local-user account.

I'm trying to figure out how to go about taking a switch out of the box, plug it in, let it pull down its config, and then be able to SSH into the switch, without any hand touching.  It would be ok if I was able to SSH into the switch and run a few commands after the fact to lock it down, but the simple act of remoting into the switch is what's stopping me.

Thanks!

[cappalli]

If you are willing to have the password in plain text, you can try adding
encrypt disable to the config and then adding the plain text passwords.

[joel.mccotter]

Cool I'll try that out. Would probably do a temporary local user password, then log in and enable encryption, change password and set shared keys. Will report back once I test it.

Thanks

[joel.mccotter]

Sorry, meant to say mgmt-user, not local-user.  

I may be showing some ignorance on how password hashing works but it appears I can interchangeably use hashed passwords from different switches.  I copied the "mgmt-user admin root" line with a unique hash from another switch in production to my test config and it worked just fine after letting it run through auto-config again.  

encrypt disable didn't seem to have any effect - looks like that just affects how the password is displayed on screen and not how it's stored in the config file.

[madjali · Accepted solution]

Joel,

The ability to copy passwords between devices is not unique to Aruba. The reason it works is that the password field contains the random "salt" values, the encryption identifier and the hashed password which was created as a result of the salt and encryption algorithm. So when there is a new authentication request, the system looks up the user-id and if it exists uses the random "salt" value to generate a hash of the newly provided password to compare against the stored password hash. Since the same salt and algorithm will be used, it should therefore result in the same hash. If it does, we have a match and the device accepts the user, if it doesn't match then the passwords do not match and we deny the user.

Best regards,

Madani

[joel.mccotter]

Thanks Madani, good to know - auto config seems to work well.  Seems like an obvious question - just haven't deployed configurations in this manner with our prior switch vendor.