Contributed by merdely on from the sshazam dept.
Damien Miller (djm@) just announced the release of OpenSSH 4.7:
OpenSSH 4.7 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.
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.6: ============================ Security bugs resolved in this release: * Prevent ssh(1) from using a trusted X11 cookie if creation of an untrusted cookie fails; found and fixed by Jan Pechanec. Other changes, new functionality and fixes in this release: * sshd(8) in new installations defaults to SSH Protocol 2 only. Existing installations are unchanged. * The SSH channel window size has been increased, and both ssh(1) sshd(8) now send window updates more aggressively. These improves performance on high-BDP (Bandwidth Delay Product) networks. * ssh(1) and sshd(8) now preserve MAC contexts between packets, which saves 2 hash calls per packet and results in 12-16% speedup for arcfour256/hmac-md5. * A new MAC algorithm has been added, UMAC-64 (RFC4418) as "umac-64@openssh.com". UMAC-64 has been measured to be approximately 20% faster than HMAC-MD5. * A -K flag was added to ssh(1) to set GSSAPIAuthentication=Yes * Failure to establish a ssh(1) TunnelForward is now treated as a fatal error when the ExitOnForwardFailure option is set. * ssh(1) returns a sensible exit status if the control master goes away without passing the full exit status. (bz #1261) * The following bugs have been fixed in this release: - When using a ProxyCommand in ssh(1), set the outgoing hostname with gethostname(2), allowing hostbased authentication to work (bz #616) - Make scp(1) skip FIFOs rather than hanging (bz #856) - Encode non-printing characters in scp(1) filenames. these could cause copies to be aborted with a "protocol error" (bz #891) - Handle SIGINT in sshd(8) privilege separation child process to ensure that wtmp and lastlog records are correctly updated (bz #1196) - Report GSSAPI mechanism in errors, for libraries that support multiple mechanisms (bz #1220) - Improve documentation for ssh-add(1)'s -d option (bz #1224) - Rearrange and tidy GSSAPI code, removing server-only code being linked into the client. (bz #1225) - Delay execution of ssh(1)'s LocalCommand until after all forwadings have been established. (bz #1232) - In scp(1), do not truncate non-regular files (bz #1236) - Improve exit message from ControlMaster clients. (bz #1262) - Prevent sftp-server(8) from reading until it runs out of buffer space, whereupon it would exit with a fatal error. (bz #1286) * Portable OpenSSH bugs fixed: - Fix multiple inclusion of paths.h on AIX 5.1 systems. (bz #1243) - Implement getpeereid for Solaris using getpeerucred. Solaris systems will now refuse ssh-agent(1) and ssh(1) ControlMaster clients from different, non-root users (bz #1287) - Fix compilation warnings by including string.h if found. (bz #1294) - Remove redefinition of _res in getrrsetbyname.c for platforms that already define it. (bz #1299) - Fix spurious "chan_read_failed for istate 3" errors from sshd(8), a side-effect of the "hang on exit" fix introduced in 4.6p1. (bz #1306) - pam_end() was not being called if authentication failed (bz #1322) - Fix SELinux support when SELinux is in permissive mode. Previously sshd(8) was treating SELinux errors as always fatal. (bz #1325) - Ensure that pam_setcred(..., PAM_ESTABLISH_CRED) is called before pam_setcred(..., PAM_REINITIALIZE_CRED), fixing pam_dhkeys. (bz #1339) - Fix privilege separation on QNX - pre-auth only, this platform does not support file descriptior passing needed for post-auth privilege separation. (bz #1343) Thanks to everyone who has contributed patches, reported bugs and tested releases. Checksums: ========== - SHA1 (openssh-4.7.tar.gz) = 9ebaab9b31e01bd0d04425dc23536bcc78f8d990 - SHA1 (openssh-4.7p1.tar.gz) = 58357db9e64ba6382bef3d73d1d386fcdc0508f4 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.
(Comments are closed)
By Anonymous (202.54.26.120) blah@nospamme.nodomain on
Comments
By Anonymous Coward (128.171.90.200) on
I use -current ;)
By Anonymous Coward (194.245.32.131) on
By Cabal (Cabal) Cabal on http://www.enginuity.org/
Existing installations are unchanged.
That's great to see, it's been due for a while. Perhaps PermitRootLogin will be next.
Comments
By Ray Percival (sng) on http://undeadly.org/cgi?action=search&sort=time&query=sng
> Existing installations are unchanged.
> That's great to see, it's been due for a while. Perhaps PermitRootLogin will be next.
Naw. I change PermitRootLogin the first thing after a new install. But making it the default state violated the principle of least surprise. Which is a bad thing.
Comments
By Terrell Prude' Jr. (151.188.247.104) tprude@cmosnetworks.com (this is a spamtrap address) on http://www.cmosnetworks.com/
That's also the first thing that I do. Probably should've been the default back in the day, but of course that's hindsight now.
That said, wasn't spamd's greylisting turned on by default in OpenBSD 4.1, when it wasn't in 4.0? Wouldn't that be a "least surprise" issue as well, thus possibly justifying a new PermitRootLogin default for new installs only?
--TP
Comments
By Ray Percival (sng) on http://undeadly.org/cgi?action=search&sort=time&query=sng
>
> That's also the first thing that I do. Probably should've been the default back in the day, but of course that's hindsight now.
>
> That said, wasn't spamd's greylisting turned on by default in OpenBSD 4.1, when it wasn't in 4.0? Wouldn't that be a "least surprise" issue as well, thus possibly justifying a new PermitRootLogin default for new installs only?
>
> --TP
$ grep spam /etc/rc.conf
spamd_flags=NO # for normal use: "" and see spamd-setup(8)
spamd_grey=NO # use spamd greylisting if YES
spamlogd_flags="" # use eg. "-i interface" and see spamlogd(8)
$ grep spam /etc/rc.conf
spamd_flags=NO # for normal use: "" and see spamd-setup(8)
spamd_black=NO # set to YES to run spamd without greylisting
spamlogd_flags="" # use eg. "-i interface" and see spamlogd(8)
Yeah, they are different.
As to PermitRootLogin. I agree that, in most cases, it should be changed. But if it's not the default to allow it you then, on a fresh box, have a login method that no users on the box can use. This can be ... confusing. (OK. I'm overstating the facts a bit there. But the point being you would expect to be able to use a login method with all your users unless you've told it not to allow it.)
I see those as two different cases. The same reason passwords are turned on by default. I think both should be turned off. But at the same time I think it's the job of the admin to make that choice and the system should, by default, allow him to decide.
Comments
By Anonymous Coward (74.115.21.120) on
How about just letting us add users during the install so there's no need for root logins to be enabled initially.
Comments
By Ray Percival (sng) on http://undeadly.org/cgi?action=search&sort=time&query=sng
>
> How about just letting us add users during the install so there's no need for root logins to be enabled initially.
Doesn't change the point that a login method that a given user can't use by default violates the principle of least surprise.
Comments
By Anonymous Coward (193.108.162.1) on
By Terrell Prude' Jr. (151.188.247.104) tprude@cmosnetworks.com (this is a spamtrap address) on
>
> Doesn't change the point that a login method that a given user can't use by default violates the principle of least surprise.
Hmm...but if we can add users during the install, which of course would include adding them into wheel as appropriate, wouldn't this solve that principle?
--TP
By Anonymous Coward (83.5.224.194) on
By Anonymous Coward (82.75.29.106) on
After that I set up Allowusers and set UseDNS to no.
By Anonymous Coward (213.251.73.98) on
> Existing installations are unchanged.
> That's great to see, it's been due for a while. Perhaps PermitRootLogin will be next.
Or maybe like this:
Start sshd(8) by default? [yes]
Allow ssh root logins? [no]
Comments
By Terrell Prude' Jr. (151.188.247.104) tprude@cmosnetworks.com (this is a spamtrap address) on http://www.cmosnetworks.com/
> > Existing installations are unchanged.
> > That's great to see, it's been due for a while. Perhaps PermitRootLogin will be next.
>
> Or maybe like this:
>
> Start sshd(8) by default? [yes]
> Allow ssh root logins? [no]
Good idea. As someone else pointed out, we'd also need to be able to add at least one general user, and put that user in the wheel group. A call to adduser (at least, on OpenBSD) should solve that, yes? Most GNU/Linux distros and non-*BSD UNIX platforms (to my knowledge) don't have the concept of a wheel group, so the portable version wouldn't generally need to account for that. Notable exception: Trustix.
--TP
Comments
By Anonymous Coward (219.90.211.166) on
If people really want to do this sort of thing they can play with it from the shell after the install, or do something about it after booting.
By RC (24.37.242.64) on
> Existing installations are unchanged.
> That's great to see, it's been due for a while. Perhaps PermitRootLogin will be next.
I agree with you too, but like one posting below somewhere, I think it would be best to give the option to set the option to permit or deny during install.
I guess the only advantage to this is that if you remotely install (or what not) and forget to create a user account to ssh into and forget to set up sudo or add the user to the wheel group, then you're not locked out of your own system 'by default'.
What I'd personally like to see (off topic) is the option to install via tftp, added to all the other options, instead of just pxe+tftp+ftp, http, nfs, etc.
Comments
By Anonymous Coward (24.37.242.64) on
> > Existing installations are unchanged.
> > That's great to see, it's been due for a while. Perhaps PermitRootLogin will be next.
>
> I agree with you too, but like one posting below somewhere, I think it would be best to give the option to set the option to permit or deny during install.
>
> I guess the only advantage to this is that if you remotely install (or what not) and forget to create a user account to ssh into and forget to set up sudo or add the user to the wheel group, then you're not locked out of your own system 'by default'.
>
> What I'd personally like to see (off topic) is the option to install via tftp, added to all the other options, instead of just pxe+tftp+ftp, http, nfs, etc.
s/below/above/
Wish I could re-edit my comment...
By Terrell Prude' Jr. (151.188.247.104) tprude@cmosnetworks.com (this is a spamtrap address) on http://www.cmosnetworks.com/
> I agree with you too, but like one posting below somewhere, I think it would be best to give the option to set the option to permit or deny during install.
>
That's a good idea, and it would sure get my vote.
> I guess the only advantage to this is that if you remotely install (or what not) and forget to create a user account to ssh into and forget to set up sudo or add the user to the wheel group, then you're not locked out of your own system 'by default'.
If you're remotely installing, then during the actual install, you still have to have access to the console somehow, don't you, even if it's serial port access? If that's true, then is getting locked out of the box still an issue?
--TP
Comments
By Anonymous Coward (74.59.88.115) on
> > I think it would be best to give the option to set the
> > option to permit or deny during install.
>
> That's a good idea, and it would sure get my vote.
I agree with the person above who appreciates the
simplicity, and lack of "Do you ...?" in the install.
In any case, we all do have the option to do this
(and add a user, etc.) during the install. Well,
almost. Just drop into a shell at the end of the
install and do (pretty much) whatever you want (or
do it in siteXX.tgz). I have always been pleased
and impressed to see that the developers have not
heeded various requests over the years to do this or
that with the install. It is ideal in that it's a
geodesic to the ultimate install script: a complete,
solid base OS.
By freakman (84.167.98.122) on
# ssh -version
I get the error message:
OpenSSH_4.7, OpenSSL 0.9.7j 04 May 2006
Bad escape character 'rsion'.
Comments
By freakman (84.167.98.122) on
Comments
By freakman (84.167.98.122) on
;-))
By tedu (38.99.3.113) on
>
> # ssh -version
>
> I get the error message:
>
> OpenSSH_4.7, OpenSSL 0.9.7j 04 May 2006
> Bad escape character 'rsion'.
and what were you expecting? rsion is not a valid escape character.
By m (195.212.29.171) on
But I have a question specific to OpenBSD.
Will be this new version of OpenSSH included in patch branch?
Thanks a lot