Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - SANS Internet Storm Center InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Securing SSH Services - Go Blue Team!!

Published: 2017-11-01
Last Updated: 2017-11-02 20:29:34 UTC
by Rob VandenBrink (Version: 2)
6 comment(s)

As the world of the attacker evolves and new attacks are developed (Red Team), people in the world of defense sees a matching evolution in recommendations for securing various platforms and services (Blue Team).  It struck me as odd that we don’t see a lot of “high profile” changes in advice for SSH, so I did some digging.

The go-to document that many of us use for SSH security is NISTIR 7966 (  That has lots of great recommendations, and is dated October 2015, so it’s 2 years old as of this post.

There are some great OPENSSH recommendations published here at  The latest commit on that project was Oct 19, so just 11 days ago – that’s about as current as it gets.

However, lots of the devices we work with don’t give us access to the OpenSSH config, so there’s a lot of translation to match up guidance to the command interface of this or that device. hosts a paper that does just this.

For instance, let’s look at Cisco IOS routers – mostly because the configuration is so simple, and I see so many of them that have silly configuration “misses” on the security side.  Most guidance for Cisco IOS routers suggests that you force SSHv2, add an access-list to limit access, and then stop there.  That config sequence would look like:

crypto key gen rsa gen mod 2048        ! generate the SSH key

login on-failure log                   ! log failed login attempts
login on-success log                   ! log successful login attempts


ip ssh version 2                       ! force SSHv2 (SSHv1.x is easily decrypted)

ip access-list standard ACL-MGT        ! Create an ACL to limit access

  permit ip x.x.x.0          ! permit access from management VLAN

  permit ip host x.x.x.y               ! or permit access from specific management hosts

deny ip any log                        ! log all other accesses  (you can log the successful ones too of course)


line vty 0 15                          ! note that some newer platforms have more than 15 VTY lines !!

transport input ssh                    ! restrict to SSH only (no telnet)

access-class ACL-MGT                   !  apply the ACL

However, combining advice from the various documents above, naming the key, increasing the key size and setting a client minimum all make good sense – this changes our config commads to:

crypto key generate rsa modulus 4096 label SSH-KEYS     ! name the keys.  This makes it easier to rotate keys without a "gap" in protection

ip ssh rsa keypair-name SSH-KEYS

ip ssh version 2

ip ssh dh min size 2048                                                                              ! set a minimum standard for a client to connect with (helps prevent downgrade attacks)

ip access-list standard ACL-MGT

 permit ip x.x.x.0                 ! permit access from management VLAN

 permit ip host x.x.x.y                      ! or permit access from specific management hosts

deny ip any log                              ! log all other accesses  (you can log the successful ones too of course)


line vty 0 15                                ! note that some newer platforms have more than 15 VTY lines !!

transport input ssh                          ! restrict to SSH only (no telnet)

access-class ACL-MGT                                                           ! apply the ACL

A Cisco ASA gives us a bit more control, where we can set the key exchange group.

crypto key generate rsa modulus 4096

ssh version 2

ssh key-exchange group dh-group14-sha1


ssh x.x.x.y m.m.m.0 inside            ! limits SSH access to specific hosts or subnets. (note the ACL is a subnet instead of a wildcard approach)

(I’d recommend NOT to enable ssh to any public interfaces – use a VPN connection, preferably with 2FA, then connect to the inside interface).

Rather than disable telnet on an ASA, you simply don’t grant access to it – be sure that there are no lines similar to:

telnet x.x.x.y m.m.m.m <interface name>

in your configuration.

Note that both the Cisco IOS platform and Cisco ASA support key based authentication in addition to standard userid/password authentication.  The advantage to this is that you can’t easily brute-force a key-based authentication interface – so that’s a very (very) good thing.  The disadvantage is that if an admin workstation is then compromised, the attacker is in the “all your keys are belong to us” situation – all they need is the keys, and the keys are usually helpfully named with the IP address or hostnames of the targets.  Or if you happen to be a vendor who’s put keys into a firmware image, that would mean all instances of your product everywhere are easy to pop.

This covers off some basic SSH configuration, but what about auditing this config?  (Stay tuned)

Rob VandenBrink

Keywords: Securing SSH
6 comment(s)
November issue of Security Awareness Newsletter Ouch! (Shopping Online)
Diary Archives