Slashdot Mirror
OpenSSH 5.4 Released
HipToday writes "As posted on the OpenBSD Journal, OpenSSH 5.4 has been released: 'Some highlights of this release are the disabling of protocol 1 by default, certificate authentication, a new "netcat mode," many changes on the sftp front (both client and server) and a collection of assorted bugfixes. The new release can already be found on a large number of mirrors and of course on www.openssh.com.'"
FTFA:
* Many improvements to the sftp(1) client, many of which were implemented by Carlos Silva through the Google Summer of Code program:...
... - Add recursive transfer support for get/put and on the commandline
(Alas!!)
Whole host of other improvements and bugfixes; give it read if SSH is pertinent to your environment....
Please do tell what are the vital differences from version 1.4 made in 2008, because I think you're trolling. It looks like all RFCs normally look, either you haven't read many and don't have a clue what you're talking about or you are just trying to spread FUD.
Live today, because you never know what tomorrow brings
The read-only feature of sftp makes it almost a replacement for anonymous ftp. Too bad it appears to be a global setting.
No X.509 certificates are used. Please study the changes before you comment based on false assumptions. Also, the agent protocol exists for quite a while now, it is not new.
I am reading this article and posting to it through a ssh tunnel using OpenSSH on a Gentoo Linux server at home and putty.exe on a work laptop running XP Pro at work.
Firefox sees it as a SOCKS 5 proxy at localhost. The tricky part was setting the config key in Firefox called "network.proxy.socks_remote_dns" to true. (Navigate to about:config and filter for "proxy" to find this setting quickly). The corporate network admins use bogus DNS resolution as a firewall.
I love you, OpenSSH devs. I sincerely thank you.
A brief quote from the project's home page:
Please take note of our Who uses it page, which list just some of the vendors who incorporate OpenSSH into their own products -- as a critically important security / access feature -- instead of writing their own SSH implementation or purchasing one from another vendor. This list specifically includes companies like Cisco, Juniper, Apple, Red Hat, and Novell; but probably includes almost all router, switch or unix-like operating system vendors. In the 10 years since the inception of the OpenSSH project, these companies have contributed not even a dime of thanks in support of the OpenSSH project (despite numerous requests).
So go and DONATE, as i've just done.
OpenSSH is nothing short of magic. I too use it to tunnel out of work's firewall.
Now, Debian Dev. DON'T TOUCH. :)
that is brief!
FTP is a fucking mess, I hate it, I wish I could kill it today everywhere. It is a disaster to manage with a firewall. The horrendous idea of using separate random ports for data connection vs control connections, the active/passive methods, it's is pure evil.
At the time of its invention FTP's design made sense.
TCP allows bi-directional traffic on a port, but TCP was not invented when FTP was first created (1971). The protocol that was around only allowed one-way transmission of data on any connection. So when you FTPed into a machine, and server had to open a connection back to the client to return any data.
Also remember that firewalls were also not invented until the late '80s (earlier '90s?), so the blocking of connections back to the client weren't an issue. It was only later on (mid-'90s) where the combination of active/passive modes and security lock downs became a headache.
By that time there was a large amount of inertial behind FTP--and remember that HTTP was mostly still young in the '90s as well, and the read/write web wasn't that all that popular (and even things like WebDAV isn't used a lot even now).
So while I fell your pain (I'm a sys admin), there aren't / weren't that many alternatives.
A brief quote from the project's home page:
Please take note of our Who uses it page, which list just some of the vendors who incorporate OpenSSH into their own products -- as a critically important security / access feature -- instead of writing their own SSH implementation or purchasing one from another vendor. This list specifically includes companies like Cisco, Juniper, Apple, Red Hat, and Novell; but probably includes almost all router, switch or unix-like operating system vendors. In the 10 years since the inception of the OpenSSH project, these companies have contributed not even a dime of thanks in support of the OpenSSH project (despite numerous requests).
So go and DONATE, as i've just done.
Okay, we get it Theo.
In the 10 years since the inception of the OpenSSH project, these companies have contributed not even a dime of thanks in support of the OpenSSH project (despite numerous requests).
And they don't have to, either morally or legally.
OpenSSH is released under the BSD license, and the devs know full well that they may not be financially rewarded for their work. To suddenly expect those users to donate cash just because they use the very code you freed is, to say, the least, hypocritical. After all, if you wanted to be paid for the work you do, why are you releasing it for free to the world under one of the most liberal software licenses possible? Why not a dual license that requires payment for commercial use? Naturally because the BSDs are all about freedom, of course.
Well, unless they think they're getting screwed financially.
"And they don't have to, either morally or legally."
Legally, no. But morally? Well, I beg to differ: those companies generate millions of dollars a year and would be in a completely different situation right now if they didn't have OpenSSH to benefit from. As such I see it as rather greedy and selfish not to donate anything at all.
But alas, this only proves that people have different views of what is morally or ethically acceptable: what I find morally questionable you find completely acceptable, and the same thing would probably work also vice versa on some other topic.
The OpenSSH developers do not trust any X.509 code. The actual X.509 validation and trust decision mechanisms are pretty horiffic, and I'm glad they stayed away from that. You don't have to throw away your X.509 certs, you can keep using them for other purposes.