OpenSSH 5.4 Released 127
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.'"
SFTP improvements (Score:4, Informative)
* 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....
Some interesting features... (Score:1, Informative)
I'm interested to see how the certificates and netcat features get used in the real world with SSH. I regenerated all of my SSH keys because they are defaulted to AES-128 bit encrypted and the public exponent is changed to 65537.
johnny stoops.
Re:New, Problematic Protocol Introduced (Score:4, Informative)
Thank you Open SSH devs (Score:5, Informative)
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.
Re:Thank you Open SSH devs (Score:3, Informative)
Are you sure they're going through the proxy out of the box? My Firefox had that configuration knob set to "false" by default, and DNS queries are definitely hitting my company's DNS server.
If I tune the knob to true, they go through the proxy.
Both cases verified with tcpdump.
history of FTP (Score:2, Informative)
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.
SFTP and FTPS are different (Score:1, Informative)
SFTP is not FTP over SSH if you did not understand, it is a proper FTP that happens to run over a secured link.
FTP over a secured link is FTPS (FTP over SSL/TLS), which is distinct from SFTP (SSH file transfer protocol).
http://en.wikipedia.org/wiki/Ftps [wikipedia.org]
http://en.wikipedia.org/wiki/SSH_file_transfer_protocol [wikipedia.org]
Performance note:
FTPS can stream files at full TCP speeds, while most SFTP implementations suffer from the SSH and SFTP protocol performance problems caused by having small application-level window and packet sizes (often 32 to 64KB) and requiring a fixed set of packets to be acknowledged before the next bunch is sent.
For details, see section 6.2, "The SSHv2 and SFTP Performance Handbrake" in http://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf [auckland.ac.nz]
and pages 27 to 30 in http://fasterdata.es.net/talks/Tierney-tutorial.pdf [es.net].