upstart configuration for user launches an extra ssh-agent

Bug #1244736 reported by Bruno Vasselle
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
gnome-session (Ubuntu)
Confirmed
Undecided
Unassigned
openssh (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Symptom: the ssh-agent does not have my key anymore after upgrade to 13.10

I use kdm and pam-ssh to deal with my keys.

It appears that pam-ssh does its job, and my key it actually there... in another agent: I can see 2 ssh-agent processes, and changing the SSH_AUTH_SOCK and SSH_AGENT_PID environment variables so that they refer to the other one reveals my key...

The script /usr/share/upstart/sessions/ssh-agent.conf launches ssh-agent, regardless of whether it is already there or not.

Adding the line:
    [ "$SSH_AGENT_PID" ] && { stop; exit 0; } # already running

before line:
    eval "$(ssh-agent)" >/dev/null

in the script does restore the behavior before upgrade.

CVE References

Revision history for this message
Bruno Vasselle (bruno-vasselle) wrote :

This does not affect "gnome-session", but "openssh-client"... I'm pretty sure I've said so before posting.

Revision history for this message
Bruno Vasselle (bruno-vasselle) wrote :

Also, this does not seem to be related to Bug #959506, as this one is pretty old, and my config used to work before 13.10.
It seems however to relate somehow loosely to Bug #1181510.
I'm adding a comment in both Bugs

Revision history for this message
Bruno Vasselle (bruno-vasselle) wrote :

I've also added two lines to protect the killing part, which I did not mention above. Don't know whether it's useful or not.

By the end of pre-start:
    initctl set-env --global SSH_AGENT_LAUNCHER=/usr/share/upstart/sessions/ssh-agent.conf

By the beginning of post-stop:
    [ "$SSH_AGENT_LAUNCHER" = /usr/share/upstart/sessions/ssh-agent.conf ] || exit 0

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-session (Ubuntu):
status: New → Confirmed
Changed in openssh (Ubuntu):
status: New → Confirmed
Revision history for this message
Guillaume Martres (smarter) wrote :

Using:
grep -q "^use-ssh-agent$" /etc/X11/Xsession.options || { stop; exit 0; }
To detect whether or not to launch the ssh agent doesn't seem to make sense to me, since if "use-ssh-agent" is true then ssh-agent will be setup by /etc/X11/Xsession.d/90x11-common_ssh-agent (and later launched), so there doesn't seem to be a need for an upstart script here.

Revision history for this message
Bruno Vasselle (bruno-vasselle) wrote :

Down again after last upgrade.

Here's my ssh-agent.conf

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

---------------
openssh (1:6.6p1-1) unstable; urgency=medium

  [ Colin Watson ]
  * Apply various warning-suppression and regression-test fixes to
    gssapi.patch from Damien Miller.
  * New upstream release (http://www.openssh.com/txt/release-6.6,
    LP: #1298280):
    - CVE-2014-2532: sshd(8): when using environment passing with an
      sshd_config(5) AcceptEnv pattern with a wildcard, OpenSSH prior to 6.6
      could be tricked into accepting any environment variable that contains
      the characters before the wildcard character.
  * Re-enable btmp logging, as its permissions were fixed a long time ago in
    response to #370050 (closes: #341883).
  * Change to "PermitRootLogin without-password" for new installations, and
    ask a debconf question when upgrading systems with "PermitRootLogin yes"
    from previous versions (closes: #298138).
  * Debconf translations:
    - Danish (thanks, Joe Hansen).
    - Portuguese (thanks, Américo Monteiro).
    - Russian (thanks, Yuri Kozlov; closes: #742308).
    - Swedish (thanks, Andreas Rönnquist).
    - Japanese (thanks, victory).
    - German (thanks, Stephan Beck; closes: #742541).
    - Italian (thanks, Beatrice Torracca).
  * Don't start ssh-agent from the Upstart user session job if something
    like Xsession has already done so (based on work by Bruno Vasselle;
    LP: #1244736).

  [ Matthew Vernon ]
  * CVE-2014-2653: Fix failure to check SSHFP records if server presents a
    certificate (bug reported by me, patch by upstream's Damien Miller;
    thanks also to Mark Wooding for his help in fixing this) (Closes:
    #742513)

 -- Colin Watson <email address hidden> Fri, 28 Mar 2014 18:04:41 +0000

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

Other bug subscribers

Remote bug watches

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