Comment 5 for bug 195550

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.