Security

I'm new to the Aruba MAS and am looking to figure out whether there is an equivalent to the cisco-ish

"copy flash: <file> running-config" command which takes a flash file and essentially pastes it as though

it were typed at the CLI, with some sensible special behavior surrounding anything interactive.  Note for

those unfamiliar with Cisco, this command does NOT erase anything that is in the running-configuration.

That's my general question.  This is my more specific question:

It was my hope that I would be able to use such a thing to paste mgmt-user entries into the configuration,

since the CLI does not allow you to enter the crypt, nor even enter the password non-interactively.  I need

to be able to paste other employees' passwords into the switch config without seeing the cleartext

password.  The same question applies to various aaa secrets and keys.  Though you can paste these in

non-interactively, the password is set to the crypt, not to the original value.  Under most other cisco-like

systems one precedes the crypt with a number designating what kind of crypt is being entered (or cleartext).

This syntax seems not to be accepted on the MAS.

What do other Aruba users do to acheive equivalent functionality?

have you tried preceding the show run with "encrypt disable"?

This will output the file without the hashes on these items

Seth,

Yes I've played with that option.  It doesn't get me where I need to be.  Also it doesn't work for mgmt-user, which is a good thing.

I need to be able to paste in configuration items that have the salted hash.  In the case of mgmt-user I have to be able to paste in passwords that I do not and should not know myself.  For the case of keys and secrets, configuration fragments stored off the switch are less useful to someone that happens to find them during a security breach if they do not have naked passwords in them, which is kind of the point of the whole salted hash exercise.

As an aside, if the crypts shown can't be pasted back in, you might as well just show "XXX", because they do not serve any useful purpose otherwise.  A nefarious person that came by a copy of a fleet of configuration files would have an easier time cracking the hash if they had multiple, differently salted crypts for what is more than probably the same password, than they would if the salt was always the same (so long as the salt was not so well known such that dictionaries were already available.)

bjulin,

Why don't you try "backup flash" and "restore flash"?  http://www.arubanetworks.com/techdocs/ArubaOS_73_Web_Help/Default.htm#mas_guides/1command_List/backup.htm?Highlight=backup flash

Thanks, cjoseph.

However that, or any other scheme that basically edits the startup-config, requires the switch to be reloaded.  I can't be reloading switches just to change passwords.

Two reasons:

1) As a general policy, administrative accounts that can alter network configuration do not use SSO facilities

2) It does us no good to be able to auth off RADIUS when we are consoled into a stranded switch at the rack.

We do like to have individual accounts on these devices for accountability and debugging reasons, so we can see who issued the commands.  If, in the case of 2) we just had one emergency account, every time we take that password out of the sealed envelope we store it in, we change it systemwide.