Update to OpenSSH 5.4p1

[Nils Toedtmann]

This is for the Lucid wishlist, i hope it's correct to do it here:

Please upgrade Lucid's OpenSSH package to upstream's 5.4p1. It has some very useful new features, e.g. a minimal certificate format, a netcat mode and setting the umask for sftp-server (am waiting for a long time for the latter).

See https://launchpad.net/openssh/+milestone/5.4p1 and http://www.openssh.com/txt/release-5.4 .

[Colin Watson (cjwatson)]

I'm aware of OpenSSH 5.4p1, but I don't think it's suitable for ramming
past feature freeze; it's quite a big new feature release and I don't
think that these features are essential for Lucid - I'd rather have the
devil we know. I will upgrade to 5.4p1 in Lucid+1.

[Nils Toedtmann (m-launchpad-net-mail-nils-toedtmann-net)]

Colin: understood. But that means that LTS will lack those features for another 2 years :( Particularly the certificate and the umask feature are interesting for server installations.

[Colin Watson (cjwatson)]

I understand your concern, but I would rather that 10.04 LTS lacked
these features than that we introduced them and they were then found to
be broken in some way. There'll be more releases ...

[Matthew Weaver (matt-ice-nine)]

Colin, what can be done to convince folks that inclusion of this OpenSSH release in lucid is the best idea?

The certificate authentication support is most compelling for large institutional installations, the same user base that focuses on LTS releases (and have long upgrade cycles).

Missing it in this release will be costly to those same users.

The fact that OpenSSH included the features in a point release is a compelling argument to the importance of the feature and the quality of implementation.

[Colin Watson (cjwatson)]

On Wed, Mar 17, 2010 at 06:17:25PM -0000, Matthew Weaver wrote:
> Colin, what can be done to convince folks that inclusion of this OpenSSH
> release in lucid is the best idea?
>
> The certificate authentication support is most compelling for large
> institutional installations, the same user base that focuses on LTS
> releases (and have long upgrade cycles).

Thanks for your comments.

I'm excited by this feature too, but as I said, I'm not comfortable with
supporting basically an unknown-quantity .0 release of it for five
years; I'm concerned that it seems the sort of thing that may well
require revision once it sees non-trivial deployment. For example,
https://lists.mindrot.org/pipermail/openssh-unix-dev/2010-February/028325.html
is a mail with some concerns from a GnuPG developer, and in the followup
from an OpenSSH developer it transpires that revocation isn't
implemented yet. Isn't that likely to be pretty critical for a number
of large institutions? I'm not criticising the OpenSSH developers for
this - hey, they did the work and I would be surprised if it weren't
pretty robust as far as it goes - but it's pretty clear that this is an
initial version that will require some extensions.

As for what could be done to convince me - I don't know, release it a
month earlier? :-) Really, this is a time thing more than anything
else. This is exactly the sort of thing that feature freeze is *for*.
The sheer size and newness (in design terms - it's a certification
system designed *from scratch*, albeit by competent cryptographic
implementors but still) of the feature just makes me more reluctant to
override feature freeze for it.

> The fact that OpenSSH included the features in a point release is a
> compelling argument to the importance of the feature and the quality of
> implementation.

No, that doesn't hold given OpenSSH's release history, I'm afraid.
Since 2.0 or so, OpenSSH has just incremented the "minor" number each
time, and bumped the "major" number when the "minor" number would
otherwise have hit 10. There's little if any correlation between the
"minor" number and the character of the release, and 5.4p1 isn't a point
release the way it might be in other projects. In terms of new
features, it's the most significant since at least 5.1, maybe 4.9.
(Note, too, that 5.5p1 is planned soon to address some new issues in
5.4p1.)

Once the dust settles a little, I am prepared to maintain a backport of
a version of OpenSSH with certificate authentication support in a
special archive for Lucid users (or possibly in lucid-backports,
although I don't know which people would tend to trust more; perhaps
both). But I'm afraid I'm not persuaded that this should be *the*
version of OpenSSH in Ubuntu 10.04 LTS. 5.3p1 is pretty solid at this
point and I'm much more comfortable with it.

[Colin Watson (cjwatson)]

On Wed, Mar 17, 2010 at 08:24:19PM -0000, Matthew Weaver wrote:
> ** Changed in: openssh (Ubuntu)
> Assignee: (unassigned) => Colin Watson (cjwatson)

I'm going to leave this as it is since I'll doubtless be doing the work
anyway, but in general it's polite only to assign bugs to people if you
manage them or if you've checked with them first ...

[Matthew Weaver (matt-ice-nine)]

Thanks for the attention, Colin. I can only imagine how busy you are right now.

I'm very happy to hear the commitment to maintain a backport.

Damien Miller has a pretty excellent track record, separate from OpenSSH's overall chain of successes (or lack thereof), but even so I can deeply understand the reluctance given the relative size, complexity, and *newness* of the certificate system. Personally I am convinced that its essential simplicity (compared to other certificate schemes) will prove successful in the long run.

At any rate, thank you, and please accept my apologies for the out-of-protocol bug assignment. That was my bad, I was unsure of the best way to make sure my question came to your attention.

Much appreciated,
weaver

[Matthew Weaver (matt-ice-nine)]

(Sorry for the double-post, just want threads of record like this to be accurate)

Turns out revocation *is* supported, it's clearly in the release notes:
http://www.openssh.com/txt/release-5.4

[Colin Watson (cjwatson)]

Progress update: openssh 1:5.4p1-1 is in Debian unstable now. I'm building an appropriate merge for Ubuntu at the moment, and will run that locally for a while before feeding it to a PPA.

[Launchpad Janitor (janitor)]

This bug was fixed in the package openssh - 1:5.5p1-3ubuntu1

---------------
openssh (1:5.5p1-3ubuntu1) maverick; urgency=low

  * Resynchronise with Debian. Remaining changes:
    - Add support for registering ConsoleKit sessions on login.
    - Drop openssh-blacklist and openssh-blacklist-extra to Suggests; they
      take up a lot of CD space, and I suspect that rolling them out in
      security updates has covered most affected systems now.
    - Convert to Upstart. The init script is still here for the benefit of
      people running sshd in chroots.
    - Install apport hook.
  * Stop setting OOM adjustment in Upstart job; sshd does it itself now.

openssh (1:5.5p1-3) unstable; urgency=low

  * Discard error messages while checking whether rsh, rlogin, and rcp
    alternatives exist (closes: #579285).
  * Drop IDEA key check; I don't think it works properly any more due to
    textual changes in error output, it's only relevant for direct upgrades
    from truly ancient versions, and it breaks upgrades if
    /etc/ssh/ssh_host_key can't be loaded (closes: #579570).

openssh (1:5.5p1-2) unstable; urgency=low

  * Use dh_installinit -n, since our maintainer scripts already handle this
    more carefully (thanks, Julien Cristau).

openssh (1:5.5p1-1) unstable; urgency=low

  * New upstream release:
    - Unbreak sshd_config's AuthorizedKeysFile option for $HOME-relative
      paths.
    - Include a language tag when sending a protocol 2 disconnection
      message.
    - Make logging of certificates used for user authentication more clear
      and consistent between CAs specified using TrustedUserCAKeys and
      authorized_keys.

openssh (1:5.4p1-2) unstable; urgency=low

  * Borrow patch from Fedora to add DNSSEC support: if glibc 2.11 is
    installed, the host key is published in an SSHFP RR secured with DNSSEC,
    and VerifyHostKeyDNS=yes, then ssh will no longer prompt for host key
    verification (closes: #572049).
  * Convert to dh(1), and use dh_installdocs --link-doc.
  * Drop lpia support, since Ubuntu no longer supports this architecture.
  * Use dh_install more effectively.
  * Add a NEWS.Debian entry about changes in smartcard support relative to
    previous unofficial builds (closes: #231472).

openssh (1:5.4p1-1) unstable; urgency=low

  * New upstream release (LP: #535029).
    - After a transition period of about 10 years, this release disables SSH
      protocol 1 by default. Clients and servers that need to use the
      legacy protocol must explicitly enable it in ssh_config / sshd_config
      or on the command-line.
    - Remove the libsectok/OpenSC-based smartcard code and add support for
      PKCS#11 tokens. This support is enabled by default in the Debian
      packaging, since it now doesn't involve additional library
      dependencies (closes: #231472, LP: #16918).
    - Add support for certificate authentication of users and hosts using a
      new, minimal OpenSSH certificate format (closes: #482806).
    - Added a 'netcat mode' to ssh(1): "ssh -W host:port ...".
    - Add the ability to revoke keys in sshd(8) and ssh(1). (For the Debian
      package, this overlaps with the key blacklisting facil...

[tictactoe (xavier-garel)]

Thanks Colin,

But this bug with "fix released" means that it will be an update for the LTS Lucid with 5.5p1-3ubuntu1 or a backport from maverick or at last a PPA for Lucid ?

[Colin Watson (cjwatson)]

As per my previous comments in this bug, I intend to make this available in a PPA for Lucid. I have not done this yet, but I will update this bug when I have done so.

[Colin Watson (cjwatson)]

Here's the aforementioned PPA for Lucid:

  https://launchpad.net/~cjwatson/+archive/openssh

Enjoy!

[Colin Watson (cjwatson)]

I've also blogged about this:

  http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2010-05-10-openssh-5.5p1-for-lucid.html