OpenSSH 4.3 released
From: | Damien Miller <djm-AT-cvs.openbsd.org> | |
To: | lwn-AT-lwn.net | |
Subject: | Announce: OpenSSH 4.3 released | |
Date: | Wed, 1 Feb 2006 05:30:32 -0700 (MST) |
OpenSSH 4.3 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We have also recently completed another Internet SSH usage scan, the results of which may be found at http://www.openssh.com/usage.html Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots and purchased T-shirts or posters. T-shirt, poster and CD sales directly support the project. Pictures and more information can be found at: http://www.openbsd.org/tshirts.html and http://www.openbsd.org/orders.html For international orders use http://https.openbsd.org/cgi-bin/order and for European orders, use http://https.openbsd.org/cgi-bin/order.eu Changes since OpenSSH 4.2: ============================ Security bugs resolved in this release: * CVE-2006-0225: scp (as does rcp, on which it is based) invoked a subshell to perform local to local, and remote to remote copy operations. This subshell exposed filenames to shell expansion twice; allowing a local attacker to create filenames containing shell metacharacters that, if matched by a wildcard, could lead to execution of attacker-specified commands with the privilege of the user running scp (Bugzilla #1094) This is primarily a bug-fix release, only one new feature has been added: * Add support for tunneling arbitrary network packets over a connection between an OpenSSH client and server via tun(4) virtual network interfaces. This allows the use of OpenSSH (4.3+) to create a true VPN between the client and server providing real network connectivity at layer 2 or 3. This feature is experimental and is currently supported on OpenBSD, Linux, NetBSD (IPv4 only) and FreeBSD. Other operating systems with tun/tap interface capability may be added in future portable OpenSSH releases. Please refer to the README.tun file in the source distribution for further details and usage examples. Some of the other bugs resolved and internal improvements are: * Reduce default key length for new DSA keys generated by ssh-keygen back to 1024 bits. DSA is not specified for longer lengths and does not fully benefit from simply making keys longer. As per FIPS 186-2 Change Notice 1, ssh-keygen will refuse to generate a new DSA key smaller or larger than 1024 bits * Fixed X forwarding failing to start when a the X11 client is executed in background at the time of session exit (Bugzilla #1086) * Change ssh-keygen to generate a protocol 2 RSA key when invoked without arguments (Bugzilla #1064) * Fix timing variance for valid vs. invalid accounts when attempting Kerberos authentication (Bugzilla #975) * Ensure that ssh always returns code 255 on internal error (Bugzilla #1137) * Cleanup wtmp files on SIGTERM when not using privsep (Bugzilla #1029) * Set SO_REUSEADDR on X11 listeners to avoid problems caused by lingering sockets from previous session (X11 applications can sometimes not connect to 127.0.0.1:60xx) (Bugzilla #1076) * Ensure that fds 0, 1 and 2 are always attached in all programs, by duping /dev/null to them if necessary. * Xauth list invocation had bogus "." argument (Bugzilla #1082) * Remove internal assumptions on key exchange hash algorithm and output length, preparing OpenSSH for KEX methods with alternate hashes. * Ignore junk sent by a server before it sends the "SSH-" banner (Bugzilla #1067) * The manpages has been significantly improves and rearranged, in addition to other specific manpage fixes: #1037 - Man page entries for -L and -R should mention -g. #1077 - Descriptions for "ssh -D" and DynamicForward should mention they can specify "bind_address" optionally. #1088 - Incorrect descriptions in ssh_config man page for ControlMaster=no. #1121 - Several corrections for ssh_agent manpages * Lots of cleanups, including fixes to memory leaks on error paths (Bugzilla #1109, #1110, #1111 and more) and possible crashes (#1092) * Portable OpenSSH-specific fixes: - Pass random seed during re-exec for each connection: speeds up processing of new connections on platforms using the OpenSSH's builtin entropy collector (ssh-rand-helper) - PAM fixes and improvements: #1045 - Missing option for ignoring the /etc/nologin file #1087 - Show PAM password expiry message from LDAP on login #1028 - Forward final non-query conversations to client #1126 - Prevent user from being forced to change an expired password repeatedly on AIX in some PAM configurations. #1045 - Do not check /etc/nologin when PAM is enabled, instead allow PAM to handle it. Note that on platforms using PAM, the pam_nologin module should be used in sshd's session stack in order to maintain past behaviour - Portability-related fixes: #989 - Fix multiplexing regress test on Solaris #1097 - Cross-compile fixes. #1096 - ssh-keygen broken on HPUX. #1098 - $MAIL being set incorrectly for HPUX server login. #1104 - Compile error on Tru64 Unix 4.0f #1106 - Updated .spec file and startup for SuSE. #1122 - Use _GNU_SOURCE define in favor of __USE_GNU, fixing compilation problems on glibc 2.4 Thanks to everyone who has contributed patches, reported bugs or test releases. Checksums: ========== - SHA1 (openssh-4.3.tar.gz) = 0cb66e56805d66b51511455423bab88aa58a1455 - SHA1 (openssh-4.3p1.tar.gz) = b1f379127829e7e820955b2825130edd1601ba59 Reporting Bugs: =============== - please read http://www.openssh.com/report.html and http://bugzilla.mindrot.org/ OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom.
Posted Feb 1, 2006 18:10 UTC (Wed)
by JLCdjinn (guest, #1905)
[Link] (7 responses)
Heh; "[t]his is primarily a bug-fix release, only one new feature has
been added: Add support for tunneling arbitrary network packets over a
connection between an OpenSSH client and server via tun(4) virtual network
interfaces". And you thought it was easy to open gaping holes in your
firewall before! "[P]rimarily a bug-fix release", indeed! God bless the OpenSSH
project.
Posted Feb 1, 2006 20:35 UTC (Wed)
by crow (guest, #96)
[Link] (6 responses)
So it isn't really anything new as far as the capabilities, just in ease-of-use.
Posted Feb 1, 2006 21:40 UTC (Wed)
by job (guest, #670)
[Link] (5 responses)
Posted Feb 1, 2006 23:38 UTC (Wed)
by Mithrandir (guest, #3031)
[Link] (1 responses)
Posted Feb 2, 2006 0:18 UTC (Thu)
by Ross (guest, #4065)
[Link]
Posted Feb 2, 2006 0:44 UTC (Thu)
by djm (subscriber, #11651)
[Link] (2 responses)
While you wouldn't use it as a permanent connection between two networks or to run real-time applications over, it is very useful for ad-hoc uses (e.g. establishing a secure connection back home while you are travelling) and its convenience. We point people towards IPsec in the documentation for serious uses.
People have been using OpenSSH's TCP-over-TCP port forwarding for years without complaint, just think of this as an incremental improvement :)
Posted Feb 2, 2006 2:32 UTC (Thu)
by dskoll (subscriber, #1630)
[Link]
People have been using OpenSSH's TCP-over-TCP port forwarding for years without complaint
That's not the same thing. Port-forwarding isn't really TCP-over-TCP. It's really just plain TCP. If you use a TCP connection as a piece of wire, and then run TCP over that piece of wire, then the TCP timers in the wire layer and the top layer can interact in very nasty ways, and pretty soon your connection gets totally clogged. You might not notice it on a LAN, but probably will if you try such tunneling over the Internet.
OpenVPN is really a much nicer solution for tunnelling. Works really well, and unlike IPSec, is not a horrible nightmarish protocol produced by committee.
Posted Feb 2, 2006 12:05 UTC (Thu)
by job (guest, #670)
[Link]
In the case of TCP-over-TCP the results are also very practical. As soon as you get packet loss performance will quickly deteriorate. The SSH protocol seems like a competent design so I doubt its port forwarding is broken in that regard.
Please don't misunderstand my previous comment as it was a sincere question. The OpenSSH people probably wouldn't design something as broken as PPP-over-SSH (especially not since OpenVPN is such a simple replacement), so I am interested to hear how it works.
OpenSSH 4.3 released
Yup. This obsoletes the old method of tunneling PPP over SSH.OpenSSH 4.3 released
So it is still TCP-over-TCP? That's something one must avoid. The real OpenSSH 4.3 released
solution is IPsec, or OpenVPN if you really want.
Care to enlighten on why this must be avoided?OpenSSH 4.3 released
Performance issues. TCP handling of lost packets, corrupted packets, and congestion all rely on timing. When you stack TCP on TCP, rather than smoothing over these connection issues, they are magnified.OpenSSH 4.3 released
Saying you "must avoid" it is just a mindless application of dogma. Like most applications, it has appropriate and inappropriate uses.OpenSSH 4.3 released
TCP-over-TCP tunnelling (was OpenSSH 4.3 released)
Not "avoid" as in severe punishment, rather as in "don't do it if you can avoid it". It is a layering violation. All uses are inappropriate, unless you are a researcher doing it on purpose. Much like NAT, something you will regret sooner or later, but sometimes necessary to get the work done. A good rule of thumb is to not break principles unless you really understand them.OpenSSH 4.3 released