• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 270
  • Last Modified:

So is SSH secure or not? - a general discussion

What's the deal with SSH? At my company, we're not allowed to access a server using ssh because it makes our client machine vulnerable. Can this be true?
  • 2
  • 2
  • 2
  • +4
1 Solution
Secure Shell v1(SSH1)is no longer considered as a secure means for remote command-line management of systems.  SSH2 does however, provide a more secure mode of access.  I am sure that there will be more versions needed (as hackers find ways to crack the current level of protection), but for now SSH2 is reasonably secure.  Based on the current vulnerability scans (utilizing Harris Stat and ISS scanners)performed at the sites that I support, SSH provides a secure and reliable means of connectivity.
The problem I think your company is trying to address is that there has been a lot of exploit code released for SSH. Current versions are secure but I suppose they are concerned about the lag between a new vulnerability/exploit being released and ssh/d being updated to fix the hole. Especially if you have a lot of servers.

If you are managing multiple clients/sites/hosts over untrusted networks then VPNs are sometimes not an option - especially because of companies who like to bend IPSec as they don't believe in standards..... Not to mention IPSec & NAT.

I'd be interested to know what people think is an alternative to SSH in these situations?
There are some issues with SSH however if configured properly and with other security measures it can be pretty secure.

Applications which use clear text transmission of usernames and passwords should be a legacy of the past, since the SSH protocol provides effective, easy to use, secure remote access. Security, however, is a chain of elements and it is only as good as its weakest link. With remote access, the weakest link is the user. Therefore, the ability of SSH to subvert intrusion detection systems must be mitigated for some environments. Using the SSH daemon as a sensor in an intrusion detection system solves this problem by guaranteeing a secure connection, yet allowing signature, anomaly, and keyword detections through to the highest level of the communication. This system is probably not appropriate for all sites, especially those where there are privacy or legal issues; however, it is appropriate for more security minded environments.

You can read here til your eyes bleed about problems with SSH.


Th reason your company doesn't allow it is because it's constantly being hacked for expliots, after all it's supposed to help security right? This gives people a false sense of security so they never keep up with maintaining security patches and upgrades. Your company may see it as more trouble then whats its worth. Not to mention it requires more CPU power from the server it runs on and can be a resource hog especially on a busy web server.

Hope this sheds some light,


Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

I'll add my $.02 here.

First, I agree with ferg-o that SSH has a bad reputation because there have been many exploits for it over the years.

However, as DHNoble points out, many of these are for SSH Protocol 1.x SSH implementations, and these implementations are a) immature and b) are based on a protocol that has a fundamental man-in-the-middle flaw.

Instead, anyone considering SSH should use SSH protocol 2 only, which is supported both by commercial SSH code and free SSH implementations such as OpenSSH and PuTTY.

That said, these are all _server_ side issues we're talking about here.

On the client side, there have been some known problems, but none were SSH specific, but rather related to problems found in other systems as well. For example, the current chatter in the SSH community deals with buffer overflows in PuTTY's handling of escape strings for setting the title bar. But this isn't in the SSH code, but rather in the terminal-emulation code, and affects lots of other terminal-emulators beside PuTTY, so it doesn't matter whether you SSH, Telnet, etc.

And, SSH is certainly better than Telnet. And SFTP/SCP certainly better than FTP.

But, that doesn't mean you really want to allow SSH over the Internet into your site.

Around here we require SSH access be wrapped in an IPSec VPN when coming from the Internet.
rfr1tzAuthor Commented:
How about ferq-o's question - what can be used instead of SSH?
Well, you've got Telnet/FTP/rsh/rlogin, but they don't protect data confidentiality, including passwords.

Then there's Kerberized Telnet/FTP/rsh/rlogin, which protects some passwords(doesn't protect su/sudo passwords, for example), but not anything else. And Kerberos implementations have no better a history of security bugs than SSH.

Then there's Telnet/FTP/rsh/rlogin over SSL, but that's not widely supported. And OpenSSL has no better a security history than OpenSSH.

And there's Telnet/FTP/rsh/rlogin over IPsec (not VPN's but direct peer-to-peer IPsec). This is pretty good choice if both your client and server OS support IPsec directly and you can deal with setting up the IPsec associations (a pain). But you still don't likely want to allow this directly from the Internet as any firewalls in the way won't be able to tell what's inside the IPsec tunnels to see if it's allowed traffic or not.  Plus this doesn't scale since you need a different IPsec association for each server.

Which means you really want the IPsec association to the firewall, and not to the end server (i.e., to use a VPN with the firewall controling the traffic).

But then you still don't want to run raw Telnet/FTP/rsh/rlogin from the firewall to the end-servers, so you'd need second IPsec association between the firewall/vpn-endpoint. But that doesn't work because a) the problem is recursive for systems behind multiple firewalls and b) you still have the problem of one IPsec association to each server.

Which means you really want to tunnel another protocol inside the VPN that then goes to the end servers.

Now, possible protocols to tunnel are:
o Telnet, etc.
o Kerberized Telnet, etc.
o SSL-ized Telnet, etc.
o Telnet, etc. over IPsec.

And, I submit, by recursive investigation of the issues with the other options, we can conclude that SSH is the natural choice for what to run inside the tunnel.

So, in conclusion, the best choice is to run an IPsec VPN over the Internet and then use SSH _inside_ the tunnel to actually manage your systems.
keep updated and do latest patch.
but yet SSH is much secure than telnet/rlogin.
The main question...are you accessing a server within your own net/vlan?  If so, then your company is probably concerned with being hacked from within, or else, from someone who has gained access through your firewall.  If this is the case, then SSh2 should be sufficient to keep them from seeing your login activities.  If you are accessing a server via the internet or dial-up, then use VPN/tunneling and then you should be fine from site to site. Either case...SSh2 is currently the accepted protocol for remote access.  Instead of ftp, use scp for secure file transfers in either case.  Putty is ok, but check out PenguiNet from Siliconcircus.com, you will like it.
hi, i'm new...
so, how can i deny SSH access from a speciffic IP?
Ask your own question so we can get points!

Because it's Friday and beer-o-clock:

To deny hosts create /etc/hosts.deny and add an entry like in.sshd: xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy

What most people do is have in.sshd: ALL and then have entries in /etc/hosts.allow but each to their own......

I am basing this on the assumption that you are running unix. If not then the best way to deny people from using SSH is not to run it at all because the bad guys are already in courtesy of netbios. However I digress......

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

  • 2
  • 2
  • 2
  • +4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now