[Last Call] Learn about multicloud storage options and how to improve your company's cloud strategy. Register Now


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
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
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

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Question has a verified solution.

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

Introduction We as admins face situation where we need to redirect websites to another. This may be required as a part of an upgrade keeping the old URL but website should be served from new URL. This document would brief you on different ways ca…
In the first part of this tutorial we will cover the prerequisites for installing SQL Server vNext on Linux.
Learn how to get help with Linux/Unix bash shell commands. Use help to read help documents for built in bash shell commands.: Use man to interface with the online reference manuals for shell commands.: Use man to search man pages for unknown command…
Connecting to an Amazon Linux EC2 Instance from Windows Using PuTTY.
Suggested Courses
Course of the Month12 days, 22 hours left to enroll

650 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