libpam-ssh doesn't unlock my key

[Robbert]

Binary package hint: libpam-ssh

In Ubuntu Hardy libpamssh doesn't work anymore, it worked fine in Gutsy. Doesn't work means, it doesn't unlock my key. Instead of libpam-ssh unlocking my key I get an gtk like dialog asking me for my passphrase.

My /etc/pam.d/gdm:
#%PAM-1.0
auth requisite pam_nologin.so
auth required pam_env.so readenv=1
auth required pam_env.so readenv=1 envfile=/etc/default/locale
@include common-auth
@include pam-ssh-auth
auth optional pam_gnome_keyring.so
@include common-account
session required pam_limits.so
@include common-session
@include pam-ssh-session
session optional pam_gnome_keyring.so auto_start
@include common-password

According to /usr/share/doc/libpam-ssh/README.Debian this should be correct, and with the same configuration it worked in Gutsy.

Some trivial information:
Distro: Ubuntu Hardy 8.04 x86_64
Version of libpam: 1.91.0-9.2

[Robbert (robbertkrebbers)]

This bug still exists...

[Jeff (jeff-w-beaird)]

I believe I am seeing the same bug. Attempts to add my ssh key to the ssh-agent fail with "Could not open a connection to your authentication agent."

Here is my /etc/pam.d/gdm:
#%PAM-1.0
auth requisite pam_nologin.so
auth required pam_env.so readenv=1
auth required pam_env.so readenv=1 envfile=/etc/default/locale
@include pam-ssh-auth
@include common-auth
auth optional pam_gnome_keyring.so
@include common-account
session required pam_limits.so
@include pam-ssh-session
@include common-session
@include pam-ssh-session
session optional pam_gnome_keyring.so auto_start
@include common-password

Running strace with ssh-add produces the following salient output:
socket(PF_FILE, SOCK_STREAM, 0) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
connect(3, {sa_family=AF_FILE, path="/tmp/keyring-7VA4wG/ssh"}, 110) = -1 ECONNREFUSED (Connection refused)
close(3) = 0
write(2, "Could not open a connection to y"..., 58Could not open a connection to your authentication agent.
) = 58
exit_group(2) = ?

Here's another odd thing. When I run 'env | grep -i ssh' I see:
SSH_AGENT_PID=27069
SSH_AUTH_SOCK=/tmp/keyring-7VA4wG/ssh

But when I 'cat .ssh/agent-myhostname' I see:
SSH_AUTH_SOCK=/tmp/ssh-AtsvA27068/agent.27068; export SSH_AUTH_SOCK;
SSH_AGENT_PID=27069; export SSH_AGENT_PID;
echo Agent pid 27069;

Note that the agent PID is 27069 in both, but they are attempting to use different ssh_auth_sock's.

Problem didn't show up until a clean install of hardy.

Thanks.

[Geert Altena (ge2rt)]

I'm seeing the same things as the two above posters. I have the same GDM pam.d conf. For me, this bug showed up yesterday after an upgrade from 7.10 to 8.04 using the regular 'upgrade' option of the upgrade manager. What is strange is that the pop-up window is not styled using my regular GTK-style but instead uses the standard plain GTK style.

In addition, the SSH_AUTH_SOCK in /tmp from 'cat .ssh/agent-myhostname' is apparently the correct one as that is the one that exists, the one from 'env' does not.

[Jason Kraftcheck (kraftche)]

I think this is a bug in gnome-keyring-daemon. Doing:
  fuser $SSH_AUTH_SOCK
returns the PID of gnome-keyring-daemon.

So gnome-keyring-daemon is trying to take over ssh key management, but apparently is not capable of doing so. It should be possible to disable gnome-keyring handling of ssh keys by adding the "--components=keyring" flag. However, I can't seem to find where gnome-keyring is started from.

[Jason Kraftcheck (kraftche)]

More random notes that might help someone who understands this mess:
   o Without libpam-ssh, ssh-agent will never be started because
      /etc/X11/Xsession.d/90x11-common_ssh-agent will not start ssh-agent
      if SSH_AUTH_SOCK is defined, and gnome-keyring-daemon apparently
      defines it.
   o Remote connections via SSH get the ssh-agent SSH_AUTH_SOCK
      (/tmp/ssh-*/agent.$PID) while anything started from within the X
      session gets a SSH_AUTH_SOCK pointing to gnome-keyring-daemon.
   o By setting SSH_AUTH_SOCK to point to the ssh-agent socket, the
      key(s) unlocked by libpam-ssh are used.

My (dubious) conclusions:
  o libpam-ssh spawns a ssh-agent regardless if there is one already
     running and/or that functionality is provided by some other
     application (e.g. gnome-keyring-daemon).
  o gnome-keyring-daemon will override any existing ssh-agent when
     it is started, rather than doing something more intelligent such
     as forwarding requests to the existing agent.
I think if either of the above issues were fixed, then by ordering the entries in the pam config correctly, things would work correctly. The latter issue must be corrected for things to work correctly for both local and remote terminals. If both issues are corrected, then the order of the entries in the pam config shouldn't matter. Perhaps the best solution would be to just pass "--components=keyring" to gnome-keyring-daemon and use ssh-agent for the handling of all ssh keys.

Which reminds me that in gutsy, the functioning of libpam-ssh depended on the order of the entries in the pam config so presumably one of the above issues existed in gutsy as well.

[Valentijn Sessink (valentijn)]

I have the same problem.
My pstree shows:

     ├─gdm───gdm─┬─Xorg

With all Gnome-stuff hanging under gdm:
  Z
gdm
  └─gnome-session─┬─bluetooth-apple
                                ├─gnome-panel
                                ├─gnome-settings-───{gnome-settings-}
                                ├─nautilus
                                ├─nm-applet
                                ├─python
                                ├─seahorse-agent
                                ├─2*[ssh-agent]
                                ├─tracker-applet
                                ├─trackerd───2*[{trackerd}]
                                ├─update-notifier
                                └─{gnome-session}

My collegue, who has Hardy as well, does not have this problem. His pstree shows:

     ├─gdm───gdm─┬─.xsession─┬─gnome-session─┬─bluetooth-apple

with separate stuff below separate deamons; as far as I can see, his GDM starts an Xsession:

    Z Z Z
  gdm xssn g-ssn
    │ │ │
    │ │ ├─evolution-alarm───{evolution-alarm}
    │ │ ├─gnome-cups-icon
    │ │ ├─gnome-panel───{gnome-panel}
    │ │ ├─gnome-settings-─┬─pulseaudio─┬─gconf-helper
    │ │ ├─nautilus
    │ │ ├─nm-applet
    │ │ ├─python
    │ │ ├─tracker-applet
    │ │ ├─update-notifier
    │ │ └─{gnome-session}
    │ ├─seahorse-agent
    │ └─ssh-agent
    └─Xorg

Will research a bit further - so a GDM restart is necessary; here's my comment, more will follow.

[Valentijn Sessink (valentijn)]

OK, here's a fix that worked for my setup.
Could you (other bug subscribers) check your /etc/pam.d/gdm and see what it says?

My old config (NON working):
#%PAM-1.0
auth optional pam_group.so
auth requisite pam_nologin.so
auth required pam_env.so readenv=1
auth required pam_env.so readenv=1 envfile=/etc/default/locale
@include common-auth
auth optional pam_gnome_keyring.so
@include common-account
session required pam_limits.so
@include common-session
session optional pam_gnome_keyring.so auto_start
@include common-password

My new config (WORKING):
#%PAM-1.0
auth optional pam_group.so
auth requisite pam_nologin.so
auth required pam_env.so
@include common-auth
@include common-account
session required pam_limits.so
@include common-session
@include common-password

[Simon Sprünker (simons.spruenker)]

Valentijn, I tried your new config. Unfortunately it does not work for me.
Regarding you previous post: My gdm also starts an xsession.

[Harri (harald-dunkel)]

Seems that Valentijn's new config doesn't use libpam-ssh or pam-gnome-keyring at all.

According to the README in libpam-ssh you should be able to login if your password unlocks the private key in your .ssh directory. So for testing I would recommend to set the passphrase on your ssh key to a different string than your local passwd.

Somebody mentioned the word "mess". I would second that.

[Fran Burstall (feb-maths)]

This issue only started to bite me after upgrading to intrepid.

I note:

1. Turning off the ssh component of gnome-keyring under gconf (set /apps/gnome-keyring/daemon-components/ssh to false) no longer seems to work (I guess this is what has changed with intrepid).

2. Commenting out the line:

session optional pam_gnome_keyring.so auto_start

in /etc/pam.d/gdm _does_ work for me. This stops gnome-keyring from hijacking SSH_AUTH_SOCK and involving itself irritatingly in the affairs of ssh. However, I have no actual use for gnome-keyring and so cannot say if my fix breaks something for those that do. YMMV.

---Fran

[Fran Burstall (feb-maths)]

More on this: I find that there is a known bug in intrepid's gnome-keyring that stops it from reading the gconf database.

See https://bugs.launchpad.net/gnome-keyring/+bug/275010/comments/9 for a workaround that stops gnome-keyring from messing with ssh.

---Fran

[Thomas Hotz (thotz-deactivatedaccount)]

Confirming because it happens to several people.