OpenSSH Gets Even More Suspicious

If you remotely administer any computers, or need to check your email over an untrusted network, odds are you're already familiar with the wonders of OpenSSH. Markus Friedl yesterday posted a release announcement for the newest version, OpenSSH 3.3. Privilege separation in OpenSSH is now enabled by default, another sign of the entire OpenBSD project's appropriate paranoia.

Comments

More suspicious of OpenSSH?

[jamus]

The way I read the headline, "OpenSSH Gets Even More Suspicious", it sounded like we're supposed to be more suspicious of OpenSSH.

What has the world come to, where we can't even trust OpenSSH?

Oh, OpenSSH is more suspicious of its environment! That makes more sense! :P

Impressive

[dybdahl]

Open Source software continues to impress me after so many years. This again proves, how much better software can be, if you remove management, lawyers, sales department etc. and make good programmers work together without short-term profit in mind.

Re:Even OpenBSD developers can be vain...

[neuroticia]

You mean they didn't accept the patch you wrote for them!? Ludicrous. Maybe they're too busy being whipped along by people who don't give anything back to the OS community to evaluate your code. ;) I mean... You obviously feel strongly about it so you HAVE to have written a patch, no?

If they KNOW about it, and I'm sure they do, then they'll patch it. They're not Microsoft, afterall. In the meantime, if you're not a developer, lay off the whip. Like you said- the bug is recent, if they let a few months fly by without doing anything then you can start complaining.

-Sara

Re:No thanks

[Admiral Burrito]

Telnet wins hands down. Just use a difficult password, and change it frequently.

Except telnet does zero encryption. It is a trivial matter to sniff passwords from an unencrypted link, and inserting data is not much harder. Changing passwords frequently is kind of pointless if you are setting your new password over an insecure link.

One-time passwords are better, but they are still vulnerable to TCP insertion attacks.

Yes, these things have been exploited in the wild. SSH exists for a reason.

If security problems in SSH itself worry you (and they should), privilidge-seperated ssh is the answer. By seperating the privilidged code from the code that talks to the client and defining a good interface between them, it limits the amount of stuff that can go wrong and the quantity of code that needs to be audited.

Re:Packet sniffing

[GigsVT]

Who says the attack is local? Your packets cross from 5 to 20 hops before getting to their destination. Routers can be compromised, theough security weaknesses or through deliberate government interference. OpenSSH also allows for host authentication, so you know you are really talking to who you think you are. A secure transport is about more than some guy on your LAN sniffing your password.

No thanks???

[Nonesuch]

kevinqtipreedy writes:

Trust old telnet works fine, unless you are worried about people seeing your passwords, and everything you are doing.

And you're not?

That is the point of ssh; it encrypts what you do, including passwords so it can not be seen by people on the same network segment.

That is one of the many points of SSH. The protocol also supports public-key authentication, so you don't need a "shared secret" (reusable password) at all. The protocol also provides authentication that you are really talking to the remote server you think you are, preventing MITM attacks (e.g. spoofing DNS so your telnet session goes through my server). SSH also offers compression, for faster file transfers. And port forwarding, including X11. and much more.

A difficult password is just as important on telnet as in is on ssh because they can still be cracked either way.

It is unlikely that anybody is going to bother cracking your telnet password- if they don't sniff it, then there are few scenarios where somebody has the ability to obtain the shadow file from a server but does not already have root.

One issue with password cracking and sniffing is that it is critical to have a unique password for every site you have accounts at.

Under SSH, I can set up systems so that password logins only work on the physical console, not over the network. I can create a strong private key (passphrase protected) and install my public key on the remote servers, using the same key for many different servers without the security issues that come from using the same password across disparate sites.

Re:Necessary and useful

[__past__]

FreeBSD's goal is to create a reliable, free UNIX (it may not meet your definition of free, but that's another story)

I know it's probably unwise to make this up, but how exactly do you define "free" in a way it doesn't match FreeBSDs license?

The usual complaint from people favoring the GPL is that it's not Copyleft, so it's free even for people not interested in freedom for anyone but themselves, but I think nobody - from the FSF to Microsoft - would say it is not free itself.

Re:Security of SSH

[Dwonis]

I agree. IP over SSH is a bad idea for the same reasons why TCP over TCP is a bad idea.

Re:Necessary and useful

[Jeremi]

Code that's already out there will always be free to "roam the wild plains" ... it can't be made non-free again. People can base non-free derivative products off it but that still doesn't "un-free" the original code...

Technically, you're correct, but in the larger view, there is a historical pattern where free code gets 'adopted' by a company, and the company adds lots of functionality to the free code, so that eventually the free code is no longer competitive, and everyone switches over to using the closed-source product. At that point, the code is no longer free (except for the "old" code which is no longer useful or used, and thus doesn't count). This is what happened to Unix in the 70's and 80's, leading to Unix's fragmentation and irrelevance as a platform. With GPL code, you don't have to worry so much about v2.0 coming out as closed-source, leaving you with a choice between staying with v1.0 or losing the benefits of open source.