Cisco ASA Lost SSH to Active on Failover

[phmazzoni]

Hello,

I am having a curious problem with two Cisco ASA 5550. They are configured in Active/Standby failover and in routed mode.

The problem is: I cannot connect via SSH to the ACTIVE unit, only to the STANDBY. If a switchover is forced the problem is still the same.

Please note that is probably not a hardware issue, because it happens both with the primary and the secondary unit.

It is not a L2 or a transport problem, because I can ping or access both units via ASDM.

Any ideas?

Thanks in advance,

Pedro Mazzoni

[Jitendriya Athavale]

what code are you running, we have seen some issues with this

please paste the output of

show asp table socket

also see if you can reboot the devices (reload the standby device, it will not affect your network, after the standby is reloaded failover and try with the active ip for this device)

[phmazzoni]

Thanks Jathaval!

Below is the output of "show asp table socket":

Primary

Protocol   Socket    Local Address               Foreign Address         State

SSL        0002189f  10.223.246.140:443          0.0.0.0:*               LISTEN

TCP        00022a8f  172.30.24.103:22            0.0.0.0:*               LISTEN

SSL        00023a4f  172.30.24.103:443           0.0.0.0:*               LISTEN

SSL        0016d138  10.223.246.140:443          10.121.12.102:2259      ESTAB

Secondary

Protocol   Socket    Local Address               Foreign Address         State

SSL        0009e9af  172.30.24.104:443           0.0.0.0:*               LISTEN

SSL        0009faef  10.223.246.141:443          0.0.0.0:*               LISTEN

TCP        000a1d1f  10.223.246.141:22           0.0.0.0:*               LISTEN

TCP        000a32cf  172.30.24.104:22            0.0.0.0:*               LISTEN

SSL        000c9fd8  10.223.246.141:443          10.121.12.102:2263      ESTAB

The interface that we are trying to connect has the following IP address:

ip address 10.223.246.140 255.255.255.0 standby 10.223.246.141

As we can see, the ACTIVE daemon is not running or does not bind to the TCP/22.

Thanks again,
Pedro Mazzoni

[phmazzoni]

I am running the asa823-k8.

[Jitendriya Athavale]

try the following

remove all ssh config and configure ssh config again

if that doesnt work try the reload, i have seen issues on 8.2.3

[phmazzoni]

OK, I am trying this. Do you know if this have a related bug record?

Do you recommend other version of software?

Thanks,
Pedro Mazzoni

[Jitendriya Athavale]

i didnt do a through check but found this CSCti72411

so as i said try this

remove all ssh config and put them back in including the keys after zerorizing them

if that does not help try reload

[subflava]

I've also run into this exact issue with a pair of ASA 5510's in Active/Passive failover mode.  Once I initiate a failover to the standby unit, I lose SSH connectivity to the active member.  Even if I then fail back to the original configuration, the problem still occurs on whichever unit is the active one so it does indeed appear to be a software problem.

I was able to workaround the issue by removing all SSH configurations and then re-adding them.  I guess this somehow resets the SSH service?

Mike

[tgronke]

I confirm removing and rebuilding all SSH admin config and RSA keys restored SSH access in my case.  Reboot was not required, but I haven't checked how long this fix will work.

My problem was SSH access to an ASA that is normally standby ASA was lost after upgrade of both active and standby firewalls from 8.0(4) to 8.3(2).  The normally active ASA was not affected.  Initially, a reboot of the problem firewall restored SSH access, but that quit working after a few hours -- telnet and ASDM access continued to work..  As others reported, the output of 'sh asp table socket' appears to show a normal listener on TCP port 22.  When I tried 'telnet 22' from a command prompt, I received an initial response, but no SSH banner.

Likely unrelated, but the problem firewall also had a file system problem where the disk0 system was in read-only mode, preventing me from uploading code.  At Cisco's direction, the 'fsck disk0' command returned the file system to read/write status.