Showing results for 
Search instead for 
Did you mean: 

There are countless recommendations for the configuration of SSH on Cisco devices available. But many of them propose settings that are not adequate any more. This document shows how to set up SSH on IOS and ASA for advanced session-security and how to configure an Apple Mac with OS X to only negotiate secure crypto. The client-side part of this document can also be used for checking the settings on a Linux-system. 


Cisco IOS

It always starts with the generation of a public/private keypair that will be only used for the SSH-process. In this command we use a dedicated label "SSH-KEY" which we later assign to the SSH-config. The default-keylength ist typically too small, it's time to move to a stronger crypto. For new setups I only use 4096 Bit keys. Thats more then recommended on sites like and makes the session-setup a little slower. But by far not that slow that it's unusable. And it typically doesn't hurt to have better crypto then the others.


crypto key generate rsa label SSH-KEY modulus 4096


The RSA-Keypair is assigned to the SSH-config:


ip ssh rsa keypair-name SSH-KEY


Next we only allow SSH version 2. By default also version 1 is allowed:


ip ssh version 2


When the SSH-session is established, the session-keys are computed with the Diffie-Hellmann key exchange protocol. By default this is done with 768 Bit, which is not state-of-the-art any more. For my setups (with MacOS and Linux clients) I configure a bitlength of 4096 Bit. If you are using Putty in the actual version (0.63 at the time of writing), this is more then Putty can handle. You should change to a more powerful terminal like SecureCRT or use only a size of 2048 Bit which is still very secure. And if your IOS is to old, this command will also not be available.


ip ssh dh min size 4096


Depending on your needs you could enable the logging of SSH-login-events:


ip ssh logging events


The last step is to restrict the vty-lines to only use SSH, so that Telnet is not allowed any more:


line vty 0 4
  transport input ssh


In some setups, where SSH has to be reachable over the internet, I also change the SSH-port to something non-standard. This won't really increase the security of the setup, but it gives less log-entries from bots that try to login to SSH with commonly used username/password-combinations.


ip ssh port 7890 rotary 1
line vty 0 4
  rotary 1



If the IOS-device is running at least 15.5(2), then it's possible to disable unwanted algorithms. In security-audits, all CBC-ciphers are often a problem.


By default there are many algorithms supported:


rtr#show ip ssh | inc Encryption|MAC
Encryption Algorithms:aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
MAC Algorithms:hmac-sha1,hmac-sha1-96


With the following config only aes256-ctr with hmac-sha1 is allowed on the router:


ip ssh server algorithm encryption aes256-ctr
ip ssh server algorithm mac hmac-sha1


rtr#show ip ssh | inc Encryption|MAC
Encryption Algorithms:aes256-ctr
MAC Algorithms:hmac-sha1


Usernames and Passwords in Cisco IOS

There are different ways in IOS to configure users with corresponding passwords. For SSH, the Router/Switch doesn't need the cleartext password. That means you should not configure your users with

rtr(config)#username USER password PASS


Better configure your users with hashed passwords. If you are running a recent IOS, you can configure the passwords to be hashed with PBKDF2:

rtr(config)#username USER algorithm-type sha256 secret VERYSECUREPASSWORD


If your IOS doesn't support this new username-parameter, you configure them the following way:

rtr(config)#username USER secret VERYSECUREPASSWORD



Some more protection-mechanisms that should be thought about are Control-Plane-Protection and Management-Plane-Protection. But that is not SSH-specific.


Cisco ASA

The setup on the ASA has the same goal as on IOS, but there are less options to secure SSH. The syntax is also a bit different:


crypto key generate rsa modulus 4096
ssh version 2
ssh key-exchange group dh-group14-sha1


The keylength is dependent on the ASA platform in use. The legacy ASAs are not capable of a keylength larger then 2048 Bit. On the actual 5500-X devices, 4096 Bit is also possible.

The command "ssh key-exhange group group14-sha1" was introduced in 8.4(4.1) and 9.1(2).


Starting with 9.6(1) and 9.1(7), it's possible to limit the ciphers that are allowed on the ASA.


These are the defaults:

asa(config)# show ssh | inc Cipher
Cipher encryption algorithms enabled: 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr
Cipher integrity algorithms enabled: hmac-sha1 hmac-sha1-96


The available options are:


asa(config)# show 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: 3des-cbc 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
low: hmac-sha1 hmac-sha1-96 hmac-md5 hmac-md5-96
medium: hmac-sha1 hmac-sha1-96
fips: hmac-sha1
high: hmac-sha1


With the following config only aes256-ctr with hmac-sha1 is allowed on the ASA:

ssh cipher encryption custom aes256-ctr
ssh cipher integrity custom hmac-sha1


On the ASA, the SSH-access has to be allowed from the management-IPs:


ssh inside
ssh outside


Cisco Nexus

The Nexus by default uses only 1024 Bit keys, and only supports SSH version 2.

The only available option (to my knowledge and based on the config guide) is to use keys with a maximum length of 2048 Bits for the SSH-server:


ssh key rsa 2048 force


Client-config on MacOS (and Linux)

On a default-install of MacOS and also some Linux-versions, the optimum crypto is not always negotiated. For that, some settings should be adjusted to provide more security.


SSH-parameter can be configured at two places:

  • globally at /etc/ssh_config
  • per User at ~/.ssh/config


In the systemwide config on MacOS the following three lines are most relevant for the used cryptography of the SSH-sessions (shown are the defaults on OS X Mavericks 10.9):


#Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour
#KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
#MACs hmac-md5,hmac-sha1,,hmac-ripemd160,hmac-sha1-96,hmac-md5-96,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96


There are a couple of changes needed to make SSH-sessions more secure:  


If you don't have any legacy devices to manage you can remove everything other then the AES-ciphers. If there are still older devices like Catalyst 2950 to manage, 3des-cbc could be left in the config:


Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc,3des-cbc


I prefer to not have any legacy crypto in my cipher-string. If I have to connect to a legacy device, I specify that on the ssh-command which is shown later in this document.

Based on the manpage (and also based on the used OpenSSH-version which is 6.2p2 on both Mavericks and Yosemite), modern cipher-types like AES-GCM should also work. But when trying to configure them I only get the error „Bad SSH2 cipher spec“.  

When connecting to Cisco routers and switches, typically the  CBC-versions are used, the more modern CTR is only supported with IOS 15.4 which at least I don't use yet.


This option controls the Key-Exchange. A more secure config on Mac OS is the following:


KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1


I removed the ElipticCurve algorithms as they are suspected to contain backdoors. 

The probably trustworthy curve25519 from D.J. Bernstein is only available starting with OpenSSH 6.6p1. Based on the availability, this algorithm should be added.

The last option in this line is again for legacy systems. Again, I don't have these configured, instead I use these options only for the sessions where needed.


In this default I don't like the MD5 MACs and that the more secure ones don't have the highest priority. So this line should be cleaned up and rearranged:




Just notice the etm-MACs in the line. These are not relevant for accessing Cisco Network-devices, but can strengthen the crypto when connecting to other SSH-servers. A little excursion into Message Authentication Codes:  

The protocols SSL/TLS, IPsec and SSH by default use different methods to encrypt the data and protect the integrity:

  • SSL: mac-then-encrypt. The MAC is build first, then MAC and data are encrypted.
  • IPsec: encrypt-then-mac. The data is first encrypted, the MAC is build over the encrypted data.
  • SSH: encrypt-and-mac. The data is encrypted, but the MAC is build over the cleartext data.

Cryptographers have shown that the method used by IPsec is the most secure one. This method (encrypt-then-mac) can also be used by SSH when supported on both the client and server.

Update: RFC 7366 defines an extention to TLS that also allows to use "encrypt then mac".


What will change for our SSH-sessions with this new config? Before activating the config-changes, this is an SSH-session (on a Cisco 3560 with IOS 15.0(2)SE5):


c3560#sh ssh
Connection Version Mode Encryption Hmac State Username
1 2.0 IN aes128-cbc hmac-md5 Session started ki
1 2.0 OUT aes128-cbc hmac-md5 Session started ki


The used crypto is aes-128-cbc with an MD5-HMAC. After applying the new client-config, the used crypto is much better (as far as possible with this IOS):


c3560#sh ssh
Connection Version Mode Encryption Hmac State Username
0 2.0 IN aes256-cbc hmac-sha1 Session started ki
0 2.0 OUT aes256-cbc hmac-sha1 Session started ki



This is the used  ~/.ssh/config that still includes the legacy methods:


Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc,3des-cbc
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1


As mentioned earlier, I also removed the legacy crypto from my ~/.ssh/config:


Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1


If an ssh-session to a legacy device is still needed, the older crypto has to be specified with the ssh-command. This is an example for a connection to an old Catalyst 2950:


ssh -l ki -o Ciphers="3des-cbc" -o KexAlgorithms="diffie-hellman-group1-sha1"



Any suggestions or improvements? Please comment!

Maher Shaban
Level 1
Level 1

Great article.

thank you.

Marvin Rhoads
Hall of Fame
Hall of Fame

Nice job Karsten. Thanks!

Level 1
Level 1

On some recent IOS versions, it seems possible to configure algorithms and MACs on the SSH server as well:

Thanks for the info, I've added it to the guide!

Marvin Ruiz
Level 1
Level 1

Excellent article!

Thanks a lot for the info. 

Stefan Amstutz
Level 1
Level 1

Thank you Karsten for your excellent post.

Did you have experience to implement ssh with domain certificates?

Faisal Mohammed
Level 1
Level 1

Thank you so much, it helped me a lot.

Naveed Rana
Community Member

Thank you so much. This is a great article, very easy to follow.

Level 1
Level 1

Is there a way to disable week ciphers and CBC mode on Cisco IPS 4255, 4270 ?

These devices are approaching EOL soon. I wouldn't expect anything new here. It's time to migrate to FirePOWER to take advantage of new developments.

Perhaps you can change settings in the underlying OS, but I haven't tried it myself as I don't operate any legacy IPS anymore.

Level 1
Level 1

Thanks Karsten for responding.

Is the same thing documented somewhere on cisco site, which I can use as reference.

Level 1
Level 1


On nexus, I want to set up ''ip ssh server algorithm encryption 3des-cbc' like IOS.

I can not find any. Please help me

As far as I know, it's not (yet) available on NX-OS.

Level 1
Level 1

Is there any way to disable 3des-cbc?

Is 3des active on the nexus by default?


Very useful. Thanks
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: