OpenSSH 4.2 released

BSDForums writes "OpenSSH 4.2 has been released. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Changes since OpenSSH 4.1 include security bug fixes relating to GatewayPorts, and GSSAPI, which eliminates the risk of credentials being inadvertently exposed to an untrusted user/host. A new compression method, proactive changes for signed vs. unsigned integer bugs, and many additional bugfixes and improvements highlight this release."

Re:The new compression method is pretty fantastic.

[nurb432]

That might make remote X11 useable on a cable modem..

Re:Why you shouldn't use OpenSSH

[CyricZ]

There is no question that Mr. deRaadt is quite outspoken. But he can produce some damn fine and mighty secure code. I have nothing but the utmost respect for his coding abilities, even if his public relations skill are lacking.

Frankly, I'd rather put up with arrogance and have access to amazing code, rather than dealing with a nice person who can't write code worthy of a cockfool.

It's our pleasure, Mr. Gates.

[CyricZ]

No problem, Bill. After all, open source software (especially that under the BSD license) is meant to be shared and used by all, basically however they see fit. That's the name of the game, Mr. Gates.

Still no logging of sftp/scp transfers?

[GeekBoy]

Sigh. Back to my commercial (vandyke vshelld) implementation....

Re:Why you shouldn't use OpenSSH

[Yaa 101]

Theo de Raadt is ok really, he puts his coding where his mouth is. And at least he's not a corporate ass-licker like a lot of others. He does not corrupt his vision with corporate goodies.

Re:Why you shouldn't use OpenSSH

[slavemowgli]

Admittedly, yes, Theo is (or at least can be) quite an asshole. But what does that have to do with the quality of OpenSSH (or OpenBSD)?

Like him or not, but it's a great program, and not using it just because you don't like the lead developer, when there are no actual reasons not to, is stupid.

Which idiot makes this insightfull?

[Yaa 101]

So we must stop using one of the worlds best security software because somebody does not like Theo de Raadt?

Are you mod fucking insane?

Re:Why you shouldn't use OpenSSH

[Ann Elk]

As a friend of mine says, "It's OK if they call you an asshole, if they say it with awe."

Theo is certainly opinionated, and he may or may not be an asshole, but his group produces some damn fine software. You may not like his methods, but it's difficult to argue with his results.

Re:It's our pleasure, Mr. Gates.

[ArbitraryConstant]

The BSD licensing has made it possible for commercial OSes to have an SSH implementation by default. That ubiquity is what killed telnet. By helping companies like Microsoft, Sun, and Apple, the OpenSSH project has helped everyone.

Re:Why you shouldn't use OpenSSH

[ArbitraryConstant]

I've met Stallman and de Raadt and they're both assholes. But the world needs a few people that are willing to be assholes.

He gets results. For example, giving out contact information isn't the nicest way to get hardware docs and firmware, but it works.

Re:Why you shouldn't use OpenSSH

[Elektroschock]

Talented people, real genius, think of Mozart and others... they are usually a little bit mad and they deserve tolerance.

They can take the freedom to be different and we have to understand that we have to adopt to them.

Re:Still no logging of sftp/scp transfers?

[RAMMS+EIN]

As far as I understand, both scp and sftp are actually implemented by separate binaries on the server side. Why don't you just replace those binaries with ones that do your logging and defer the actual work to the original binaries?

Re:Please excuse my obvious ass-kissing

[Kynde]

Bloody hell. I've been using openssh ever since it came out and quite a while the old Tatu Ylönen's ssh before that and type all those lengthy [e-mail]: prefixes day in day out without knowing about those aliases.

The fact is that in OSS world one should, atleast once a month raise fingers from the keyboard and stop to think "What am I missing from my daily environment? Are stupid, repetetive or borings things that I do all too frequently?". The odds are that I could easily fix most of them swiftly and the ones that might require moderate amounts of work to happen it's quite likely that someone hast stumbled on those very same issues before me and fixed them. (and experience in *nix world teaches me that frequently the fix is quite brilliant)

Re:Slowing down dictionary attacks

[RAMMS+EIN]

``UNIX has had exponential backoffs forever. Mess up one time, you get a 1 second delay. Mess up twice, you get to wait 2 seconds, etc. I wonder why that couldn't be done in an ssh context.''

This exponential backoff system works when you're trying to log in from a tty. When SSH, the system doesn't know whether this is the same user trying to authenticate. It's similar to sitting in front of a Linux box, trying to log in on VT 1, and when it backs off, switch to VT 2, and so on.

The situation could be improved somewhat by sshd tracking failed logins by IP address, and disallowing that IP address from logging in for a while. However, this complicates sshd and isn't really bullet proof, what with NAT making any number of machines appear to have the same IP address.

Re:Increased default key size.

[Malor]

As far as I know, the computational overhead of the higher-bit keys isn't that significant, so it's probably not doing any actual harm. It'll slow down initial key negotiation and session setup, but it shouldn't affect traffic overhead, because that's encrypted with a symmetric cipher that was negotiated with the (very slow) public-key protocol. You'd probably only notice the overhead if you were running a server with many, many session setups. If it impacted you, generating a smaller key would be trivial.

The larger key will make your data more secure on the wire, in transit, but the weakest point has always been the key's passphrase. A 32768-bit key is just as crackable as a 256-bit key if you have physical access to the encrypted keyfile.

Improving transit security isn't an inherently bad idea, but it's making the strongest link in the chain even stronger. It probably won't do that much to increase overall security.

Re:Increased default key size.

[h4rm0ny]

Cracking it on the first attempt and cracking it on the 10^50th attempt have equal probabilities.

True, but both probabilities are minute. The median of that range is 5*10^49 meaning that's the average number of tries you need. If you got lucky and found it in the first 10%, that's 10^49. If someone wanting to spy on you can muster the resources to crack that in a human lifetime, you've made an enemy of God!

Quantum computing opens up some interesting possibilities, but if a hypothetical Quantum computer in the year 2015 could search 1x10^23 keys per second (more than that massive distributed Internet project a while ago), it would still take millions of years on average.

10^50 is a big number.

Re:Proactive?

[glitch23]

Proactive in this case means "before a cracker finds the bugs and exploits them" and not "before they were created to begin with". So it depends on what their point of view was when they wrote it as to whether or not they used the word correctly.