Ticket #162 (new defect)

Opened 16 years ago

Last modified 13 years ago

Disable GNOME keyring prompt on SSH

Reported by: geofft Owned by:
Priority: trivial Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description

From mail to debathena@ on March 8, 2009:

If you try to use SSH on cluster machines and you have a GNOME keyring (I don't know the conditions under which one would get created, but I have one), you get an annoying popup asking you to unlock your keyring, which is probably locked with an old Kerberos password. According to  http://live.gnome.org/GnomeKeyring/Ssh , you can disable the prompt by setting the gconf key /apps/gnome-keyring/daemon-components/ssh to false. This may affect people who do want to use an SSH agent, though.

Another option would be to figure out how to default gnome-keyring to not encrypt the keyring, which is probably acceptable given AFS permissions. This wouldn't help users who already have encrypted keyrings (unless we tell them to rm
~/.gnome2/keyrings/*).

jdreed says we can just document how to do one of the above two options / remove the keyring, or disable the SSH agent by default and document how to enable it.

A third option is to make debathena-ssh-client-config cause ssh_config to prefer Kerberos auth before public/private key auth. ghudson favors this one, as do I. We can do this by setting our own list of PreferredAuthentications?, with GSSAPI before SSH keys.

Change History

comment:1 Changed 16 years ago by broder

My ssh_config(5) documents PreferredAuthentications as having a default value of gssapi-with-mic, hostbased, publickey, keyboard-interactive, password. Do we have any clue why that doesn't prevent this problem?

comment:2 Changed 16 years ago by quentin

If you make a connection with -vvvv, you can see that the prompt appears before ssh has even considered the first authentication method; i.e. ssh is doing this before it starts authenticating, so the list of preferred authentication methods is irrelevant.

comment:3 Changed 15 years ago by broder

Things I found out looking into this today:

  • The keyring is created automatically by pam_gnome_keyring on login, which is enabled by default for gdm sessions in at least Jaunty.
  • That keyring is encrypted with your password
  • If you run passwd on a machine with pam_gnome_keyring configured, that'll update the keyring password as well. Otherwise, you lose

Looking at the source code, pam_gnome_keyring doesn't take any arguments except "auto_start", so I don't think creating the keyring unencrypted is an option. Even if it was, I wouldn't want to do it, because even though AFS permissions protect you some, AFS encryption is pretty bad and unenforceable from the server.

Since pam_gnome_keyring is also supposed to unlock the keyring on login, I suspect that the keyring has to be encrypted with an old password for this prompt to even come up.

I'm still not sure what the best way to fix the issue is, though.

comment:4 Changed 15 years ago by jdreed

  • Milestone set to The Distant Future

Can we consistently reproduce the failure? It sounds like we should just document this.

comment:5 Changed 15 years ago by broder

This should be consistently reproducible if you

# Login to Debathena workstation+
# Change your password something that's not using your AFS homedir
# Login to Debathena workstation+ again and try to ssh

comment:6 Changed 13 years ago by jdreed

Thank you for taking the time to report this bug and helping to make Debathena better. Please answer these questions:

  • Is this reproducible in Natty?
  • If so, what specific steps should we take to recreate this bug?

This will help us to find and resolve the problem.

Note: See TracTickets for help on using tickets.