Enabling ssh on a Cisco ASA

Enabling SSH on a Cisco ASA is not as easy as it might seem. On first look, you would think using just the “ssh <network> <subnet> <interface>” would do the trick but there are 2 more commands that are needed.

In my specific scenario, I needed SSH access to a Cisco ASA from the 10.10.1.0/24 subnet. First thing I did was create a local user name and password and enable ssh:

username jmartinez password Cisco123!
ssh 10.10.1.0 255.255.255.0 outside

Trying to connect, PuTTY tells me “Server unexpectedly closed network connection”. Something is missing! I enabled ssh debugging with the command “debug ssh” and received the following debug when I tried to connect:

ASA# Device ssh opened successfully.
SSH0: SSH client: IP = '10.10.1.27'  interface # = 1
SSH: unable to retrieve default host public key.  Please create a defauth RSA key pair before using SSH
SSH0: Session disconnected by SSH server - error 0x00 "Internal error"
ASA#

A useful debug log?! It’s obvious from above that I don’t have an RSA keys in order to encrypt traffic. So I issue the following command to generate a key:

ASA(config)# crypto key generate rsa
INFO: The name for the keys will be: <Default-RSA-Key>
Keypair generation process begin. Please wait...
ASA(config)#

Excellent! Now when I try to reconnect, I get a connection with the following debugging lines:

Device ssh opened successfully.
SSH0: SSH client: IP = '10.10.1.27'  interface # = 1
SSH: host key initialised
SSH: license supports 3DES: 2
SSH: license supports DES: 2
SSH0: starting SSH control process
SSH0: Exchanging versions - SSH-1.99-Cisco-1.25
SSH0: send SSH message: outdata is NULL
server version string:SSH-1.99-Cisco-1.25SSH0: receive SSH message: 83 (83)
SSH0: client version is - SSH-2.0-PuTTY_Release_0.60
client version string:SSH-2.0-PuTTY_Release_0.60SSH0: begin server key generation
SSH0: complete server key generation, elapsed time = 3030 ms
SSH2 0: SSH2_MSG_KEXINIT sent
SSH2 0: SSH2_MSG_KEXINIT received
SSH2: kex: client->server aes256-cbc hmac-sha1 none
SSH2: kex: server->client aes256-cbc hmac-sha1 none
SSH2 0: expecting SSH2_MSG_KEXDH_INIT
SSH2 0: SSH2_MSG_KEXDH_INIT received
SSH2 0: signature length 143
SSH2: kex_derive_keys complete
SSH2 0: newkeys: mode 1
SSH2 0: SSH2_MSG_NEWKEYS sent
SSH2 0: waiting for SSH2_MSG_NEWKEYS
SSH2 0: newkeys: mode 0
SSH2 0: SSH2_MSG_NEWKEYS received

When I type in an existing username / password that is on the ASA already, I get access denied. Debugging shows:

SSH(jmartinez): user authen method is 'no AAA', aaa server group ID = 0
SSH2 0: authentication failed for jmartinez

It looks like we don’t have an AAA method setup. I want to use the local user database. Let’s configure that:

ASA(config)# aaa authentication ssh console LOCAL

Now when I connect, I am able to login successfully. Here is the debug log for a successful connection:

SSH(jmartinez): user authen method is 'use AAA', aaa server group ID = 1
SSH2 0: authentication successful for jmartinez
SSH2 0: channel open request
SSH2 0: pty-req request
SSH2 0: requested tty: xterm, height 24, width 80
SSH2 0: shell request
SSH2 0: shell message received

Transfer to Voicemail

One common function of phone systems is having the ability to transfer calls to someone’s voicemail box. By default, there isn’t a feature that’s part of a CUCM and Unity integration that allows you to transfer a call to voicemail. You have to transfer the call to their extension and the call would ring until one of your Call Forward settings sends the call to their voicemail box. Alternatively, you could place the call on hold and navigate your voicemail system until you reach the destination box and transfer the call.

Both of these examples introduce unwanted delay and may frustrate the caller. By introducing this Transfer to Voicemail feature, you can allow for the quick transfer of calls.

You can setup Transfer to Voicemail function using the following steps:

1. Create a new Voice Mail Profile by going to Voice Mail > Voice Mail Profile and clicking Add New in Cisco Unified CM Administration.
2. Assign the new Voice Mail Profile something descriptive such as “TransferToVM”, assign your existing VM Pilot to Voice Mail Pilot and assign it a mask of XXXX (assuming a four digit dialplan, use sufficient wildcard characters to cover yours). Click Save.
3. Create a CTI route point by going to Device > CTI Route Point and give it Device Name that you gave your Voice Mail Profile that you created in step 2. This isn’t necessary but helps you tie the  the profile and the route point together. Assign it an appropriate CSS, Partition and Location attributes. Click Save.
4. Once you save the route point, you are able to assign an extension to it. If you use 4 digit dialing, use the Directory Number of *XXXX (similar to step 2, use sufficient wildcard characters to cover your dialplan). Under the DN Properties of *XXXX, assign the Voice Mail Profile that you created in the previous step and check the Voice Mail check box under Forward All. Click Save and reset the CTI RP.

Following these steps, you should be able to dial *+DN and directly reach that extensions voice mail box.