Security

I have been using MobaXterm as my SSH client for many months, with mostly no problems. Good thing I've kept PuTTY installed "just in case"

 

On Tuesday I was able to SSH in to my Cisco gear - which all look to CPPM for RADIUS auth - and then last thing Tuesday I patched ClearPass.

 

Being snowed-in meant I couldn't test on Wednesday.

 

Thursday I couldn't connect from MobaXterm's SSH client, but PuTTY could. I just realized that the change coincided with the patch.

 

Anyone got an idea what to troubleshoot first?

Hi,

It's unusual that one SSH client works and the other fails to authenticate with that message. Are there any configuration differences between the SSH clients?

Also, I'd recommend to us TACACS+ instead of RADIUS for admin user authentication. ;) But that's a different matter.

Now we have two SSH clients failing - on Cisco 1941 and 2960, but not ASA or non-Cisco gear.

I'm queued up for TAC now.

 

I'll let you all know what we get.

TAC gave me a quick and straight forward answer:

This is expected and is mentioned in the Release notes(http://www.arubanetworks.com/techdocs/ClearPass/CP_ReleaseNotes_6.6.3/Default.htm#WhatsNew/ImportantChanges.htm?Highlight=35712) . 

Seems I hadn't realized my Cisco switches and routers make those malformed requests when I use MobaXterm or the SolarWinds SSH clients, yet not when I use PuTTY.

 

Anyone know how to "fix" a cisco RADIUS request?

..

Oops duplicate post

I'd love to, but I need to manage them to change the auth methods.

Can't manage them if I can't connect from the management platform.

 

I've asked TAC for a workaround, or to tell me how to roll-back to patch 2 while we fix the Cisco side of the equation.

Ouch. Disabled all local auth?

I guess it's a lot of devices to console into or role back cppm.

@msabin any update on your situation?

We've gone with:

1. Build two new VMs and patch to 6.6.2
2. Restore backup from morning of the upgrade
3. export guest users database from 6.6.3 system
4. switch 6.6.3 VMs out and 6.6.2 VMs in
5. restore guest users database
6. back in business!

The issue is in the Cisco interpretation of the RFC for RADIUS, Aruba has (I think) correctly interpreted that there is no reason for a "reply-message" attribute to be in the initial auth-request and so now CPPM rejects requests with the erroneous attribute.

Cisco is claiming that since the response request was made by my SSH client (acceptable from client to NAD, just not froim NAD to NAS) they are obliged to pass the attribute up.

We're working with Cisco to get the equipment to conform to the standard (probably have to filter the attribute) and we'll push that configuration out then re-upgrade CPPM.

 

Whew!

Nice explanation and thanks for the update.

 

Now back to the Tacacs discussion @jrwhitehead :-)

TAC/Engineering report that they have added an option to toggle enforcement of the RFC in 6.6.4.

I'm still holding Cisco's feet to the fire to fix their request, but deeply apprecaite Aruba making allowances for their (Cisco's) failings.

Expect my report on testing in a few days.

 

Thanks TAC!!

The final word from Cisco: my our problem, your RADIUS vendor is mistaken, talk to your account rep to request us to care, or words to that effect.

I'll install the Aruba patch and tick the box to let me continue with poorly behaved gear and let you know how it works.

Use TACACS+ instead. :)