seahorse-agent stops responding when started with gpg-agent

Bug #183514 reported by Hervé Cauwelier
152
This bug affects 21 people
Affects Status Importance Assigned to Milestone
seahorse-plugins
Invalid
High
seahorse-plugins (Ubuntu)
Fix Released
High
Unassigned

Bug Description

Binary package hint: seahorse

I used to have seahorse prompting for the SSH passphrase. For instance I typed "ssh myserver", and a dialog appeared automatically.

Now that I switched to Hardy, I have to type "ssh-add" at the start of my session, like I was doing a year ago.

But the seahorse agent seems to be properly running:

herve 6400 0.0 0.3 22296 6872 ? Ss 09:33 0:00 /usr/bin/seahorse-agent --execute x-session-manager
herve 10198 0.0 0.3 45496 7676 ? Ss 12:22 0:00 seahorse-agent

And in the seahorse application, my SSH key is listed.

From bug #217270:

When I access the seahorse program preferences, in the tab "PGP Passphrases", I get the message "A supported PGP passphrase caching agent is not running".
On the console where I launched seahorse, I see:

** Message: init gpgme version 1.1.5
** (seahorse:7462): WARNING **: Invalid or no GPG agent is running. Disabling cache preferences.

I'm pretty sure the agents are running, as show with a "ps auwx|grep agent":

foo 864 ? Ss 15:46 0:00 /usr/bin/gpg-agent --daemon --sh --write-env-file=/home/lstep/.gnupg/gpg-agent-info-tsuiseki /usr/bin/seahorse-agent --execute x-session-manager
foo 756 ? Ss 15:46 0:00 /usr/bin/seahorse-agent --execute x-session-manager

Workaroung from comment 5:

I fixed my problem by looking at the default setup of another system and noting that it did not have:

   /etc/X11/Xsession.d/90gpg-agent

I renamed that file, restarted X, and all is well. Seahorse is running by itself rather than under gpg-agent:

   /usr/bin/seahorse-agent --execute x-session-manager

Revision history for this message
Dmitry Pankratov (dremon) wrote :

I can confirm this bug in Seahorse 2.22.0-0ubuntu2.
Ubuntu Hardy/AMD64.

The seahorse-agent is running but it only picks up the id_rsa key (and not id_rsa.1 etc), however other keys are configured and present in the keyring.

Revision history for this message
René Brandenburger (rene-brandenburger) wrote :

I can confirm the bug in Seahorse 2.22.0-0ubuntu2 (hardy), running Hardy, upgraded from Gutsy (Linux debberlein 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux)

The agent was working flawless in gutsy, but stopped working after upgrading to hardy. The processes are properly running

1000 3570 3466 0 23:08 ? 00:00:00 /usr/bin/ssh-agent /usr/bin/seahorse-agent --execute /usr/bin/gnome-session
1000 3576 3466 0 23:08 ? 00:00:00 /usr/bin/seahorse-agent --execute /usr/bin/gnome-session
1000 3781 1 0 23:08 ? 00:00:00 seahorse-agent

but only the first created key (id_rsa) works

Revision history for this message
Kenneth Loafman (kenneth-loafman) wrote :

This is also a problem with Thunderbird/Enigmail in decrypting email -- seahorse no longer asks for the passphrase and the decryption fails. If I use gpg from the command line, I get the curses prompt. After that the passphrase is cached and Enigmail will decrypt email. The cache still goes away after the previously set time.

A symptom of this problem is in seahorse-preferences -- instead of the dialog in PGP passphrases, you get the message

   "A supported PGP passphrase agent is not running.",

but it is,

   /usr/bin/gpg-agent --daemon --sh --write-env-file=/home/ken/.gnupg/gpg-agent-info-neptune /usr/bin/seahorse-agent --execute x-session-manager

Revision history for this message
Kenneth Loafman (kenneth-loafman) wrote :

I fixed my problem by looking at the default setup of another system and noting that it did not have:

   /etc/X11/Xsession.d/90gpg-agent

I renamed that file, restarted X, and all is well. Seahorse is running by itself rather than under gpg-agent:

   /usr/bin/seahorse-agent --execute x-session-manager

I'm not sure where the file came from or why it was there. If someone knows, please leave a message.

Revision history for this message
greenhunter (tierfreunde-hagenburg) wrote :

confirmed

Revision history for this message
Norbert Hartl (norbert-hartl) wrote :

I have seahorse 2.22.0 and I can see a lot of ssh keys in "my personal keys" tab.

I like to refer to the original bug title. Although I can see my ssh keys I'm not being asked for passphrases if they are needed.

I'm trying to connect via ssh to a certain host. I can see the key for this host in "my personal keys" tab of seahorse. And seahorse-agent is running. I only get a "permission denied (public key)".

I don't have a file 90gpg-agent and seahorse-agent is running x-session-manager

Revision history for this message
greenhunter (tierfreunde-hagenburg) wrote :

anything new here?

Enigmail is still not working and seahorse seems to be totally buggy in Hardy!

Revision history for this message
Tessa (unit3) wrote :

I'm having this problem as well, specifically the issues noticed with enigmail, after just upgrading to Hardy last night.

This is a real killer for me, as I use enigmail a *lot*.

Revision history for this message
Tessa (unit3) wrote :

I discovered in my gpg.conf there was an old gpg-agent-info entry that pointed to a non-existent path. When I removed that, the gpg found seahorse properly and worked.

I'm not sure why that never caused problems in gutsy, but I seem to have sorted out my seahorse problems.

Revision history for this message
greenhunter (tierfreunde-hagenburg) wrote :

"I discovered in my gpg.conf there was an old gpg-agent-info entry that pointed to a non-existent path. When I removed that, the gpg found seahorse properly and worked."

that is exactly the bug. I deleted the last line with an "#" and it works now.

Revision history for this message
Olaf Lenz (olenz) wrote :

The gpg issue seems to be solved by now, the solution being to delete

  /etc/X11/Xsession.d/90gpg-agent

which should not be there when seahorse-agent is used.

Still, the problem with the ssh keys seems to persist: in hardy, I have to use ssh-add again, as seahorse does not seem to work together with the ssh-agent.
Does anyone have a solution to this problem?

Revision history for this message
Andreas Moog (ampelbein) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. I don't have a solution but can say that intrepid ibex does not have this problem anymore. Can you confirm that it's fixed for you, too?

Changed in seahorse:
assignee: nobody → andreas-moog
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
Olaf Lenz (olenz) wrote :

In hardy, the problem persists. As for intrepid, I can't say so far, although I have installed alpha 5 yesterday. Will seahorse work together with KDE4?

Revision history for this message
Andreas Moog (ampelbein) wrote :

Could you already try with intrepid? Regarding KDE I don't know if that will work. Hasn't KDE its own agent?

Revision history for this message
Olaf Lenz (olenz) wrote :

I'm using kubuntu intrepid alpha 5. Unfortunately, I seem not to be able to start KDE anymore, due to some bug in this alpha version.
Therefore I'm currently unable to check whether seahorse works.

KDE doesn't bring a corresponding daemon, but uses gpg-agent and ssh-agent instead. Unfortunately, ssh-agent does not automatically ask for the passphrase to unlock the keyring when ssh is used, but ask for the passphrase for this single session instead. That's why I prefer seahorse.
Maybe I'm doing something wrong?

Revision history for this message
Mackenzie Morgan (maco.m) wrote :

Using seahorse 2.22.2-0ubuntu1 I cannot reproduce this bug. Seahorse prompts for SSH key passphrases as expected.

Revision history for this message
Sebastien Bacher (seb128) wrote :

does anybody still get the issue in intrepid?

Revision history for this message
Filipe Sousa (natros) wrote :

I have

Revision history for this message
Filipe Sousa (natros) wrote :

I just fixed it

Logout and
rm -rf private-keys-v1.d
rm gpg.conf gpg-agent-info-rome

It's working :)

Now I don't have the private-keys-v1.d nor the gpg-agent-info-rome. I guess the gpg-agent-info-rome was the root of the problem.

Revision history for this message
Norbert Hartl (norbert-hartl) wrote :

For me it doesn't work. Invoking everything on the shell just asks for things ssh does anyway. I have an env variable SSH_AUTH_SOCK that points to a keyring thing in /tmp. Trying to force a dialog by invoking stuff via ALT+F2 (no display) I onyl get a dialog for sides where I can enter a password. For passphrase stuff it is just silently failing

Revision history for this message
Tom Hudson (trhudson) wrote :

I've been using Intrepid since it's release date and this has not been an issue. Yesterday evening I installed Kubuntu and KDE 4.2 and when I logged back into Gnome this morning I received the message that "A supported PGP passphrase agent is not running".

I did the following and it resolved the issue:
sudo mv /etc/X11/Xsession.d/90gpg-agent ~/90gpg-agent.bak

Therefore, could this be related to something that Kubuntu installed?

Revision history for this message
Mackenzie Morgan (maco.m) wrote : Re: [Bug 183514] Re: [hardy] seahorse agent no longer asks for the passphrase

If you run "ps -ef | grep agent" what's running?

Revision history for this message
Tom Hudson (trhudson) wrote : Re: [hardy] seahorse agent no longer asks for the passphrase

1002 7398 1 0 11:05 ? 00:00:00 /usr/bin/dbus-launch --exit-with-session /usr/bin/pulse-session /usr/bin/seahorse-agent --execute x-session-manager
1002 7414 7340 0 11:05 ? 00:00:00 /usr/bin/seahorse-agent --execute x-session-manager

Revision history for this message
Mackenzie Morgan (maco.m) wrote : Re: [Bug 183514] Re: [hardy] seahorse agent no longer asks for the passphrase

If you put that file back, log out and back in, is seahorse-agent or gnupg-
agent running? I've got gnupg-agent running in GNOME and it's not giving me
any trouble (meanwhile seahorse-agent causes major breakage in KDE).

Revision history for this message
Tom Hudson (trhudson) wrote : Re: [hardy] seahorse agent no longer asks for the passphrase

I'm running in Gnome. I installed KDE yesterday evening (I didn't try to send email while in KDE) and when I went back to Gnome (my default display manager) the issue happened. Anyway...

When I put the file back, I get the error message again. When I run the "ps -ef | grep agent" I get the following output:
1002 9175 9116 0 14:24 ? 00:00:00 /usr/bin/gpg-agent --daemon --sh --write-env-file=/home/deathmoon/.gnupg/gpg-agent-info-deathmoon-desktop /usr/bin/dbus-launch --exit-with-session /usr/bin/pulse-session /usr/bin/seahorse-agent --execute x-session-manager
1002 9179 1 0 14:24 ? 00:00:00 /usr/bin/dbus-launch --exit-with-session /usr/bin/pulse-session /usr/bin/seahorse-agent --execute x-session-manager
1002 9195 9116 0 14:24 ? 00:00:00 /usr/bin/seahorse-agent --execute x-session-manager
1002 9518 9494 0 14:25 pts/0 00:00:00 grep agent

The 90gpg-agent file contains the following:
: ${GNUPGHOME=$HOME/.gnupg}

GPGAGENT=/usr/bin/gpg-agent
PID_FILE="$GNUPGHOME/gpg-agent-info-$(hostname)"

if grep -qs '^[[:space:]]*use-agent' "$GNUPGHOME/gpg.conf" "$GNUPGHOME/options" &&
   test -x $GPGAGENT &&
   { test -z "$GPG_AGENT_INFO" || ! $GPGAGENT 2>/dev/null; }; then

   if [ -r "$PID_FILE" ]; then
       . "$PID_FILE"
   fi

   # Invoking gpg-agent with no arguments exits successfully if the agent
   # is already running as pointed by $GPG_AGENT_INFO
   if ! $GPGAGENT 2>/dev/null; then
       STARTUP="$GPGAGENT --daemon --sh --write-env-file=$PID_FILE $STARTUP"
   fi
fi

Revision history for this message
Mackenzie Morgan (maco.m) wrote : Re: [Bug 183514] Re: [hardy] seahorse agent no longer asks for the passphrase

And what's in your ~/.gnupg/gpg.conf?

Revision history for this message
Tom Hudson (trhudson) wrote : Re: [hardy] seahorse agent no longer asks for the passphrase

# FILE CREATED BY SEAHORSE

use-agent

Andreas Moog (ampelbein)
Changed in seahorse:
assignee: andreas-moog → nobody
Andreas Moog (ampelbein)
summary: - [hardy] seahorse agent no longer asks for the passphrase
+ seahorse-agent stops responding when started after gpg-agent
summary: - seahorse-agent stops responding when started after gpg-agent
+ seahorse-agent stops responding when started with gpg-agent
description: updated
description: updated
Revision history for this message
Andreas Moog (ampelbein) wrote :

Raising importance since that's broken on default installations.

description: updated
Changed in seahorse (Ubuntu):
importance: Low → High
status: Incomplete → Confirmed
affects: seahorse (Ubuntu) → seahorse-plugins (Ubuntu)
Andreas Moog (ampelbein)
Changed in seahorse-plugins (Ubuntu):
status: Confirmed → Triaged
Changed in seahorse-plugins:
status: Unknown → New
Revision history for this message
Barry Warsaw (barry) wrote :

Confirmed on Jaunty, both on machines upgraded from Intrepid and those of a fresh install. The workaround is also confirmed to work.

Revision history for this message
wirespot (wirespot) wrote :

Confirmed on Jaunty (upgraded from Intrepid), but the workarounds DO NOT WORK.

I've located indeed the following file:

  /etc/X11/Xsession.d/90gpg-agent

Moving it out of the way and restarting did NOT fix the issue. I am still asked for the ~/.ssh/id_rsa passphrase on the command line.

Removing ~/.gnupg/gpg-agent-info-foobar and ~/.gnupg/private-keys-v1.d didn't work either.

Other relevant info:

Running agents `ps awux|grep agent`:

foobar 6341 0.0 0.0 4784 640 ? Ss 11:18 0:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/pulse-session /usr/bin/seahorse-agent --execute x-session-manager
foobar 6348 0.0 0.0 3144 724 ? S 11:18 0:00 /usr/bin/dbus-launch --exit-with-session /usr/bin/pulse-session /usr/bin/seahorse-agent --execute x-session-manager
foobar 6367 0.0 0.2 18976 6132 ? Ss 11:18 0:00 /usr/bin/seahorse-agent --execute x-session-manager

My ~/.gnupg/gpg.conf:

# FILE CREATED BY SEAHORSE
use-agent

The Seahorse interface contains the SSH private key and it's correctly configured on remote servers in authorized_keys. Connecting works fine, the sole problem being I don't get asked the passphrase by the agent.

Calling ssh-add manually works.

Revision history for this message
taka k. (scar) wrote :

i use several different keys for different remote computers, and i have them stored in ~/.ssh/keypairs/ and manage their usage with ~/.ssh/config. will seahorse ever be able to properly store and retrieve all these passphrases? i tried to run 'ssh-add' but nothing seems to happen; i am just returned to a prompt. i tried to ssh to a remote computer and entered my passphrase, logged out, and tried to ssh again; i still was asked for the passphrase.

Revision history for this message
Mackenzie Morgan (maco.m) wrote : Re: [Bug 183514] Re: seahorse-agent stops responding when started with gpg-agent

"ssh-add" does not normally have any output, so just returning to a
prompt is expected.

Revision history for this message
Simone Cianfriglia (crimer) wrote :

Execute "sudo aptitude purge gnupg-agent" and the file 90gpg-agent will go away.

Revision history for this message
Stuart Bishop (stub) wrote :

Still occurs in Karmic.

Revision history for this message
Reinhard Tartler (siretart) wrote :

Bug #346429 seems very related to this one. I even suspect that a potential fix should solve this and the other bugs together.

Revision history for this message
Reinhard Tartler (siretart) wrote :

Sorry, I meant bug #346492

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package seahorse-plugins - 2.29.90-0ubuntu2

---------------
seahorse-plugins (2.29.90-0ubuntu2) lucid; urgency=low

  * debian/seahorse-plugins.Xsession: avoid starting seahorse-agent if
    gnupg-agent is installed. This avoids bad interaction between the two,
    which seems to be known upstream in gnome #578312, closes LP: #183514
    plus duplicates.
 -- Reinhard Tartler <email address hidden> Thu, 11 Feb 2010 21:01:23 +0100

Changed in seahorse-plugins (Ubuntu):
status: Triaged → Fix Released
Changed in seahorse-plugins:
importance: Unknown → High
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.