OpenSSH Turns Five Years Old

heydrick writes "The OpenSSH project is five years old. Project member Damien Miller writes, 'Five years ago, in late September 1999, the OpenSSH project was started. It began with an audit, cleanup and update of the last free version of Tatu Ylonen's legacy ssh-1.2.12 code. The project quickly gathered pace, attracting a portability effort and, in early 2000, an independent implementation of version 2 of the SSH protocol. Since then, OpenSSH has led in the implementation of proactive security techniques such as privilege separation & auto-reexecution.' Yaa for OpenSSH."

This story turns 8 months old

[Anonymous Coward]

And it's a dupe [slashdot.org], too. Remember when editors actually read submissions?

5 years since the first *release*

[heatdeath]

The project was first released as OpenSSH 5 years ago today. The project was started, however, much earlier than that.

5 years since OpenSSH 2.0

[ikkibr]

From openssh.com: "With the OpenBSD 2.6 release out of the way, Markus Friedl decided to pursue SSH 2 protocol support. Slaving away for months, he managed to keep OpenSSH slim and lean, while at the same time managing to turn it into a single piece of software that could do both the SSH 1 and SSH 2 protocols. This version, called OpenSSH 2.0, shipped with OpenBSD 2.7 on June 15, 2000. Most of the checking of Markus' changes were done by Niels Provos and Theo de Raadt. Bob Beck is to be thanked for updating OpenSSL to a newer version."

Re:What?

[suitepotato]

TFA is insufficient and history can be found here: http://www.openssh.com/history.html/ [openssh.com].

That marked the OpenSSH 1.2.2 release, which was shipped with OpenBSD 2.6 in December 1, 1999.

Further...

With the OpenBSD 2.6 release out of the way, Markus Friedl decided to pursue SSH 2 protocol support. Slaving away for months, he managed to keep OpenSSH slim and lean, while at the same time managing to turn it into a single piece of software that could do both the SSH 1 and SSH 2 protocols. This version, called OpenSSH 2.0, shipped with OpenBSD 2.7 on June 15, 2000.

That would make it over five years old, much older if you count the groundwork laid with OSSH, and 2.0 is coming up on its fifth birthday.

I use ports of it with public key authentication on Windows and Linux. I salute the people who've worked so hard on making and keeping this going. OpenSSH is at the top of my "must have working or it's a no-go" list of tools for remote access and security.

Re:Ettercap team claim SSH / SSL is easy crackable

[Anonymous Coward]

Newsforge interview [newsforge.com]

They are also trying to get publicity.

[Some Random Username]

Yes, SSL and SSH are vulnerable to MITM attacks if used incorectly. This is not news, and has been known for years. Trying to pretend this is new and interesting and "easily crackable" is dishonest.

OpenSSH

[Mark_MF-WN]

SSH rules -- definitely one of the triumphs of modern software development. An absolutely essential set of tools, with open standards, competing implementations, and availability on every platform conceivable.

So hats off to OpenSSH, y'all. :)

SSH is wonderful, and yet users still don't get it

[Rantastic]

I love ssh. I use it everyday.

Where I used to work (I quit 2 months ago) it was a contant battle to get users to use ssh instead of telnet. Yes, that's right, telnet. When I first started working there, a little over a year ago, I was shocked to discover that thousands (no exageration) of developers were still using telnet to access unix hosts.

When I asked my manager about this, his explanations ranged from "that is how they have always worked" to "some of them just don't know how to use ssh."

When I spoke to the users themselves they just could not understand what is wrong telnet.

Of course, I should point out that this is also a company that suffered a massive data theft (something like 90,000 email addresses) last year...

Re:Cool...

[Anonymous Coward]

I wish I could control what fowarding can occur in the config file on the server. Access lists would be great here.

If you use public-key authentication (and users don't have r/w access to the ~/.ssh/authorized_keys file, you can put restrictions on what each key can forward to.

Re:auto-reexecution?

[slavemowgli]

From the Changelog for OpenSSH 3.9:

Make sshd(8) re-execute itself on accepting a new connection. This security measure ensures that all execute-time randomisations are reapplied for each connection rather than once, for the master process' lifetime. This includes mmap and malloc mappings, shared library addressing, shared library mapping order, ProPolice and StackGhost cookies on systems that support such things.

Hope this helps. :)

Re:Cool...

[petermgreen]

if you use privilage seperation then tunnels come from the userid that created them.

therefore you should be able to control them with iptables user matching

Re:Ettercap team claim SSH / SSL is easy crackable

[packetl0ss]

What symmetric cipher, that ssh uses, even supports 4096 bit encryption? I thought bits that high were only supported for public/private keys but not the symmetric ciphers themself. According to the ssh manual page [openbsd.org], it seems like the supported symmetric ciphers only go up to 256 bits.

Re:Ettercap team claim SSH / SSL is easy crackable

[kasperd]

Would it be practical to have a summetric cipher with 4094 bit encryption, or would that make things run a bit slow?

256 bit AES use 14 rounds with a 128 bit key in each round. Rather than generating the 1792 bit keyschedule from the 256 bit key, you could just use a 1792 bit key. The speed would be the same as 256 bit AES. But don't expect it to be much more secure.

Most likely the cipher isn't the weakest point anyway. If you want to have 256 bits of entropy in your password you need aproximately 42 random characters.