Slashdot Mirror
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."
And it's a dupe, too. Remember when editors actually read submissions?
Remember when editors actually read submissions?
No.
For the awesome tool. Ssh, scp, and ssh tunnels are an integral part of how I accomplish things at work, and how I bypass corporate firewalls to use bittorrent. Thanks for the outstanding work.
The project was first released as OpenSSH 5 years ago today. The project was started, however, much earlier than that.
I'm sorry. The number you have reached is imaginary. Please rotate your phone 90 degrees and try again.
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."
TFA is insufficient and history can be found here: http://www.openssh.com/history.html/.
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.
If my grammar and spelling are off, I am [distracted/tired/careless] (take your pick)
Don't worry - you'll see the dupe in 10 days.
Remember when the US Federal Gov'nt was having a royal fit about encryption and then just kinda "gave up"? Unless they can crack it, they wouldn't have given up (use 4096 encryption, people!)
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.
So hats off to OpenSSH, y'all. :)
Thank god that OpenBSD cares enough to make the portable version of OpenSSH. I've used OpenSSH to make my machines more secure on everything from Solaris to Linux to *BSD.
Kudos!
The more you know, the less you understand.
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...
Ask Slashdot: Where bad ideas meet poor googling skills.
Manager: "that is how they have always worked"
...
Manager: "some of them just don't know how to use ssh."
You: "{manager}, Telnet is a huge security risk and it is only a matter of time before we are screwed royally by this. I recommend that we plan on disabling telnet in the near future on all hosts. Before that time, I will send out an E-Mail to all affected staff with instructions for use and notification of when telnet services will be disabled. I think this is a good idea, what do you think?"
After that, your responsibility in the matter is moot.
You: Documents that you brought this issue up with your manager in the event that he/she decides not to pursue your idea, covering your ass and placing as much blame on your manager for any fuck ups that occur as a result of his/her stupidity.
If you weren't in a position to suggest such policy, then I pity you and am glad you got out of such a job.
From the Changelog for OpenSSH 3.9:
Hope this helps. :)
quidquid latine dictum sit altum videtur.
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
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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, it seems like the supported symmetric ciphers only go up to 256 bits.
Never mind that telnet/rsh have no security at all, apparently if security exists, it has to be "approved". Now, I don't dispute the idea of having validated security, but I do dispute the claim that no security at all is preferable.
It also neglects the fact that SSH is merely the program, that the encryption algorithm used is AES, which is most certainly a FIPS standard.
In other words, it's not just that "users don't get it" - although that is often the case. The problem is also malignant attitudes in management that regard total insecurity as politically more acceptable.
IMHO, if management enacts a policy that cripples security or eliminates it entirely, then management should be culpable. Encryption may be explicitly covered by FIPS, but that doesn't mean insecurity should be an acceptable standard for anyone.
In the case described by the parent post, that of users not knowing how to use SSH, fine. Mandate that all computers use host-to-host IPSec. The users then don't need to know a damn thing, but the connections are just as secure.
In other words, ignorance can sometimes be an excuse, but this isn't one of those times, as all it would take is ticking a checkbox under Windows and not doing a whole lot more under Linux. They can remain blissfully ignorant, continue to be stupid, but still remain perfectly safe.
IPSec and SSH are not just good ideas, they SHOULD be the lore. (Not law, just lore. Though making telnet a crime might not be such a bad idea...)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Seriously, I can understand mispelling complicated words, but how do you not know how to spell yay?
So you consider "misspelling" a complicated word then I guess?
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.
Do you care about the security of your wireless mouse?
No, "SSH" has been around for a long time, it predates the OpenSSH client and probably your website.
I rarely criticize things I don't care about.
Personally, I think the "OMG Telnet!" thing has gone way overboard when you are talking about internal networks.
Sure you _should_ use encrypted protocols, but when you look at a realworld network, it's full of NFS, SMB, FTP, SMTP, IMAP, HTTP, RPC, 5250/3270 and a gazillion other things that pass sensitive information in plaintext. Telnet is just the tip of the iceburg and the easiest to replace. Ultimate one should be looking at IPSec or VPN rather than making a big deal about SSH vs Telnet.
Now, if you are typing a root password onto a Internet host, that's another story, but I sincerely hope you don't have thousands of developers with root access somewhere.
Whenever I hear the word 'Innovation', I reach for my pistol.
Sadly, or not, I'm using SecurID from RSA Security and the PAM module requires that I shut off Privsep.
======== In the future, everything will be artificial. ========