OpenBSD Journal

Announce: OpenSSH 4.7 released

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)


Comments
  1. By Anonymous (202.54.26.120) blah@nospamme.nodomain on

    Friggin sweet. Now to wait for my distro to ship this package :D

    Comments
    1. By Anonymous Coward (128.171.90.200) on

      > Friggin sweet. Now to wait for my distro to ship this package :D

      I use -current ;)

  2. By Anonymous Coward (194.245.32.131) on

    great to see that. thank you, developers, and keep up the good work.

  3. By Cabal (Cabal) Cabal on http://www.enginuity.org/

    * sshd(8) in new installations defaults to SSH Protocol 2 only.
    Existing installations are unchanged.


    That's great to see, it's been due for a while. Perhaps PermitRootLogin will be next.

    Comments
    1. By Ray Percival (sng) on http://undeadly.org/cgi?action=search&sort=time&query=sng

      > * sshd(8) in new installations defaults to SSH Protocol 2 only.
      > 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
      1. By Terrell Prude' Jr. (151.188.247.104) tprude@cmosnetworks.com (this is a spamtrap address) on http://www.cmosnetworks.com/

        > 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.

        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
        1. By Ray Percival (sng) on http://undeadly.org/cgi?action=search&sort=time&query=sng

          > 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.
          >
          > 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
          1. By Anonymous Coward (74.115.21.120) on

            > 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.

            How about just letting us add users during the install so there's no need for root logins to be enabled initially.

            Comments
            1. By Ray Percival (sng) on http://undeadly.org/cgi?action=search&sort=time&query=sng

              > > 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.
              >
              > 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
              1. By Anonymous Coward (193.108.162.1) on

                I use OpenBSD many year, but I think what `PermitRootLogin yes' by default is bad idea. But all the same OpenBSD rocks!

              2. By Terrell Prude' Jr. (151.188.247.104) tprude@cmosnetworks.com (this is a spamtrap address) on

                > > 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.

                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

        2. By Anonymous Coward (83.5.224.194) on

          **use proper *passphrases* for root**

        3. By Anonymous Coward (82.75.29.106) on

          > Naw. I change PermitRootLogin the first thing after a new install. But

          After that I set up Allowusers and set UseDNS to no.

    2. By Anonymous Coward (213.251.73.98) on

      > * sshd(8) in new installations defaults to SSH Protocol 2 only.
      > 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
      1. By Terrell Prude' Jr. (151.188.247.104) tprude@cmosnetworks.com (this is a spamtrap address) on http://www.cmosnetworks.com/

        > > * sshd(8) in new installations defaults to SSH Protocol 2 only.
        > > 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
        1. By Anonymous Coward (219.90.211.166) on

          I always liked the simplicity and lack of "do you want X" in OpenBSD's installer. I'd be upset if this started to change.
          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.

    3. By RC (24.37.242.64) on

      > * sshd(8) in new installations defaults to SSH Protocol 2 only.
      > 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
      1. By Anonymous Coward (24.37.242.64) on

        > > * sshd(8) in new installations defaults to SSH Protocol 2 only.
        > > 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...

      2. 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
        1. 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.

  4. By freakman (84.167.98.122) on

    After I call

    # ssh -version

    I get the error message:

    OpenSSH_4.7, OpenSSL 0.9.7j 04 May 2006
    Bad escape character 'rsion'.

    Comments
    1. By freakman (84.167.98.122) on

      I forgot to tell you it's OpenBSD v4.1 i386 with all current security fixes.

      Comments
      1. By freakman (84.167.98.122) on

        And it's STABLE, not CURRENT.

        ;-))

    2. By tedu (38.99.3.113) on

      > After I call
      >
      > # 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.

  5. By m (195.212.29.171) on

    Hello, thanks a lot for your great work

    But I have a question specific to OpenBSD.
    Will be this new version of OpenSSH included in patch branch?

    Thanks a lot

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]