Please backport OpenSSH 5.1 to Hardy

Thank you for your bug report, but I've removed the security flag. This should be used to highlight a specific security vulnerability in a package. In the event of a specific security vulnerability, a bug report should be opened against the affected package, so that the package can be fixed as a SRU in hardy-security. In this scenario, a backport is not normally appropriate.

openssh is unfortunately one of the packages we don't do backporting for, the chance of regression is way too high, and the benefits are fairly low. Normal security backfixes are provided by the security team, but if you want a newer openssh version, you will have to upgrade.

Martijn:

If you really want it, you can get a backport from my PPA: https://edge.launchpad.net/~rainct/+archive

[DISCLAIMER: All files there com with NO support from Canonical nor Ubuntu, and only limited maintenance from me. Use them at your own responsability.]

May be we can find a middle ground for it, like backport it with an alternative name like openssh5. This way those who really need the new features not present in hardy can have it, and you keep the backports repositories safe as usual.

I second Pablo's recommendation. I've recently undergone a PCI audit, and was flagged for not using OpenSSH 5.0p1 due to a known vulnerability in 4.7p1 (CVE-2008-1483)

If we can please backport this, I would be very appreciative!

Thank you,

VTKnightMare: Backports are *not* done in order to fix bugs. Instead, fixes for security problems are isolated as a patch, applied to the version in the repository and uploaded to hardy-security. In fact, if you look at https://launchpad.net/ubuntu/+source/openssh you can see that the particular vulnerability you mention, CVE-2008-1483, has already been fixed in all Ubuntu releases.

VTKnightMare: Your so called auditors are idiots. Ubuntu's openssh packages were patched for this issue over a year ago. http://www.ubuntu.com/usn/usn-597-1

Playing version string games is not a reason for a backport. The reasons for not backporting stand.

Hehehe :) I agree with you Scott wholeheartedly my friend! (on your comment about the auditors) However, what about Pablo's suggestion? Maybe release openssh v5.0 as openssh5-server and openssh5-client? Is this really such an un-reasonable request?

On the surface it's not unreasonable, but it's an approach that's not really maintainable. For packages like this, there really isn't a good in-archive solution. A dedicated PPA is probably your best approach. I understand Canonical is doing something similar (dedicated PPA) to get Python 2.6 into Hardy.

The comment, "[I]f you want a newer openssh version, you will have to upgrade." doesn't really make sense. This is no LTS upgrade available.

A server edition like LTS purports to be requires something better than SSH 4.8.

> A server edition like LTS purports to be requires something better than SSH 4.8.

Nope, on a server you typically value stability more than getting the
latest bleeding edge version. 4.8 is actually a quite recent version
if you compare to what is included in other currently supported
"enterprise" Linux distributions:

* Red Hat Enterprise Linux 5 (RHEL5): OpenSSH 4.3 (this of-course also
  includes derivates like CentOS 5)

* SUSE Linux Enterprise Server 10 (SLES10): OpenSSH 4.2

Also remember that all distributions, including Ubuntu, backports
security fixes for SSH.

Stability is an important value in a server, but it's not the only value.

Offering SFTP in a limited directory tree is a common server function. The claim that there is no security value in offering a version of OpenSSH with simplified SFTP chroot is rather disingenuous. The Ubuntu position appears to be:

  (a) Go to one of our shorter-lived releases and do that part right; just give up the stability value
  (b) Use tedious workarounds involving building chroot jails for each user
  (c) Force users to downgrade to FTP (a la Windows) which can easily be chrooted
  (d) Some other Linux distros are even further behind the curve so suck it up and enjoy

It's not clear what criteria Ubuntu is using to decide what to backport. But a package like this that is central to many servers' purposes ought to a prime candidate, particularly when there's no architectural reason why it can't be backported easily. See Siegfried's site.

I agree with Ray Robert. What's being asked for here is not a bleeding edge version upgrade, but rather an upgrade to an openssh version that supports easily setting up a chroot environment. This WILL lead to enhanced security. It makes no sense that the current LTS server edition doesn't support this.

This bug and the rationale for it has morphed a bit over time. Based on the features being discussed, I can see where a backport might make sense if we can test it adequately (meaning make sure it works with all the rdepends). Is anyone up for doing the testing?

I'd like to help, but have never done any formal testing. What does it entail?

I will volunteer happily! :)

Aras "Russ" Memisyazici
Systems Administrator

Office of Research
Virginia Tech

-----Original Message-----
From: Scott Kitterman <email address hidden>
Sent: Saturday, October 10, 2009 11:25 AM
To: Memisyazici, Aras <email address hidden>
Subject: [Bug 286337] Re: Please backport OpenSSH 5.1 to Hardy

This bug and the rationale for it has morphed a bit over time. Based on
the features being discussed, I can see where a backport might make
sense if we can test it adequately (meaning make sure it works with all
the rdepends). Is anyone up for doing the testing?

--
Please backport OpenSSH 5.1 to Hardy
https://bugs.launchpad.net/bugs/286337
You received this bug notification because you are a direct subscriber
of the bug.

Status in Hardy Heron Backports: Won't Fix

Bug description:
OpenSSH 4.9 - 5.1 has been out for some time but unfortunately wasn't placed into Hardy Heron.

It has a number of features which would are very interesting and should improve security. One of the most important features introduced in 5.1 according to my view is the chroot simplification.

OpenSSH now has a chroot option built-in which allows administrators to simplify their chroot installations a lot if they're only need SSH cli access and SFTP. This means fewer mis-configurations and improved overall security.

Basically, introducing a chroot setup with OpenSSH has become as simple as adding 2-3 lines in the sshd config file.

Since Hardy Heron is supposed to be an LTS version, I'm actually really surprised that this isn't in Hardy already. This is because the feature I'm describing here was introduced in OpenSSH 4.9 and Ubuntu Hardy is apparently using an even older version.

This gives me some concerns with regards to security in Hardy Heron and makes me (and my company) wonder if LTS is really the way to go.

Other changes include:

Added an extended test mode (-T) to sshd(8) to request that it write
   its effective configuration to stdout and exit. Extended test mode
   also supports the specification of connection parameters (username,
   source address and hostname) to test the application of
   sshd_config(5) Match rules.

ssh(1) and sshd(8): avoid unnecessary malloc/copy/free when receiving
   network data, resulting in a ~10% speedup

"Match group" blocks in sshd_config(5) now support negation of
   groups. E.g. "Match group staff,!guests" (bz#1315)

The sftp-server(8) manual now describes the requirements for
   transfer logging in chroot environments. (bz#1488)

Already introduced in OpenSSH 4.9 (!!!)

Added chroot(2) support for sshd(8), controlled by a new option
    "ChrootDirectory". Please refer to sshd_config(5) for details, and
    please use this feature carefully. (bz#177 bz#1352)

Linked sftp-server(8) into sshd(8). The internal sftp server is
    used when the command "internal-sftp" is specified in a Subsystem
    or ForceCommand declaration. When used with ChrootDirectory, the
    internal sftp server requires no special configuration of files
    inside the chroot environment. Please refer to sshd_config(5) for
    more information.

I'm travelling this weekend. I'll try to have a look on Monday at what's
needed.

For those who are interested, its not that hard to compile your own version. I had to remove all of openssh (server+client) using synaptic, and then compiled and packaged using checkinstall.

For some reason, the init script no longer worked so I did a removal all (or whatever its called: remove everything including configuration) and wrote my own simple startup command
/usr/sbin/sshd -f /etc/ssh/sshd_config
which is started via rc.local. I noticed this because the old starup (/etc/init.d/ssh start) did not apply the configuration I specified in sshd_config, so be careful! I don't know enough about ubuntu to tell you what's going on there.

Of course with this method you will need to personally make sure you stay up to date with any security updates in openssh.

No sense in waiting for this though. Compiling your own packages isn't so hard after all...

hmmm nothing here for a while. I just stumbled upon this trying to get an sftp chrooted env setup and realized how clumsy and hard it seemed without the latest openssh. On a centos system I resorted to using scponly but on my hardy server I'm not going to use that hack.
an openssh5 install would be great, I didn't realize hardy was on such an old version. I guess with lucid on the way there will be an upgrade path and this won't matter as much but it is a very desirable feature openssh added would have been good in hardy.

If you still fear regression issues: Maybe the new release can be initially configured as additional sshd (other port, other name).