Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Is SSH no more secure than telnet? SANS ISC InfoSec Forums

Watch ISC TV. Great for NOCs, SOCs and Living Rooms: https://isctv.sans.edu

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Is SSH no more secure than telnet?

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.

Kevin Liston

292 Posts
ISC Handler
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.
dsplice

10 Posts
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"
dsplice
1 Posts
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.
Mysid

146 Posts
"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.
Mysid
57 Posts
I'm quite surprised to read that sniffing is a rare attack!? Now that we know that NSA/GCHQ/etc. sniff every single connection...
Martin Scharm

2 Posts
"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.
Mysid

146 Posts
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.
Anonymous
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.
Alan

57 Posts
"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.

Mysid

146 Posts
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 :)
Mysid
13 Posts
WOW Telnet is 44 years old !
Mysid
13 Posts
"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."

I'm going to ask you to ignore some information that doesn't agree with my thesis so I can validate my central idea.
Mysid
3 Posts
I also rate limit connections using iptables (seems to be described well on: https://codeghar.wordpress.com/2010/04/25/secure-your-ssh/). "...still have the ability to try three times a minute..."
mbrownnyc

19 Posts
I'm slowly converting all my home services to .onion services, available ONLY via TOR. I'm considering also moving to an IPv6 ONLY approach. Does anyone have thoughts on this?
mbrownnyc
7 Posts
Ummmm, network/security admins could simply BLOCK inbound SSH access to the network at the edge router to specific IP's and from specific IP's (if a worker really needs to get SSH access from home, either get the worker a static IP and filter inbound traffic on it), or make them use a VPN to access those services.

A standard ACL (properly applied) will save admins a ton of headaches.
dogbert2

21 Posts
There is no way SSH is less secure than telnet. You're right, that is because of encryption. In the end, if they both have the same authentication mechanism, SSH is still (even though slightly) more secure because traffic is encrypted.

That was a good tip from Mysid, in using the from= line; however, what would be a great addition to that feature, is if the SSH server, could detect whether the user (SSH client) is using a key that is password protected or not.
MikeDawg

4 Posts
I would add another way ssh is frequently less secure option and that is something like firewall management. If you need to open it up to the outside (sometimes necessary), then you may have the option of allowing ssh or https. SSH is much more easily brute forced than https. An HTTP login will frequently be limited to 3 attempts before having to refresh the screen and also each attempt takes a few seconds to load the auth screen etc... SSH on the other hand can frequently be brute forced unlimited times as fast as they can pass credentials. Not only that but scanners often are just trying SSH with common usernames and passwords. While that is possible on an https login page it is more difficult and less common.
MikeDawg
1 Posts
A two-factor such as Duo:Security doesn't stop a live MitM attack. End user's don't know their IP addresses, and assuming the attacher is on the same LAN or a segment away conducting the MitM attack, the city info isn't going to help either. In fact, since my Comcast says I'm 700 miles away, and my cell wireless says 200 miles away, that'll be pretty worthless information as well and just generate support calls.

Two factor is great to prevent loss/theft of client private key, not MitM attack.

To prevent MitM attack for the initial connection (where no server public key has been exchanged), put SSHFP keys in a DNS zone secured with DNSSEC and use a trusted local DNS resolver supporting DNSSEC on the client end (and/or local stub resolver to verify the DNSSEC signatures).

Gibson's PPP isn't two-factor. It's still something you know, not something you have or are.

IPv6-only is great, until the network breaks. IPv6 network breakage happens often enough that I would not rely on it (yet).

Port-knock with IPTables is a great low-budget solution to stop port scans. You can then leave your SSH on default tcp/22 since nothing can access it without the right port-knock sequence, or you can still move it for more obscurity.
MikeDawg
42 Posts
@Jason R.

Two factor is any two of:
- Something you know
- Something you have
- Something you are

Your password is something you know, PPP implements something you have... you carry a piece of paper with codes and cross them off as you use them. (Yes I suppose you could memorize the whole sheet of passwords... but that's not its point.) Its not as good as a Yubikey... but its hella free-er ;_)
Anonymous
I work of an ISP, we sniff all the time for debugging reasons. And if some of admins where more black hat, we could see all of our customers clear text passwords and data. Use encryption and ditch telnet/FTP/
Peter P

8 Posts

Sign Up for Free or Log In to start participating in the conversation!