force-command unable to pass arguments along to internal-sftp

Bug #362511 reported by Carsten Andrich
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
portable OpenSSH
Fix Released
Unknown
openssh (Debian)
Fix Released
Unknown
openssh (Ubuntu)
Fix Released
Low
Colin Watson
Karmic
Won't Fix
Low
Colin Watson

Bug Description

Source package: openssh_5.1p1.orig.tar.gz + openssh_5.1p1-5ubuntu1.diff.gz
Ubuntu Release: Jaunty
Package Version: openssh-server_5.1p1-5ubuntu1

When using OpenSSH's ForceCommand sshd_config directive to launch its internal-sftp, it is not possible to pass arguments to the latter. Example:
This fails (sshd tries to invoke it as if it were an application):
> ForceCommand internal-sftp -l INFO
This works:
> ForceCommand internal-sftp

This bug has already been fixed in the upstream version of OpenSSH, see: https://bugzilla.mindrot.org/show_bug.cgi?id=1527 and http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/session.c.diff?r1=1.241;r2=1.242;f=h

I consider this bug as of pretty low priority since it only matters for ppl who use ForceCommand + the internal-sftp + care about logging (transfer) actions made by clients.

I have compiled a fixed version (attached patch applied) of OpenSSH in my PPA, just in case anyone would like to use that feature, too.

Revision history for this message
Carsten Andrich (carsten-andrich) wrote :

The attached patch is taken from the first of the above links and adjusted to patch the openssh_5.1p1-5ubuntu1 source package.

Revision history for this message
Andreas Olsson (andol) wrote :

I'm setting this bug as confirmed based on upstream report, as well on some quick testing of my own.

Changed in openssh (Ubuntu):
status: New → Confirmed
Revision history for this message
Andreas Olsson (andol) wrote :

@Carsten: By the way, thanks for supplying the modified patch.

Right now Jaunty is in FinalFreeze, but after Release I'll take a look at it and see if I can create a debdiff to be upload. Just not sure if it will be important enough for a SRU, or if it will have to wait for Karmic.

https://wiki.ubuntu.com/FinalFreeze
https://wiki.ubuntu.com/StableReleaseUpdates

Changed in openssh:
status: Unknown → Fix Released
Revision history for this message
Carsten Andrich (carsten-andrich) wrote :

Unfortunately I didn't think of the RC-Release/FinalFreeze, otherwise I'd have published that bug report earlier.
Anyhow, I seriously doubt that too many users will miss this feature in Jaunty, since it has only been introduced in OpenSSH 4.8p1 and is available in Ubuntu since Intrepid. I for once have only become aware of the ForceCommand and internal-sftp based chrooting method roughly a week ago. As this is - obviously - no regression either, it probably won't justify a SRU, but as I already rely heavily on it I will keep backporting the patch to the current jaunty versions of OpenSSH (And anyone who wants can get it from my PPA).

Revision history for this message
Andreas Olsson (andol) wrote :

@Carsten: You'r probably right about it not being important enough for a SRU. Unless somehow disagree and actually makes it happen, feel free to ping this bug when the Karmic development has started.

Might also be a good idea to report this bug to the Debian BTS. Do you want to do it, or shall I?

https://wiki.ubuntu.com/Debian/Bugs

Revision history for this message
Carsten Andrich (carsten-andrich) wrote :

@Andreas: I'd like to report it myself. Thanks for both the hint and the offer, though. I just want to repay both Debian and Ubuntu a tiny part of what I owe both of them. ;)

Changed in openssh (Debian):
status: Unknown → New
Thierry Carrez (ttx)
Changed in openssh (Ubuntu):
importance: Undecided → Low
Colin Watson (cjwatson)
Changed in openssh (Ubuntu Karmic):
assignee: nobody → Colin Watson (cjwatson)
Revision history for this message
Thierry Carrez (ttx) wrote :

Per 20091020 meeting

Changed in openssh (Ubuntu Karmic):
status: Confirmed → Won't Fix
Colin Watson (cjwatson)
Changed in openssh (Ubuntu):
status: Confirmed → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (4.4 KiB)

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

---------------
openssh (1:5.2p1-1ubuntu1) lucid; 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. Note that the Upstart job does not
    support /etc/default/ssh, because it's much more straightforward to edit
    the job (/etc/init/ssh.conf) than it was to edit the init script.

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

  * New upstream release (closes: #536182). Yes, I know 5.3p1 has been out
    for a while, but there's no GSSAPI patch available for it yet.
    - Change the default cipher order to prefer the AES CTR modes and the
      revised "arcfour256" mode to CBC mode ciphers that are susceptible to
      CPNI-957037 "Plaintext Recovery Attack Against SSH".
    - Add countermeasures to mitigate CPNI-957037-style attacks against the
      SSH protocol's use of CBC-mode ciphers. Upon detection of an invalid
      packet length or Message Authentication Code, ssh/sshd will continue
      reading up to the maximum supported packet length rather than
      immediately terminating the connection. This eliminates most of the
      known differences in behaviour that leaked information about the
      plaintext of injected data which formed the basis of this attack
      (closes: #506115, LP: #379329).
    - ForceCommand directive now accepts commandline arguments for the
      internal-sftp server (closes: #524423, LP: #362511).
    - Add AllowAgentForwarding to available Match keywords list (closes:
      #540623).
    - Make ssh(1) send the correct channel number for
      SSH2_MSG_CHANNEL_SUCCESS and SSH2_MSG_CHANNEL_FAILURE messages to
      avoid triggering 'Non-public channel' error messages on sshd(8) in
      openssh-5.1.
    - Avoid printing 'Non-public channel' warnings in sshd(8), since the
      ssh(1) has sent incorrect channel numbers since ~2004 (this reverts a
      behaviour introduced in openssh-5.1; closes: #496017).
    - Disable nonfunctional ssh(1) ~C escape handler in multiplex slave
      connections (closes: #507541).
    - Fix "whitepsace" typo in ssh_config(5) (closes: #514313, LP: #303835).
  * Update to GSSAPI patch from
    http://www.sxw.org.uk/computing/patches/openssh-5.2p1-gsskex-all-20090726.patch,
    including cascading credentials support (LP: #416958).
  * Use x11.pc when compiling/linking gnome-ssh-askpass2 (closes: #555951).
  * Moved to bzr.debian.org; add Vcs-Bzr and Vcs-Browser control fields.
  * Add debian/README.source with instructions on bzr handling.
  * Make ChrootDirectory work with SELinux (thanks, Russell Coker; closes:
    #556644).
  * Initialise sc to NULL in ssh_selinux_getctxbyname (thanks, Václav Ovsík;
    closes: #498684).
  * Don't duplicate backslashes when displaying server banner (thanks,
    Michał Górny; closes: #505378, LP...

Read more...

Changed in openssh (Ubuntu):
status: Fix Committed → Fix Released
Changed in openssh (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.