07-17-2013 04:52 PM
I've been testing Auto Config on these switches, using 18.104.22.168 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.
Solved! Go to Solution.
07-17-2013 05:00 PM
07-17-2013 06:46 PM
07-17-2013 08:58 PM
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.
07-20-2013 12:56 PM
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.