Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
Guide to better SSH-Security
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.
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 http://www.keylength.com 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.
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
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:
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:
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: encyrpt-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: