Rather than putting it in the session we may just need to hack the gnome-session
source, or the scripts in xinitrc. Of course then people can't get rid of it.

 I managed to get it into my default session by running the utility for managing startup 
programs, so it shouldn't need to be hardcoded.

Marking the head of the priority queue with priority high

Is this still relevant?

Yes.  Ideally we'd forward credentials from pam or something so the user doesn't
have to enter a password twice.  That gets complicated when you factor in
ssh-agent and that the password associated with a ssh key doesn't have to match
the login password.

Before adding to the default session we need to investigate what happens if the
user doesn't have ssh-gnome-askpass installed or if SSH_ASKPASS is configured to
use the terminal ask pask program.  Does it detect that we aren't attached to a
tty and exit quietly or does it hang around waiting for forever?

*** Bug 122159 has been marked as a duplicate of this bug. ***

Ray asked me to test behaviour with some variations of ssh-askpass and
ssh-askpass-gnome installed.  Tested out what happens with no askpass program
installed (prints an error to stdout, returns), what happens with only the
openssh-askpass program installed (displays the slightly uglier X-only askpass),
and with both installed, and my environment's SSH_ASKPASS set to null, the
openssh-askpass program, and the openssh-askpass-gnome program.  Behavior seems
to be much as expected, the X only program runs unless SSH_ASKPASS is set
explicitly to the GNOME version.  

This bug has been obsoleted by gnome-keyrings growing of ssh-agent support, I
beleive.