ssh always asks to unlock private key with no password set

Closing the dialog box allows the ssh to work (one time), but doesn't work
well in automated scripts! Doing same thing from console (text mode)
works without dialog.

Thanks for your bug report. This bug has been reported to the developers of the software. You can track it and make comments here: http://bugzilla.gnome.org/show_bug.cgi?id=516097

comment from upstream "Could you paste the first line of the SSH key file into this bug report?"

Hello Stephen, any chance to do what upstream is requesting?

Similar issue here, 8.04 final.

Even though ssh-agent has been unlocked via ssh-add, the dialog comes up everytime the ssh-agent is being used for anything. After clicking "Refuse" (or whatever the untranslated button is called), regular operation proceeds.

How do I disable this annoying popup? I can handle my SSH passphrases on my own and would rather not enter my passphrase into some Gnome dialog that I've never seen before. Especially with really weird questions like the one quoted above coming from upstream.

Okay,I found directions on how to fix this at: http://live.gnome.org/GnomeKeyring/Ssh

"gconftool-2 --set -t bool /apps/gnome-keyring/daemon-components/ssh false" silences the SSH part of gnome-keyring.

Had the same problem as Martin Schmitt and his solution worked for me. Note that you need to log out of Gnome and log back in for it to take effect.

I get this too. However, I find that clicking on 'Deny' makes the window go away and everything proceeds normally.

I found clicking on the escape key would make the window disapper, but I
surely wanted to disable it for sure. The gconf setting really helped me do
that.

2008/4/28 Rkimber <email address hidden>:

> I get this too. However, I find that clicking on 'Deny' makes the
> window go away and everything proceeds normally.
>
> --
> ssh always asks to unlock private key with no password set
> https://bugs.launchpad.net/bugs/187127
> You received this bug notification because you are a direct subscriber
> of the bug.
>

those comments are not useful there, could somebody having the issue reply to the question rather than commenting about disabling ssh or workaround the bug?

-----BEGIN DSA PRIVATE KEY-----

What did you expect?

My SSH key does have a password but nonetheless I dislike this window, because it interrupts my usual routine:

$ ssh somehost
<ssh asks me for my passphrase, I realise that I haven't added the key to the ssh-agent yet. I press STRG+C...>
$ ssh-add
<I enter my passphrase into the agent>
$ ssh somehost
<ssh gets the key from the agent>

I also noticed that it seems rather random whether the dialog gets the focus; sometimes the focus just remains on the terminal window, potentially leading users to typing their passphrases in plain text into the terminal window. For me it means that hitting ESC will do nothing, and I have to use the mouse to close the window. That is just plain wrong: I'm forced to use the mouse to close a graphical dialog that pops up while I'm working in the terminal.

I think the possibility to store the passphrase in seahorse is generally a nice feature, but it should not pop up a graphical window in the terminal.

new upstream comment

"I would love to fix this. I really can't duplicate this. I have a DSA key
unencrypted without a password and it works correctly.

Are there messages from gnome-keyring-daemon in your auth.log? "

do you still get this issue? could you reply to the comment?

Frankly, I didn't quite understand the request from upstream. Has there been any change inside 8.04 that justifies creating a new user to test this with, or would it be more appropriate to test with 8.10 already?

testing on 8.10 would be useful, or describe easy steps to trigger the bug on a stock installation

I can't reproduce it with hardy.

philsf@philsf-laptop:~$ apt-cache policy openssh-server
openssh-server:
  Installed: 1:4.7p1-8ubuntu1.2
  Candidate: 1:4.7p1-8ubuntu1.2
  Version table:
 *** 1:4.7p1-8ubuntu1.2 0
        500 http://br.archive.ubuntu.com hardy-updates/main Packages
        500 http://security.ubuntu.com hardy-security/main Packages
        100 /var/lib/dpkg/status
     1:4.7p1-8ubuntu1 0
        500 http://br.archive.ubuntu.com hardy/main Packages

I tried logging with su - to a test user account, and also logging into gnome with that user, to the same result. The title says always, and it didn't happen to me in either environment. I also never seen this bug in normal usage.

I attach the full transcript of the first experiment.

Is it possible that the reporter suffered from some miscofiguration?

If the reporter needs to use ssh keys non-interactively, he could set a password and use a ssh-agent.

Sorry, no time to do it on 8.10 right now, but here you go on 8.04:

-------
groupadd martin2
useradd -g martin2 -d /home/martin2 -m -s /bin/bash martin2
passwd martin2
mkdir ~martin2/.ssh
cp ~martin/.ssh/id_dsa ~martin/.ssh/id_dsa.pub ~martin2/.ssh
chown -R martin2:martin2 ~martin2/.ssh

Log out from Gnome, log in as martin2.

Start Terminal.

1) ssh-add ----> Dialog pops up, Press "Deny", enter Passphrase in Terminal
2) ssh martin@foo ----> Dialog pops up, Press "Deny", Authentication succeeds

Message from gnome-keyring-daemon in /var/log/auth.log: "couldn't find or load public key for private key" - This is logged not upon ssh-add (Step 1) but upon authentication (Step 2).
-------

Seeing that upstream uses SSH keys without passphrase (see comment above) while maintaining a security component, I trust this Gnome-Dialog even less than before. :-(

Update for 8.10:

The dialog pops up on ssh-add, but not on SSH login attempts.That still isn't particularly nice, but at least the system is in a usable state after clicking "Deny" only once.

I've the same problem as the OTP with Ububtu 8.10; with Ubuntu 8.4 it worked with the same keys fine for me.

I didn't inspect this problem further, but for me the problem seems to be, that I can clock only on "Deny" when I have an empty password. Clicking on "OK" doesn't work, as the window re-appears automatically.

If "OK" would accept an empty password, probably the "Automtically unlock this key when I log in" checkbox would work too and avoid that the dialog pops up the next time again.

Selecting the checkbox and then clicking on "Deny" seems to not save the checkbox setting.

I am seeing that today, its new. What does auth.log say?

Jan 23 14:59:48 k2 gdm[5733]: pam_unix(gdm:session): session opened for user slo by (uid=0)
Jan 23 14:59:48 k2 gdm[5733]: pam_ck_connector(gdm:session): nox11 mode, ignoring PAM_TTY :0
Jan 23 14:59:48 k2 gdm[5733]: gnome-keyring-daemon: couldn't lookup keyring component setting: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://www.gnome.org/projects/gconf/ for information. (Details - 1: Failed to get connection to session: dbus-launch failed to autolaunch D-Bus session: No protocol specified
Jan 23 14:59:48 k2 gdm[5733]: Autolaunch error: X11 initialization failed.
Jan 23 14:59:48 k2 gdm[5733]: )gnome-keyring-daemon: couldn't lookup ssh component setting: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://www.gnome.org/projects/gconf/ for information. (Details - 1: Failed to get connection to session: dbus-launch failed to autolaunch D-Bus session: No protocol specified
Jan 23 14:59:48 k2 gdm[5733]: Autolaunch error: X11 initialization failed.
Jan 23 14:59:48 k2 gdm[5733]: )gnome-keyring-daemon: couldn't lookup pkcs11 component setting: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://www.gnome.org/projects/gconf/ for information. (Details - 1: Failed to get connection to session: dbus-launch failed to autolaunch D-Bus session: No protocol specified
Jan 23 14:59:48 k2 gdm[5733]: Autolaunch error: X11 initialization failed.
Jan 23 14:59:48 k2 gdm[5733]: )
Jan 23 14:59:48 k2 gnome-keyring-daemon[5963]: Couldn't unlock login keyring with provided password
Jan 23 14:59:48 k2 gnome-keyring-daemon[5963]: Failed to unlock login on startup

In this case the root cause appears to be the login didn't start everything, so now when I try and SSH to a remote box, whatever is meant to be doing its work in the background (letting me SSH to my laptop using a non-password-protected private key) isn't.

auth.log is a good idea :) There I found the problem for my above described problem

| Jan 23 18:10:12 ax-tge gnome-keyring-daemon[6440]: couldn't find or load public key for private key
| Jan 23 18:10:12 ax-tge gnome-keyring-daemon[6440]: user denied this prompt previously, skipping prompt and automatically denying

I had in my ~/.ssh directory an old private key for which no public key was in the same directory. This seems to confuse the gnome-keyring-daemon. After deleting the old private key my problem disappeared!

Here's another clue: this issue started to occur on my system (8.10) after I've changed my password. It worked fine before. I found the same messages in my /var/log/auth.log as SteveLoughran. The only difference to before the password change are the last to lines:

Apr 4 07:05:55 seawind gnome-keyring-daemon[5520]: Couldn't unlock login keyring with provided password
Apr 4 07:05:55 seawind gnome-keyring-daemon[5520]: Failed to unlock login on startup

They didn't appear when it was working.

do you still have the issue? do you have public keys as described on the GNOME bug?

let me have a check. I think the problem was @home, judging by the
log. That machine is interesting as calls to getLocalHost() don't
always work, which is very good for finding assumptions in code,
including anything that relies on an ORB to work reliably

https://issues.apache.org/jira/browse/IVY-817
https://issues.apache.org/jira/browse/HADOOP-3426
http://jira.smartfrog.org/jira/browse/SFOS-697

On Tue, Apr 21, 2009 at 9:21 AM, Sebastien Bacher <email address hidden> wrote:
> do you still have the issue? do you have public keys as described on the
> GNOME bug?
>
> --
> ssh always asks to unlock private key with no password set
> https://bugs.launchpad.net/bugs/187127
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I still have the issue.

My SSH key is password-protected and I have a valid .pub file. (BTW it's a DSA key)

could somebody having the issue forward the bug to GNOME?

try to "unset SSH_AUTH_SOCK" before running ssh command.

How I got rid of this bug and what it indicates:

Important context:
intrepid, autologin by gdm, WPA key stored by nm in a password-less (unsecure plaintext) default.keyring, which also is the default gnome keyring.

Now, trying to use sshfs with a key authentification, this dialog pups up and I can continue by either entering my local user password or pressing "Deny". This is due to a keyring called login.keyring, which has somehow gotten created. Once it is either unlocked with my password or denied, ssh connection works since I had a key file in the first place.

IIRC, login.keyring is the former default keyring and got changed to default.keyring, but, supposedly, some ssh related part of gnome-keyring still has it hardcoded.

The workaround is - delete the login.keyring, restart session by means of autologin (not entering a password), try connecting (using sshfs with rsa keys), now a window appears asking for a password to create a new login.keyring. Just press enter, it warns about unsafe storage, accept it. Connection gets established and the popup is gone.

What has changed is that the login.keyring is now a plaintext file and contains a string with my public key, same as the wireless WPA key in the default.keyring. Thus, this bug (or feature?) may depend on autologin and/or changed passwords.

Hopefully this helps,
Kind regards,
Matiss

Still seeing this on Ubuntu 10.04; the "unset SSH_AUTH_SOCK" trick works