?
Solved

So is SSH secure or not? - a general discussion

Posted on 2003-03-11
10
Medium Priority
?
268 Views
Last Modified: 2010-04-11
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?
0
Comment
Question by:rfr1tz
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
  • 2
  • 2
  • +4
10 Comments
 

Expert Comment

by:DHNoble
ID: 8115832
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.
0
 
LVL 4

Expert Comment

by:ferg-o
ID: 8116350
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?
0
 
LVL 9

Expert Comment

by:TooKoolKris
ID: 8117059
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.

http://search.cert.org/query.html?rq=0&ht=0&qp=&qs=&qc=&pw=100%25&ws=1&la=&qm=0&st=1&nh=25&lk=1&rf=2&oq=&rq=0&si=1&col=allcert&col=trandedu&col=vulnotes&col=techtips&col=research&col=certadv&col=incnotes&col=secimp&qt=ssh&x=14&y=7

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,

TKK
0
When ransomware hits your clients, what do you do?

MSPs: Endpoint security isn’t enough to prevent ransomware.
As the impact and severity of crypto ransomware attacks has grown, Webroot fought back, not just by building a next-gen endpoint solution capable of preventing ransomware attacks but also by being a thought leader.

 
LVL 14

Expert Comment

by:chris_calabrese
ID: 8121629
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.
0
 
LVL 3

Author Comment

by:rfr1tz
ID: 8121714
How about ferq-o's question - what can be used instead of SSH?
0
 
LVL 14

Accepted Solution

by:
chris_calabrese earned 800 total points
ID: 8122811
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 SSH
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.
0
 

Expert Comment

by:daniaz
ID: 8126813
keep updated and do latest patch.
but yet SSH is much secure than telnet/rlogin.
0
 

Expert Comment

by:DHNoble
ID: 8133625
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.
0
 

Expert Comment

by:khrypt
ID: 8570582
hi, i'm new...
so, how can i deny SSH access from a speciffic IP?
0
 
LVL 4

Expert Comment

by:ferg-o
ID: 8570680
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......
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

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

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

A look at what happened in the Verizon cloud breach.
This article is written by John Gates, CISSP. Gates, the SNUG President-Elect, currently holds the position of Manager of Information Systems at Lake Park High School in Roselle, Illinois.
With Secure Portal Encryption, the recipient is sent a link to their email address directing them to the email laundry delivery page. From there, the recipient will be required to enter a user name and password to enter the page. Once the recipient …
The Email Laundry PDF encryption service allows companies to send confidential encrypted  emails to anybody. The PDF document can also contain attachments that are embedded in the encrypted PDF. The password is randomly generated by The Email Laundr…

762 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question