Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium


OpenSSH secure enough for internet

Posted on 2004-10-18
Medium Priority
Last Modified: 2012-06-27
I have have read some conflicting arguments as to weather or not SSH is secure enough for internet usage. Mostly it seems that it is considered secure enough to run over the internet. I have read that as long as you are running the latest version of OpenSSH at all times that you are very safe. Yet others say that SSH in general has had to many problems in the past to trust. OpenBSD develops Open SSH, OpenBSD has always boasted one the safest *nix, so I would think that this is a plus.

Any opinions.

Question by:DMS-X
LVL 13

Assisted Solution

Caseybea earned 400 total points
ID: 12340380
Yes, OpenSSH is definately secure enough.   NOTE:: A big part of this is based on the KEYS that you use-  it's strongly recommended to usa DSA keys (1024 bit), and you'll be fine.

I work in a very paranoid research wing of a medical school; we use SSH exclusively for remote access.  

OpenSSH is also flexible enough for you to "ride" other applications on top of it, such as graphical login tools like VNC, etc.

Note too, that you CAN mix and match clients and servers - for example, the ssh client from ssh.com WILL work with a server running OpenSSH.   There is a bit of tweaking to do with the format of the client keys as they sit on the server, all reasonably well-documented.

Assisted Solution

paranoidcookie earned 200 total points
ID: 12340673
There have been a few high profile problems with open ssh however more recently its been very secure. I would definatly say turn off root login directly, if you want to use root log on as a non privilaged user then use su.
Also consider using only Key based logins rather than password, protect keys with a passphrase and youll have a very secure server.

Accepted Solution

gianluca_marcari earned 1200 total points
ID: 12340958
OpenSSH security has been improving steadily, with recent features such as privilege separation guaranteeing that even a possible future exploit only has very, very limited chance to do any damage.

But, OpenSSH (or just any SSH implementation, for the matter) is a framework: there is a host of underlying crypto algorithms, such as RSA/DSA, which are only used to swap a "session key" and not to encrypt the whole session, as DES/TripleDES/Blowfish/CAST/AES (very fast symmetric cyphers to protect the actual session) and some integrity verification protocols (MD5/SHA1).

Why so big a variety? Because even the SSH authors know that one of these protocols might be compromised at any time (NSA has been rumored to be able to crack DES for ages, but nowadays it's pointless talk, since single-DES has become very vulnerable to plain brute forcing when adequate computing resources are applied. Computing power grew a lot since the 70s)

So, the idea is to have as many supported protocols as possible, for every functionality which is key to the integrity/secrecy/authentication of the SSH session, in order be still able to do secure connections even if one or more of those protocols get compromised.

Another important factor is the user: too often programs display warnings which get ignored. Upon connection to an unknown server, every SSH implementation asks the user whether he trusts the remote host (displaying the key fingerprint of the remote server). I've rarely seen, in my whole life, anyone actually bothering to verify the fingerprint. Even so, when you already "know" a host (you have its key stored in .ssh/known_hosts or known_hosts2) and its key changes (server upgrade or session hijacking? Maybe the cluster switched?) OpenSSH will display a huge warning and *refuse* to continue until you manually edit your hostkey file and remove or update the offending key. Even in those extreme cases, users, when clued enough to understand what's going on, would often simply edit out the key  and go ahead. On Windows, it's even worse - many implementations (like the otherwise excellent PuTTY by Simon Tatham) will allow you to go ahead with a couple mouseclicks.

Another human factor to consider is of course the password: having state-of-the-art, military grade crypto engines is pointless if passwords are too easy or so complicated that your users will write them down. In this respect, public-key identities, as paranoidcookie correctly pointed out, offer a much better safety: You could have your identity unlocked by a passphrase and loaded into a key agent (ssh-agent on OpenSSH, Pageant on PuTTY) at the beginning of your computing session and be able to access all systems where your key is valid without having to type any other password; you are much safer trying to authenticate to a potentially compromised server (no risk doing that with an RSA/DSA key, while typing your password straight into an untrusted machine would be a very, very bad idea).

Many commercial implementations try to improve the security of a Key Agent system with some other means like smartcards or USB tokens: sometimes your users will be just unable to "accept" the idea of a key agent system because it's too obscure to them, and giving them a physical object will put some user friendliness back into the loop (for a price).

As too many people in the security world never stop pointing out, users are and will likely always be the most important factor. Security conscious users who treat their passwords / codes / identities with appropriate care and who pay attention to the messages on screen are every administrator's dream. No point in using the best implementations (OpenSSH rocks - Theo de Raadt and the other guys behind it and OpenBSD are among the best and most reputable programmers in the world when it comes to a security conscious approach) if your users are such a gaping security hole.
LVL 34

Assisted Solution

PsiCop earned 200 total points
ID: 12341143
I would also make sure you use SSH v2 and not SSH v1.

Author Comment

ID: 12349535
Awsome, thanks everyone.


Thanks alot that made alot of sense. I will be the only one using ssh so users are not an issue. I have been using PC Anywhere to get into a windows computer behind the site firewall and from there I have been using ssh to administer the linux email server. I wanted to eliminate PC Anywhere completely. Hopefully we will have vpn up and working soon also : )

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

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

How many times have you wanted to quickly do the same thing to a list but found yourself typing it again and again? I first figured out a small time saver with the up arrow to recall the last command but that can only get you so far if you have a bi…
Often times it's very very easy to extend a volume on a Linux instance in AWS, but impossible to shrink it. I wanted to contribute to the experts-exchange community a way of providing a procedure that works on an AWS instance. It can also be used on…
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
This demo shows you how to set up the containerized NetScaler CPX with NetScaler Management and Analytics System in a non-routable Mesos/Marathon environment for use with Micro-Services applications.
Suggested Courses
Course of the Month10 days, 11 hours left to enroll

572 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