cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1110
Views
11
Helpful
4
Replies

Verifying a sensor's ssh server-key

kurtpatzer
Level 1
Level 1

Hello,

I'd like to know a repeatable method for verifying a sensor's SSH server key from a windows client. I generally use putty as my ssh client, but tried 2 others in this persuit.

On the sensor you can use the "show ssh server-key" command to view the key in its raw (decimal) format, as well as an MD5 and Bubble Babble fingerprints.

When you connect with putty for the first time, putty shows you a finger print, which I assume is MD5 because it is 128 bit in hex format. But that doesn't match the 128 bit hex MD5 fingerprint shown via the sensor's command line.

I tried a 2nd client which gave a babble fingerprint, but again, doesn't match the babble fingerprint that the sensor's command line does.

I tried a 3rd client which shows both the MD5 and babble fingerprint. These fingerprints matched those displayed by the other SSH clients, and obviously then did not match what the sensor showed.

Lastly, I tried to look at the full key stored by these clients in host files or the windows registry to compare with the full key shown by the IDS command line. All 3 clients display the key in hex format, while the sensor displays in decimal format. I can't find a hex to decimal calculator that can handle 1024 bits worth of input!

So, if I have to blindly accept the key the first time my SSH client connects to a Cisco IPS sensor, I'm obviously open to a man in the middle attack at first connect. I can do some warm & fuzzy verification (connect from the sensor's own subnet & verify my ARP cache MAC address entry is correct, etc), but it seems these finger prints should be verifiable directly.

Thanks,

KEP

1 Accepted Solution

Accepted Solutions

Here is kind of a kludge that may help.

Once again logging in as the service account you can SSH back to the sensor's own loopback ip address.

"ssh -2 127.0.0.1"

-bash-2.05b$ ssh -2 127.0.0.1

The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.

DSA key fingerprint is 2c:76:a2:b3:67:e2:cb:46:8d:ee:3b:41:92:ac:61:19.

Are you sure you want to continue connecting (yes/no)?

The service account is connecting through the sensor's own loopback ip address so there is almost know possibility of a man in the middle attack.

(The only way to mess this up would be for the attacker to already have complete control of the sensor and loaded his own SSH server program on the sensor)

The "-2" specifies to use a version 2 client.

Now the big question will the hex fingerprint seen in the above question be able to be used to compare to the information provided by your SSH client?

Let me know if this weird method still won't work for you.

I have sent an email to our main SSH engineer to see if he has a better method.

View solution in original post

4 Replies 4

marcabal
Cisco Employee
Cisco Employee

What are you most likely running in to is a mismatch of SSH v1 keys and SSH v2 keys.

The SSH server on the sensor will support connections from both SSH v1 and SSHv2 clients, BUT will only show the SSH v1 key with the "show ssh server-key" command.

So when you connect with a SSH v2 client it will pull the SSH v2 key from the sensor which will not match the SSH v1 key you see in the CLI output.

Options:

1) Use a SSH v1 client instead of a V2 client. (Many clients give you the option of specifying the version to use).

2) Login with a service account on the sensor. Then "cd /etc/ssh", and execute "cat ssh_host_rsa_key.pub". This file should contain the public key used by SSH Server when handling v2 clients and you should be able to compare it with the key seen by the clients you are using.

Right on the nose! When I forced the clients to use SSH v1, the fingerprints matched those shown by the show ssh server-key command.

This is certainly a big step in the right direction. But, is there any way to verify the fingerprint of the ssh v2 public key? I can indeed display it from the bash shell via the service account, but I don't know how to describe it's encoding. It's neither hex nor decimal. The known hosts files/registry entries of the ssh clients that I use store the key in decimal format. I'd need a way of converting between decimal format and that used in the sensor public key file. Any options there?

Thanks for the tips so far...

KEP

Here is kind of a kludge that may help.

Once again logging in as the service account you can SSH back to the sensor's own loopback ip address.

"ssh -2 127.0.0.1"

-bash-2.05b$ ssh -2 127.0.0.1

The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.

DSA key fingerprint is 2c:76:a2:b3:67:e2:cb:46:8d:ee:3b:41:92:ac:61:19.

Are you sure you want to continue connecting (yes/no)?

The service account is connecting through the sensor's own loopback ip address so there is almost know possibility of a man in the middle attack.

(The only way to mess this up would be for the attacker to already have complete control of the sensor and loaded his own SSH server program on the sensor)

The "-2" specifies to use a version 2 client.

Now the big question will the hex fingerprint seen in the above question be able to be used to compare to the information provided by your SSH client?

Let me know if this weird method still won't work for you.

I have sent an email to our main SSH engineer to see if he has a better method.

This works great, as far as I'm concerned!

I've had similar issues with all Cisco devices, IOS, PIX, VPN Concentrator. I'll have to research later if its the same issue. Problem is this verification method requires an SSH v2 client on the box itself. That is true for the latest IOS versions, but not PIX or VPN. If you have any ideas there, let me know. But thanks big time for the solution on the sensor.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: