Solved: Re: Cisco ASA ssh not connecting with cipher error

DavidM0567 · ‎03-24-2020

I am unable connect to the Cisco ASA 5512-X with ssh or asdm. I can telnet to it. This issue occurred following wiping the configuration to clear a password when password recovery was disabled. Debug shows "cipher not supported" but it is listed as a cipher in "sh ssh ciphers". Does anyone know what I can do to fix ssh and asdm?

Thank you,

smc-asa# sh ver

Cisco Adaptive Security Appliance Software Version 9.12(3)9
SSP Operating System Version 2.6(1.192)
Device Manager Version 7.13(1)

smc-asa(config)# ssh 0.0.0.0 0.0.0.0 inside

smc-asa(config)# ssh version 2
smc-asa(config)# ssh key-exchange group dh-group14-sha1
smc-asa(config)# crypto key generate rsa modulus 2048
WARNING: You have a RSA keypair already defined named <Default-RSA-Key>.

Do you really want to replace them? [yes/no]: yes
Keypair generation process begin. Please wait...
smc-asa(config)# Device ssh opened successfully.
SSH0: SSH client: IP = '172.16.87.2' interface # = 2
SSH: host key initialised
SSH0: starting SSH control process
SSH0: Exchanging versions - SSH-2.0-Cisco-1.25

SSH0: send SSH message: outdata is NULL

server version string:SSH-2.0-Cisco-1.25
SSH0: receive SSH message: 83 (83)
SSH0: client version is - SSH-2.0-PuTTY_Release_0.66

client version string:SSH-2.0-PuTTY_Release_0.66

SSH2 0: send: len 360 (includes padlen 7)
SSH2 0: SSH2_MSG_KEXINIT sent
SSH2 0: input: packet len 672
SSH2 0: partial packet 8, need 664, maclen 0
SSH2 0: ssh_receive: 204 bytes received
SSH2 0: partial packet 8, need 664, maclen 0
SSH2 0: input: padlen 10
SSH2 0: received packet type 20

SSH2 0: SSH2_MSG_KEXINIT received
SSH2 0: matching cipher is not supported: aes256-ctr
SSH2 0: ssh: kex_choose_conf error
SSH2 0: key exchange failed to completeSSH0: Session disconnected by SSH server - error 0x00 "Internal error"

smc-asa# sh ssh ciphers
Available SSH Encryption and Integrity Algorithms
Encryption Algorithms:
all: 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr
low: 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr
medium: aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr
fips: aes128-cbc aes256-cbc
high: aes256-cbc aes256-ctr
Integrity Algorithms:
all: hmac-sha1 hmac-sha1-96 hmac-md5 hmac-md5-96 hmac-sha2-256
low: hmac-sha1 hmac-sha1-96 hmac-md5 hmac-md5-96 hmac-sha2-256
medium: hmac-sha1 hmac-sha1-96 hmac-sha2-256
fips: hmac-sha1 hmac-sha2-256
high: hmac-sha2-256

Marvin Rhoads · ‎03-26-2020

Is that coming from the ASA? I think so because the source is a Cisco MAC address. In the capture we see:

TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)

That usually indicates the client didn't propose any acceptable cipher suites in the Client Hello. We would normally expect something like this from the client:

...after which the server replies with its hello and proposes the strongest mutually supported cipher suite for the conversation going forward:

If there is no overlapping cipher suite available, the ASA will reply with a handshake failure.

View solution in original post

Marvin Rhoads · ‎03-24-2020

I've seen people using an old Putty client version that doesn't support the DH Group 14 and other settings. According to your debugs the client that's failing is using Putty 0.66 (from 2015). Can you update the Putty and check?

DavidM0567 · ‎03-25-2020

I upgraded to the latest putty version (0.73) but I was still unable to connect. I am also unable to connect with ASDM or access the web interface.

HTTPS in Chrome to the ASA IP gives the message:

This site can’t provide a secure connection 172.16.1.1 uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH

smc-asa# debug ssh
debug ssh enabled at level 1
smc-asa# Device ssh opened successfully.
SSH0: SSH client: IP = '172.16.87.2' interface # = 2
SSH: host key initialised
SSH0: starting SSH control process
SSH0: Exchanging versions - SSH-2.0-Cisco-1.25

SSH0: send SSH message: outdata is NULL

server version string:SSH-2.0-Cisco-1.25
SSH0: receive SSH message: 83 (83)
SSH0: client version is - SSH-2.0-PuTTY_Release_0.73

client version string:SSH-2.0-PuTTY_Release_0.73

SSH2 0: SSH2_MSG_KEXINIT sent
SSH2 0: SSH2_MSG_KEXINIT received
SSH2 0: matching cipher is not supported: aes256-ctr
SSH2 0: ssh: kex_choose_conf error
SSH2 0: key exchange failed to completeSSH0: Session disconnected by SSH server - error 0x00 "Internal error"

Thank you

Marvin Rhoads · ‎03-25-2020

Check that your wipe didn't also clear your 3DES-AES license on the ASA:

show version | i 3DES

If it's not active, then go to software.cisco.com and request a new (free) 3DES-AES license from the traditional licenses section.

DavidM0567 · ‎03-25-2020

ASDM and https are still not connecting buy SSH is now working. Thanks for the fix to SSH. Do you know why ASDM and https would still be failing?

Thank you

smc-asa# sh ver | i 3DES
Encryption-3DES-AES : Disabled perpetual

I was able to submit a request for a license key from:

https://slexui.cloudapps.cisco.com/SWIFT/LicensingUI/Quickstart#

I received the key in an email and applied it on the ASA

smc-asa(config)# activation-key 00000000 00000000 00000000 00000000 00000000

Validating activation key. This may take a few minutes...
Failed to retrieve permanent activation key.
Both Running and Flash permanent activation key was updated with the requested key.

smc-asa(config)# sh ver | i 3DES
Encryption-3DES-AES : Enabled perpetual

Marvin Rhoads · ‎03-25-2020

ASDM and https depend on having several things in addition to the 3DES-AES license:

1. a valid ASDM image on disk0

2. an "asdm image" statement in the config referring to the image

3. http server enabled (it's actually TLS but the http command is there from decades ago)

4. http being explicitly allowed on the interface that the traffic arrives with the address or network of the client allowed.

The following commands will confirm those:

dir disk0:
show run asdm
show run http

DavidM0567 · ‎03-25-2020

I've confirmed the asdm file is on disk0: and that the asdm image is mapped to it. I've tried different version of asdm but receive the same results. http is enable for all IPs on the inside interface.

The https connection gives an error:

This site can’t provide a secure connection172.16.1.1 uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH

smc-asa# sh disk0:
--#-- --length-- -----date/time------ path
42 103071744 Mar 23 2020 13:44:56 asa9-12-3-9-smp-k8.bin
43 34033084 Mar 23 2020 13:46:08 asdm-7131.bin
46 82593792 Mar 24 2020 10:46:59 asa952-smp-k8.bin
48 111624192 Mar 24 2020 11:03:34 asa984-17-smp-k8.bin
54 32738244 Mar 25 2020 12:59:07 asdm-792-152.bin

4118085632 bytes total (3753959424 bytes free)

smc-asa# sh run asdm
asdm image disk0:/asdm-792-152.bin
asdm history enable

smc-asa# sh run http
http server enable
http 0.0.0.0 0.0.0.0 inside

Marvin Rhoads · ‎03-25-2020

Can you run wireshark while trying to connect via https? Capture filter on the ASA address and then display filter on tcp.port==443.

You should see a cipher spec exchange and which side is not working will be confirmed.

DavidM0567 · ‎03-26-2020

There was a "client hello" followed by this message. I didn't see anything that mentioned cipher spec exchange specifically. Is this the message you expected to see? It's using TLS 1.2. Is there something more that I should be getting from this message?

Thanks

311 3.425332 172.16.87.10 172.16.84.188 TLSv1.2 61 Alert (Level: Fatal, Description: Handshake Failure)

Frame 311: 61 bytes on wire (488 bits), 61 bytes captured (488 bits) on interface \Device\NPF_{D1A3B5DD-3207-4036-BB7A-8D425BB0DF6B}, id 0
Interface id: 0 (\Device\NPF_{D1A3B5DD-3207-4036-BB7A-8D425BB0DF6B})
Encapsulation type: Ethernet (1)
Arrival Time: Mar 26, 2020 10:39:56.044911000 Eastern Daylight Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1585233596.044911000 seconds
[Time delta from previous captured frame: 0.000287000 seconds]
[Time delta from previous displayed frame: 0.000287000 seconds]
[Time since reference or first frame: 3.425332000 seconds]
Frame Number: 311
Frame Length: 61 bytes (488 bits)
Capture Length: 61 bytes (488 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:tcp:tls]
[Coloring Rule Name: TCP]
[Coloring Rule String: tcp]
Ethernet II, Src: Cisco_b7:3e:40 (50:87:89:b7:3e:40), Dst: VMware_d5:79:73 (00:0c:29:d5:79:73)
Destination: VMware_d5:79:73 (00:0c:29:d5:79:73)
Source: Cisco_b7:3e:40 (50:87:89:b7:3e:40)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 172.16.87.10, Dst: 172.16.84.188
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 47
Identification: 0x80e9 (33001)
Flags: 0x0000
Fragment offset: 0
Time to live: 255
Protocol: TCP (6)
Header checksum: 0x36f8 [validation disabled]
[Header checksum status: Unverified]
Source: 172.16.87.10
Destination: 172.16.84.188
Transmission Control Protocol, Src Port: 443, Dst Port: 60255, Seq: 1, Ack: 518, Len: 7
Source Port: 443
Destination Port: 60255
[Stream index: 2]
[TCP Segment Len: 7]
Sequence number: 1 (relative sequence number)
Sequence number (raw): 1409711058
[Next sequence number: 8 (relative sequence number)]
Acknowledgment number: 518 (relative ack number)
Acknowledgment number (raw): 3705980144
0101 .... = Header Length: 20 bytes (5)
Flags: 0x018 (PSH, ACK)
Window size value: 32768
[Calculated window size: 32768]
[Window size scaling factor: -2 (no window scaling used)]
Checksum: 0x8b0f [unverified]
[Checksum Status: Unverified]
Urgent pointer: 0
[SEQ/ACK analysis]
[Timestamps]
TCP payload (7 bytes)
Transport Layer Security
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 2
Alert Message
Level: Fatal (2)
Description: Handshake Failure (40)

Marvin Rhoads · ‎03-26-2020

Is that coming from the ASA? I think so because the source is a Cisco MAC address. In the capture we see:

TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)

That usually indicates the client didn't propose any acceptable cipher suites in the Client Hello. We would normally expect something like this from the client:

...after which the server replies with its hello and proposes the strongest mutually supported cipher suite for the conversation going forward:

If there is no overlapping cipher suite available, the ASA will reply with a handshake failure.

DavidM0567 · ‎04-02-2020

I changed the tls 1.2 setting to all

ssl cipher tlsv1.2 all

I am now able to ssh, https, and asdm into the asa.

Thank you all