OpenBSD Journal

OpenSSH 4.0 released!

Contributed by grey on from the be sure to buy one of the newT-shirts to support the project! dept.

OpenSSH 4.0 has just been released! Read on for the complete announcement.

List:       openssh-unix-dev
Subject:    OpenSSH 4.0 released
From:       Damien Miller 
Date:       2005-03-09 9:54:13
Message-ID: <200503090954.j299sDng029163 () cvs ! openbsd ! org>

OpenSSH 4.0 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 would like to thank the OpenSSH community for their continued
support to the project, especially those who contributed source and
bought T-shirts or posters.

We have a new design of T-shirt available, more info on
        http://www.openbsd.org/tshirts.html#18

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 3.9:
============================ 

* ssh(1) now allows the optional specification of an address to bind to 
  in port forwarding connections (local, remote and dynamic). Please 
  refer to the documentation for the -L and -R options in the ssh(1) 
  manual page and the LocalForward and RemoteForward options in the 
  ssh_config(5) manpage. (Bugzilla #413)

* To control remote bindings while retaining backwards compatibility,
  sshd(8)'s GatewayPorts option has been extended. To allow client
  specified bind addresses for remote (-R) port forwardings, the server
  must be configured with "GatewayPorts clientspecified".

* ssh(1) and ssh-keyscan(1) now support hashing of host names and 
  addresses added to known_hosts files, controlled by the ssh(1) 
  HashKnownHosts configuration directive. This option improves user 
  privacy by hiding which hosts have been visited. At present this 
  option is off by default, but may be turned on once it receives 
  sufficient testing.

* Added options for managing keys in known_hosts files to ssh-keygen(1),
  including the ability to search for hosts by name, delete hosts by
  name and convert an unhashed known_hosts file into one with hashed
  names. These are particularly useful for managing known_hosts files
  with hashed hostnames.

* Improve account and password expiry support in sshd(8). Ther server 
  will now warn in advance for both account and password expiry.

* sshd(8) will now log the source of connections denied by AllowUsers,
  DenyUsers, AllowGroups and DenyGroups (Bugzilla #909)

* Added AddressFamily option to sshd(8) to allow global control over
  IPv4/IPv6 usage. (Bugzilla #989)

* Improved sftp(1) client, including bugfixes and optimisations for the 
  ``ls'' command and command history and editing support using libedit.

* Improved the handling of bad data in authorized_keys files,
  eliminating fatal errors on corrupt or very large keys. (Bugzilla
  #884)

* Improved connection multiplexing support in ssh(1). Several bugs 
  have been fixed and a new "command mode" has been added to allow the
  control of a running multiplexing master connection, including 
  checking that it is up, determining its PID and asking it to exit.

* Have scp(1) and sftp(1) wait for the spawned ssh to exit before they
  exit themselves.  This prevents ssh from being unable to restore 
  terminal modes (not normally a problem on OpenBSD but common with 
  -Portable on POSIX platforms). (Bugzilla #950)

* Portable OpenSSH:

  - Add *EXPERIMENTAL* BSM audit support for Solaris systems 
    (Bugzilla #125)

  - Enable IPv6 on AIX where possible (see README.platform for
    details), working around a misfeature of AIX's getnameinfo. 
    (Bugzilla #835)

  - Teach sshd(8) to write failed login records to btmp for
    unsuccessful auth attempts. Currently this is only for password,
    keyboard-interactive and challenge/response authentication methods
    and only on Linux and HP-UX.

  - sshd(8) now sends output from failing PAM session modules to the 
    user before exiting, similar to the way /etc/nologin is handled

  - Store credentials from gssapi-with-mic authentication early enough
    to be available to PAM session modules when privsep=yes.

Checksums:
==========

- MD5 (openssh-4.0.tgz) = 7dbf15fe7c294672e8822127f50107d0
- MD5 (openssh-4.0p1.tar.gz) = 122bec49d2cace00b71cc29b5ececed3

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, Ben Lindstrom, Darren Tucker and Tim Rice.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

(Comments are closed)


Comments
  1. By Nate (65.95.240.35) on

    I like the styling new Agent Puff on the main page there.

  2. By djm@ (203.217.30.86) on

    BTW, I botched the MD5 sum for the portable tarball in the release announcement. The correct one is:

    MD5 (openssh-4.0p1.tar.gz) = 7b36f28fc16e1b7f4ba3c1dca191ac92

    ...or just the the PGP signature, it is correct.

    Comments
    1. By grey (207.215.223.2) on

      IANACBIMPOOF (I am not a cryptographer, but I may play one on fora)

      http://cryptography.hyperlink.cz/md5/MD5_collisions.pdf is worth taking a look at. I realize it's recent (March 5th), but gives an example of finding a full md5 collision in 8 hours on a notebook, and they're predicting that time will go down once Wang et al release their actual speed up method (perhaps the prediction of 2 minutes is overstating it, but you never know). That said, getting a collision on meaningful substitutes (e.g. a backdoored OpenSSH) might be another challenge, but I doubt it's going to be too much harder if speed keeps increasing.

      At any rate, I was wondering - why have just one CRC in the release notes? Why not also provide a sha-1 CRC, or even several different CRC types? As we witness more hashes fall victim to improved collision attacks (there will _always_ be collisions anyways because it's a frigging hash), it's understandable that any individual (md5, sha-1, crc32, whatever) hash will have possible meaningful collisions. However, finding a meaningful collision for -several- different CRC's simultaneously, I would posit is probably very unlikely.

      Maybe I'm wrong about that in some cases, as I know sha-1 is based off of previous work from md5. But regardless, it wouldn't be hard to check, just take an example of a two different files wherein they both have the same md5, and then see if they both have the same sha-1 (or crc32, or ripe-md or whatever-the-hell-CRC you want to have as well). Does anyone have two files that have an md5 collision I could test against?

      Also, it should be noted (and Jose thankfully reminded me of this at RSAConf when we were discussing hashes briefly) that the OpenBSD ports system already checks several different hashes on distfiles. Just check a /usr/ports/blah/blah/distinfo yourself and you'll see something like this:

      $ more distinfo
      MD5 (nmap-3.81.tgz) = 9b32f74e2f6999e4f7668a24f2a1ea85
      RMD160 (nmap-3.81.tgz) = d57533f1bf614541dd0cdfcf0f14b257d26a28c9
      SHA1 (nmap-3.81.tgz) = 9d1ce1ab3e097ce5d61078fd4bc713f9b701fa1c
      SIZE (nmap-3.81.tgz) = 1846196

      So, since we do it in the ports system already, maybe we should look to add it in our release notes as well?

      Comments
      1. By grey (207.215.223.2) on

        Jolan corrects me in that even though distinfo contains several different hashes, it only checks against one. I've also formalized this a little bit on a posting to advogato here. Adding corrections and suggestions for anyone curious. I'll clean it up more time allowing.

        Oh, and if anyone wants to improve the ports system to check all the hashes provided in distinfo, keep in mind that generally reading from disk is the biggest bottleneck in computing hashes, so if the disk could be read once, but several hashes computed simultaneously, that would be bitchin'.

        Comments
        1. By mirabile (213.196.227.95) on http://mirbsd.org/

          NetBSD(tm)s pkgsrc has recently gained support for multiple
          checksums (though I don't know if they check all), and
          MirPorts check all available checksums for quite some time
          now, shortly after the SHA-1 break announcement.

          They both run on OpenBSD as a replacement (possibly also in
          parallel) to the OpenBSD Ports Tree.

          Oh, and I'm sure you can pull out the diff and apply it
          to OpenBSD's bsd.port.mk as well.

  3. By Nikademus (212.88.244.240) on http://www.octools.com

    New T-shirt?? http://www.openbsd.org/tshirts.html#18???

    I already have it for quite a while.. :)

    Comments
    1. By Anonymous Coward (195.217.242.33) on

      Yup I feel a new new t-shirt is what is called for

  4. By Anthony (68.145.112.234) on

    I like that. It's a good thing management tools have been updated, otherwise we'd be in trouble... the keys get changed on sites I use far more than I would like even though my own machines are kept consistent. Will OpenBSD-STABLE be updated with this version?

    Comments
    1. By Brad (204.101.180.70) brad at comstyle dot com on

      From stable.html... - As an exception to the above rules, OpenSSH release versions will be merged into the patch branch.

  5. By Anonymous Coward (65.198.20.164) on

    * Improved sftp(1) client, including bugfixes and optimisations for the ``ls'' command and command history and editing support using libedit

    Out of everything, those are two of the features I'd been hoping for. I also wish there was tab completion in sftp.

    Comments
    1. By Ben (208.27.203.127) mouring@nospam.eviladmin.org on

      I'm sure it will come. I passed my work with readline version off to someone in the community that was interested in tab completion. Also stated they really should look at OpenBSD's ftp client.

      Maybe if no one gets to it by next year I'll step up and rewrite my stuff to use libedit.

      But not this year... Too much stuff I'm trying to work on. *SIGH*

      - Ben

      Comments
      1. By Anonymous Coward (24.127.0.74) on

        If I knew how, I'd do it. =D

        Comments
        1. By Ben (208.27.203.127) mouring@nospam.eviladmin.org on

          The libedit completion example is here: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ftp/complete.c

          and the only thing left is finding the glue to let el_gets() know to call it (which escapes me at this moment in history).

          No real magic here. =-) Just detective work and playing.. ermm.. I mean coding.

          I'd point you to the readline example, but it has ran off along with all the rest of my OpenSSH development since I'm not active anymore.

          - Ben

          Comments
          1. By Ben (208.27.203.127) mouring@nospam.eviladmin.org on

            BTW.. if you are looking for the "glue" it is here: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ftp/util.c

            In function "void controlediting(void)"

            So it is cake.=-) Any two bit code monkey can do it.

            - Ben

    2. By xhrl (24.80.50.50) on

      definitely agree about those two features, especially tab completion;p

  6. By oksala (66.130.12.114) ok@ok.com on

    The ability to secify the address to bind to in port forwarding connections is indeed very useful. Many thanks...

  7. By Anonymous Coward (24.34.57.27) on

    I have OpenSSH 4.0p1 running on a variety of OSes, all built against OpenSSL 0.9.7e, and one of the clients is giving me a problem. They're all built with a standard ./configure and no other options, and just X11 forwarding in the ssh_config file. Whenever I connect to a system with this one, regardless of the SSH server version running, after I put in a password, it pauses for a full 5 seconds every time with the following (from ssh -vv):

    debug2: x11_get_proto: /usr/X11R6/bin/xauth -f /tmp/ssh-PZhTm22307/xauthfile generate unix:10.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 2>/dev/null
    (pause 5+ seconds here)
    debug2: x11_get_proto: /usr/X11R6/bin/xauth list unix:10.0 . 2>/dev/null

    Every other client flies through these lines with no delay on any number of servers. The problem child is Mandrake 10.1, whereas the working clients are Mandrake 9.2, FreeBSD 4.9, and FreeBSD 4.10. Any ideas?

    Comments
    1. By Anonymous Coward (24.34.57.27) on

      Addendum: my initial troubleshooting was a bit off. This doesn't happen on any system that I'm logged in to locally and initiate a connection, but if I jump from one machine to another with X11 forwarding turned on, the second machine is always doing this 5-second pause. This is most easily reproducible if I SSH to localhost twice in a row (one connection within another).

    2. By benjamin s. (212.236.10.2) on

      Hi!

      Is it possible, that openssh is simply trying to do a dns-lookup on the ip-address and failing to do so at least implies a certain timeout while doing the dnslookup?

      Comments
      1. By Anonymous Coward (24.34.57.27) on

        Nah, it happens with UseDNS off (though I normally keep it on and have all forward and reverse lookups correctly defined). It only happens on that second login jump, the first one is fine. Thanks, though.

  8. By Anonymous Coward (81.220.245.98) on

    Greetings to all of you people, May I ask why sftp logging and chroot jail are not yet implemented in openssh, would it be because of some security issues? I personally think jailing sftp users as an important security thing, because I do not like to see people going in /etc for example. Even if access rights should be strictly defined in any well maintained operating system, this seems to be a bit hazardous...

    Comments
    1. By RC (4.8.16.53) on

      > May I ask why sftp logging and chroot jail are not yet
      > implemented in openssh

      It wouldn't make much sense, would it? To use SFTP, you have to have SSH support, so you can always read/transfer those files without using scp/sftp.

      > I personally think jailing sftp users as an important security
      > thing, because I do not like to see people going in /etc for example.

      No, it's really because you don't particularly understand security.

      Comments
      1. By Anonymous Coward (84.96.24.154) on

        > No, it's really because you don't particularly understand security.

        Thank you for your reply. Maybe I should have precised that my point of view is to use sftp as a complete replacement solution for the old traditional ftp (jailing ssh sessions in usual situations really has no sense, you're right). So, what I mean about jailing is just to avoid people going where they do not need to in order to transfer files.

        So do you mean that openssh is not particularly designed for file transfer which is just a useful extension, and that a better solution for encrypted file transfer would be ftp over ssl for example?

        Comments
        1. By RC (4.8.16.53) on

          > So do you mean that openssh is not particularly designed for file
          > transfer which is just a useful extension, and that a better solution
          > for encrypted file transfer would be ftp over ssl for example?

          No, SSH does a pretty good job with file-transfers. It sounds to me that you haven't progressed very far in your efforts to set-up an ssh server as a file-transfer-only service. This a complicated issue, that I can't just explain to you in a few sentences.

          Comments
          1. By Anonymous Coward (81.220.245.98) on

            > No, SSH does a pretty good job with file-transfers. It sounds to me that
            > you haven't progressed very far in your efforts to set-up an ssh server
            > as a file-transfer-only service. This a complicated issue, that I can't
            > just explain to you in a few sentences.

            Okay, thanks, after having read various stuff on the openssh-dev mailing list and newsgroups about this subject, I understand you have good reasons not to integrate chrooting in the ssh daemon.

            Maybe you think about tunneling ftp into ssh. I wonder anyway if there are click'n'play solutions for windows users on the other side.

            What would you think about making rssh compilable on bsd (it seems that it is only running on linux for now) and including it as a port, so that complaining people can get satisfied?

            Comments
            1. By RC (4.8.16.53) on

              > Maybe you think about tunneling ftp into ssh. I wonder anyway if there
              > are click'n'play solutions for windows users on the other side.

              One of FTP's stupid limitations, is that it uses 2 different ports (read up on active/passive modes). It is technically possible to forward the control connection over SSH, which would protect your password, but not the file data itself. Even doing the former is a VERY complicated process, that won't work in many cases, due to nat/firewalls.

              > What would you think about making rssh compilable on bsd

              rssh is no longer being developed, and has some obvious and gaping security holes. You could at least go with 'scponly'. However, even with that, you should never consider it secure.

              SSH is designed for interactive use, not file transfers, and hacks to get it to work that way have been worked-around many times, and more work-arounds are sure to appear in the future. If you generally trust your users in the first place, scponly may be good enough (with proper permissions on directories). If you're providing file-transfer service to untrusted or anonymous users, you really should find something made with that purpose in-mind, as it is sure to keep your system more secure.

              Comments
              1. By Anonymous Coward (216.27.182.22) on

                eh?

                http://www.pizzashack.org/rssh/index.shtml

                Last update was Dec. 30, 2004.

              2. By 9 (209.73.236.253) on

                Sorry, I just stumbled on this thread while having the same question, and I'd like to comment:

                If you generally trust your users in the first place, scponly may be good enough (with proper permissions on directories). If you're providing file-transfer service to untrusted or anonymous users, you really should find something made with that purpose in-mind, as it is sure to keep your system more secure.

                This comment, however true it may be, isn't very helpful. Someone is clearly looking for a secure alternative to FTP which wouldn't allow users to browse the entire file system. Why bother responding just to say, "You're obviously ignorant as to how this should work. I would tell you what to do, but don't feel like it."?

                Comments
                1. By 9 (66.237.197.226) on

                  Oh, and I forgot to comment on why I quoted what I did. What about those of us who want neither to provide anonymous/insecure access nor to trust our users?

      2. By Anonymous Coward (82.69.212.38) on

        > It wouldn't make much sense, would it? To use SFTP, you have to have SSH > support, so you can always read/transfer those files without using > scp/sftp. Uh, no. It's easy to make it so that SFTP works without granting access to SSH. I think you oughtn't to go around telling people they are naive w.r.t to security if you don't know that much yourself.

        Comments
        1. By Anonymous Coward? (68.94.11.184) simongales@hotmail.com on

          If the users' shell is set to the sftp-server executable, and you incorporate the chroot patch into the sftp-server executable, what security concerns are there? Assume that port/X11-forwarding is disabled.... ???

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