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.
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.
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?
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.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...