SSH Server "Time to Live"? Less than a cup of coffee!

Published: 2017-11-08
Last Updated: 2017-11-08 14:32:43 UTC
by Rob VandenBrink (Version: 2)
12 comment(s)

After the stories I posted last week on SSH, I had some folks ask me about putting an SSH server on the public internet - apparently lots of lots of folks still think that's a safe thing to do.

Shodan lists 15 million such trusting souls:

OK - so can 15 million people be wrong? In a word, yes.  I put an SSH / SCP server up for a few minutes yesterday, for a quick file transfer.  For kicks, I left it up for a few minutes after I send myself the files, and had a coffee while I watched the logs.  And yu-u-u-p, I had several IP's brute forcing against my SSH service within 10 minutes of the server being online.


These are all automated attack engines, but they are taking the Mirai approach of using well known / default credentials to attempt to login - exactly lke the Mirai botnet, except over SSH rather than telnet.  I'll refer you again to  and any number of other sites that have default credentials listed.  "Common password" lists such as "the worst 500 passwords" or even comprehensive lists like the RockYou list, with transforms such as "add "99! or "!!"" to the end" are also surprisingly successful.  I have to say that I got domain admin this week from some LinkedIn OSINT, an open SSH server and "456789" as a password.

Anyway, the "safe" time to live for an SSH server on the public internet really is minutes these days - in my case less than a cup of coffee.  Look at your logs - the wolf has been at your door since the day you put that server online.  If you are still seeing brute force attempts against your server, that's no guarantee that someone else hasn't already succeeded.  Time to put your SSH server behind a VPN, preferably a VPN with multifactor authentication!


Rob VandenBrink

12 comment(s)


I'm assuming that since you suggest putting it behind a VPN that you believe key-authentication to be also unsafe? Could you elaborate?

I've been running with PasswordAuthentication no, PermitRootLogin no for a while, including a login script that emails me as an alert. Should I assume this is no longer safe? Do you have an opinion on the Google-Authenticator 2FA integration with SSHD?
This is why tools like bfd, fail2ban, Denyhosts, etc. are all very useful. Immediately cuts off brute-force attempts. If you have a lot of services that are internet-facing, some kind of network appliance would be far better of course.
Sorry, I couldn't agree less. A VPN is nothing more secure than SSH is.

Obviously one should not allow access for "root" with "password" but disallowing password login is enough and likely more secure than most VPN servers are.
I use fail2ban tightened up ( 1 password fail gets your IP a 120 minute ban ). Cuts down the automatic attacks well enough to be useful for me.
While I certainly agree that restricting any administrative access to systems to behind a VPN is best, I'd like to see this post updated to account for the use of public-key authentication / SSH keys, and/or multi-factor authentication. (I typically avoid fail2ban and similar solutions, due to the denial-of-service potential.) Consider that SSH can be used AS an effective VPN solution - especially with public-key authentication and MFA in-place.
Great feedback, thanks everyone!

Yes, I would certainly say that SSH with 2FA or key based authentication is as good as a VPN (that'd be VPN with 2FA/MFA) any day. Any mainstream MFA provider does the trick, I see a lot of RSA, DUO and also yes, Google MFA solutions being used, they all work great - pick your favourite and go with it!

Anything with userid/password on the internet is definitely a target these days, but ssh and telnet are "higher on the radar" for attackers. VPN should be just as high, certainly the risks are greater, but for some reason we're not seeing that in practice. At least with my clients, I do see some brute forcing on VPN services, but it's not nearly as common as for telnet and ssh. That being said, yes, MFA, keys or certificates for VPN authentication is a must these days too. If a VPN is breached it's catastrophic, and it's only a matter of time before folks put successful VPN credentials up for sake as "marketplace" items (more than they are now that is). MFA or keys or certificates are the main protections there - I'd suggest MFA does the best job because (if done right), the person who just stole the corporate laptop doesn't get the MFA along with it.

All that being said, having one VPN service with 2FA / MFA is less of a target than a collection of SSH servers with 2FA / MFA or key based authentication. Especially if those servers are maintained by different people with different skill levels, it's likely that at some point, one of those SSH servers will (by error or an uninformed configuration) become a userid/password authentication host.

On fail2ban, yes, that traditionally filters out the attackers who only have a host or two doing their work for them. However, these days we have attackers with dozens or hundreds of bots involved in the attack. My screenshot didn't show it, but the attack I saw was up to 10 hosts (and rising) within a few minutes, and that was most certainly automated rather than targeted. So at that point you really need to look at keys or a VPN - someone who's determined enough will eventually get past fail2ban and similar tools.

For more on SSH, go back to the 3 stories on this that we posted last week? Some of this info is covered there as well.

Again, thanks for the comments and suggestions, keep them coming!
I'd be interested in thoughts regarding sFTP. Our EDI software uses sFTP (also 22/tcp) with username/passwords. Trading partners likely would have difficulty using VPN and/or MFA. Our software disconnects after x failed attempts and automatically bans when certain usernames are attempted. The logs seem to indicate that it has been fairly effective. However, I'd like to hear what other EDI shops do.
Usually sFTP (FTP over SSH) can be at least connected to using a standard SSH client, so I'd suspect that your server is seeing the same sort of continuous attack traffic that any other SSH server might see. With a trusted partner often you can restrict access to an sFTP host to their fixed IPs - is that an option for you?

FTPs (FTP + TLS) is also an option, but often that's more trouble than it's worth. Unless you can make sure it's running PASV only, firewalls won't catch the port and direction change unless the certificate is installed on the firewall. And if it's configured for userid/password authentication, the root problem doesn't go away - you're still susceptible to brute force credential attacks.

Another option would be to use a "secure send" platform, maybe something that you can send a partner a "time bomb" https link via email, which lets them pull one file with a passphrase? We see lots of solutions like this being deployed these days for insurance and banking organizations, for one-time access to forms that need a signature for instance.

No matter the platform, of course also be sure to both update and pentest that platform regularly - even for the last option, for all things are "time-bombed" for the user, often the content doesn't actually get deleted (or doesn't get deleted securely). And of course on all platforms an authentication bypass or other security issue will often leave all the content breached or exposed (which usually comes to the same thing), so you'll want to follow vendor security announcements and patches (and industry news if your vendor isn't great about patching).
Time to live usually refers to first compromise, not the first packet sent your way.

One point with VPNs, which is often overlooked, is that usually they are bi-directional. You could make connections through it in both ways. This is sometimes not wanted. Do you know how your VPN endpoint is protected? Often not.
You can dramatically decrease the number of failed authentication attempts if you use "security by obscurity"- choose another port for SSH. 99,9% of those bots only use the traditonal ports for telnet and SSH. Configuring SSH to use port 55 (for example) and a ban of 120 minutes after the 3rd failed authentication attempt leads to 15 - 20 entries *per year* in my OSSEC logs.

Diary Archives