Even when I was up against an overzealous agent, I had a number of methods for discouraging a search. I routinely mislabeled my shipments “farm machinery.” And I have yet to meet the lowly-paid customs official who will open a container marked “radioactive waste” to verify its contents.
Lord of War
Apart from the fact that Telnet sends everything in plaintext, Telnet is also vulnerable to man-in-the-middle attacks. Telnet does not provide a mechanism to verify the identity of the host that you are connecting to. (Well, when you are sending everything in the clear, host identification is kinda like closing the convention center door after the Furries have bolted.) An attacker could intercept your packets on their way to the actual destination. The attacker could even modify the packets that are sent during the communication. So Telnet provides no assurance of confidentiality or integrity.
Right, then. You know better than to manage your ASA over Telnet. The very idea gives you hives, yes? Excellent.
There are 2 methods can you use to manage an ASA securely: There’s the GUI management tool (ASDM) which is secured by HTTPS, providing encryption and secure server identification. (ASDM version 6 and up is actually quite usable and stable.) Or, if you want a command line, you could set up your ASA to accept management connections via SSH. SSH will encrypt the traffic and thereby prevent eavesdropping. The SSH protocol also allows the ASA to identify itself via its host key.
This is the core of the trust model for SSH on the ASA. Let’s look at how SSH uses the host key to identify the ASA.
SSH RSA Keypair on the Cisco ASA
SSH on the Cisco ASA requires the generation of a RSA keypair on the ASA. It is used to uniquely identify the ASA when the SSH client tries to establish a SSH connection to the SSH server (the ASA). To generate RSA key pairs for identity certificates, use the crypto key generate rsa command. You can specify a modulus size of 512 bits, 768 bits, 1024 bits or 2048 bits. 1024 bits is the default:
ciscoasa# con t ciscoasa(config)# crypto key generate rsa modulus 2048 INFO: The name for the keys will be: <Default-RSA-Key> Keypair generation process begin. Please wait...
To view the public key data, use the show crypto key mypubkey rsa command:
ciscoasa(config)# show crypto key mypubkey rsa Key pair was generated at: 18:00:35 UTC Jul 30 2011 Key name: <Default-RSA-Key> Usage: General Purpose Key Modulus Size (bits): 2048 Key Data: 30820122 300d0609 2a864886 f70d0101 01050003 82010f00 3082010a 02820101 00b40fc7 78bec280 af666796 ff3eb3f7 c4115062 0fed2d01 69ebb174 18230cbe 5b4d8255 4053ca6d e26d6c9e 43efa97b ab0f10df ffef3b0e 409a94f6 3c191ecd 89a10cf9 fe93a21f c409e464 0bfac0cf 11a9b95f 7b7f3a2a 6b90eccd 2e4c92d0 ad216037 745891dd 00e0337b 89060f14 3f0fc0f3 0b98b208 03dd2bcc ce13c1b9 dd8324c3 9e252b84 e171ef18 916f4227 36edf126 dbf3008d 8582327a a1df5028 6246fd47 9df418a8 e3556a18 40ec4c3d 758c0a86 7ebbdc68 d2a12a59 0e150e2e fb74555f ef19b73c 7d512e6c 781c3bea 22f2bfe8 5d0fb4d4 e1ae564f 47df2d7a 5fd81224 81f197b8 5189e3c0 10a81e73 4f049a33 1eefd405 0d8b15fe db4b4fd5 8b020301 0001
An RSA public key consists of two parts: the public (or encryption) exponent e and the modulus. The modulus is the long number in the public key (.pub) file. The public key can be known to everyone. The private key consists of the private (or decryption) exponent d which must be kept secret.
ASA Host Key Fingerprint
When connecting to the Cisco ASA via SSH, the Cisco ASA acts as the SSH server, and the management workstation runs an SSH client (such as Putty or the OpenSSH client.) The first time that the SSH client connects to the ASA, you will be presented with a prompt that shows you the RSA key fingerprint of the server.
The fingerprint is what you get when you apply a hash function to the public key. The fingerprint is shorter than the actual key, so that it is easier for a human to verify. In SSH clients, the fingerprints that are displayed for human verification are usually a sequence of 16 octets printed as hexadecimal with lowercase letters and separated by colons. RFC 4716 deals with the SSH public key format.
The idea here is for you, the human, to verify that the fingerprint for the key is correct. Then you can be reasonably sure that you are indeed connecting to the correct host.
With Putty, once you hit Yes, the fingerprint is cached in the registry at:
And you will not be prompted to verify the ASA’s host key again, unless the ASA uses a different key for identification, or you delete the key from the registry on the management workstation.
On a Mac, you can SSH into the ASA from the Terminal program. OS X has OpenSSH built-in. Just open terminal and use the ssh command to open a connection to the ASA:
host:~ username$ ssh 126.96.36.199 The authenticity of host '188.8.131.52 (184.108.40.206)' can't be established. RSA key fingerprint is ef:ab:28:81:53:c2:a3:8d:77:0d:06:e7:89:2b:81:9c. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '220.127.116.11' (RSA) to the list of known hosts.
After you type Yes, the host key of the ASA is added to the known_hosts file on the Mac at:
You can open this folder just by typing open .ssh in a Terminal window. You will not be prompted again to verify the key fingerprint when connecting to the ASA , so long as the ASA’s key remains in the known_hosts file. If you delete the known_hosts file, you will prompted to verify the fingerprints when you connect, as if you are connecting for the first time.
Like SSH server administrators the world over, you might want to keep a record of the key fingerprint so that you can use it for reference later on. You should use out-of-band channels to provide this fingerprint to legitimate users, so that they can compare it with the fingerprint that is presented to them when they connect to the ASA. Out-of-band channels could include email, telephone, key-signing parties or even SMS. Some method that is unlikely to be also intercepted by the attacker.
On a Mac, you can use the ssh-keygen utility to generate the RSA fingerprint from a host key that is stored in the Mac’s known_hosts file. Just open Terminal and use the ssh-keygen command:
host:~ username$ ssh-keygen -l -F 18.104.22.168 # Host 22.214.171.124 found: line 3 type RSA 2048 ef:ab:28:81:53:c2:a3:8d:77:0d:06:e7:89:2b:81:9c 126.96.36.199 (RSA)
The human verification of the host key fingerprint is only useful if the user actually performs a verification (i.e. compares it to the fingerprint that the SSH server administrator has provided via an out-of-band communication.) If you just blindly accept the fingerprint presented during connection establishment, there’s no assurance that the host identity is correct, or that the communications will be secure from a man-in-the-middle attack. After all, the attacker could have intercepted the SSH session negotiation from the SSH server and presented their own fingerprint to the SSH user.