Is SSH no more secure than telnet?

Published: 2013-06-23. Last Updated: 2013-06-23 14:17:06 UTC
by Kevin Liston (Version: 1)
22 comment(s)

TL;DR

In SSH's default (and most common) deployment: Yes.  It is no more secure than telnet, but it can be better.

Apologies to Ian Betteridge

If you ask any sysadmin, they say that SSH is more secure than telnet, and they'll likely comment that opening telnet up to the Internet is reckless.  One can simulate asking general opinion with a little googling:

  • "ssh is more secure than telnet": 11,500
  • "telnet is more secure than ssh": 81

So, the Conventional Wisdom is that "ssh is more secure than telnet."  This must be why we see so many default deployments of SSH.  Which is why SSH are likely so common and eventually successful.

Why do people commonly think SSH is more secure?  In a word: encryption.  "SSH is more secure than telnet because it's encrypted," is a common phrase (~2.3 million google hits on that set.)  SSH's encryption protects you from two main attacks: someone sniffing your credentials and logging into the wrong machine.

Sniffing is a threat from local attackers, either a compromise on the machine itself, or something in the local network, or a system inline between the client and server.  It's certainly a risk, but it's comparatively rare to the risks cited below.

A sufficiently clever attacker could also capture your credentials by modifying your traffic to go through their systems and simply collect your credentials.  One of the key advantages of SSH over telnet is that the server authenticates itself to the client before it collects credentials from the client.

So, we have two attack scenarios that require a clever attacker acting locally to either the client or the server.  I'm going to ask that we ignore these two cases for a moment as I state my case that both telnet and ssh, by default, offer equivalent protection against brute force scans.  The attacker has time and assets on their side, they've got plenty of compromised systems to dedicate to finding more system, and each newly compromised system becomes available to be used for scanning-- think zombie outbreak.

Take a moment to think about how you're using SSH in your environment?  Is it running on the default port, accepting connections from any IP, from any system, relying only on a username/password pair?  If so, I suggest that it's no more secure than running telnet.  Not that I'm suggesting that you chuck SSH and go with telnet "because that guy at the Internet Storm Center said so."

Making it better

SSH can be an effective control.  It's just that so many people set it up only halfway.  If you are using it on the perimeter as your remote-management solution, I strongly suggest running it on a non-standard port.  Seriously, the level of scanning on port 22 is crazy (http://www.dshield.org/port.html?port=22)-- compare it to port 80.  I wouldn't use 2222 as your alternate because it looks like they might be catching on to that as well.

Use SSH as it was intended.  That means creating keys on the client-side as well.  Not those unencrypted keys either, that can be a decent was of managing systems if you can limit the permissions on the accounts correctly, but for interactive sessions from your client boxes, it's really not a good idea.  Intermediary malware loaders are looking for SSH keys in addition to other FTP credentials, so using encrypted client keys might protect a little when the client system is exposed (if you don't decrypt the key while they have their hooks into your system, that is.)

Keep an eye out for abuse.  Tools like fail2ban (http://www.fail2ban.org) can help keep out the brute force attacks.  Putting up a listener on ports 22 and 2222 and feeding that into your firewall blocklist might cut down on a lot of other abuse and spam coming into your network too.

What about two-factor?  This helps even on telnet sessions too.  Take a look at Duo:Security (https://www.duosecurity.com/) they have a personal version that's fairly inexpensive ($10 for 1000 SMS, or $20 for a hardware token.)  It's a simple PAM module.

Stop rewarding brute-force scanners.

22 comment(s)

Comments

Do not forget there are other options for two-factor. Yubico, even Google Authenticator (free). You can even require multiple two-factor or certificate schemes if you are really paranoid.
Amazing! If you compare two things and ignore all the differences, they're the same! A better title would have been, "I just learned that services that use password auth can be brute-forced"
Two observations:
(1) If your credentials are STRONG; then telnet and SSH have similar authentication security. But SSH still wins; due to the resistance against sniffing and man-in-the-middle attacks.

(2) Sniffing as an attack method is rarer because of encryption; sniffing would be much more common attack if Telnet were more widely used.

In regards to
"Sniffing is a threat from local attackers, either a compromise on the machine itself, or something in the local network, or a system inline between the client and server. It's certainly a risk, but it's comparatively rare to the risks cited below.
"

Rare does not mean "not used".
Even comparatively rare techniques are plentifully used, especially by an attacker having succeeding and wishing to gain access to more systems by capturing the LAN for more credentials.
"Not those unencrypted keys either"

Good way to find out how promiscuous your third party tech support is. Once it's out there, like everything on the net, it's free floating which then reduces your certificate to possibly less than name/pass secure.

locked to a specific set of IPs by the firewall eliminates brute forcing except if someone on your IP list is compromised.
I'm quite surprised to read that sniffing is a rare attack!? Now that we know that NSA/GCHQ/etc. sniff every single connection...
"Good way to find out how promiscuous your third party tech support is. Once it's out there, like everything on the net, it's free floating which then reduces your certificate to possibly less than name/pass secure."


Use a from= line in your authorized keys file to control from which IP address each authorized key may be used.

Then not only are the keys not freely portable to untrusted systems; but a key cannot be stolen and then easily re-used from a different LAN workstation or remote location.
Another choice for two factor, if you're up for a little coding (although I think there are some existing PAM modules around) is the otherwise free "Perfect Paper Passwords" from Steve Gibson at https://www.grc.com/ppp . Its a very straightforward and thus easy to understand and implement (and prove the security of) two factor system. I coded up my own implementation (for a non SSH focused usage) in a few hours.
Kevin wrote: "Take a moment to think about how you're using SSH in your environment? "

By all means, SSH can open a rather serious hole in your network if you allow outgoing SSH to any Internet address. Internal users can then use SSH to establish VPNs to external machines to avoid content controls your organization has established or to leak data to external parties.
"If you allow outgoing SSH to any Internet address. Internal users can then use SSH to establish VPNs to external machines to avoid content controls"

That's really a policy issue, not a security issue. HTTP(s)/DNS tunneling can be used to do the same thing.

Regardless of what your defined policies are, there are going to be ways to build VPNs to circumvent them.

Of course... now that organizations have plenty of servers in the cloud, or remote sites to be managed; blocking outgoing SSH is not sane.

You could always use route based ACL's applied at the CORRECT place to force all your outbound traffic through an SSL inspection engine / policy enforcement point. If you need to SSL to other sites by all means allow this but use a perimeter bastion to do this ...SSH is not inherently secure this usually introduced by a human in the form of a flawed deployment :)

Diary Archives