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
Solved

OpenSSH secure enough for internet

Posted on 2004-10-18
5
338 Views
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.

Thanks,
DMS
0
Comment
Question by:DMS-X
5 Comments
 
LVL 13

Assisted Solution

by:Caseybea
Caseybea earned 100 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.
0
 
LVL 5

Assisted Solution

by:paranoidcookie
paranoidcookie earned 50 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.
0
 
LVL 1

Accepted Solution

by:
gianluca_marcari earned 300 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.
0
 
LVL 34

Assisted Solution

by:PsiCop
PsiCop earned 50 total points
ID: 12341143
I would also make sure you use SSH v2 and not SSH v1.
0
 
LVL 1

Author Comment

by:DMS-X
ID: 12349535
Awsome, thanks everyone.

gianluca_marcari,

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 : )
0

Featured Post

Ransomware-A Revenue Bonanza for Service Providers

Ransomware – malware that gets on your customers’ computers, encrypts their data, and extorts a hefty ransom for the decryption keys – is a surging new threat.  The purpose of this eBook is to educate the reader about ransomware attacks.

Question has a verified solution.

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

This is the error message I got (CODE) Error caused by incompatible libmp3lame 3.98-2 with ffmpeg I've googled this error message and found out sometimes it attaches this note "can be treated with downgrade libmp3lame to version 3.97 or 3.98" …
Fine Tune your automatic Updates for Ubuntu / Debian
Learn several ways to interact with files and get file information from the bash shell. ls lists the contents of a directory: Using the -a flag displays hidden files: Using the -l flag formats the output in a long list: The file command gives us mor…
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.

837 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