Lack of useful error messages when key cannot be added

[dinojr]

I have (according to http://www.funtoo.org/Keychain)

eval `keychain --eval --agents ssh,gpg id_rsa 370D5DFF`
eval `source ~/.keychain/$HOSTNAME-sh`
eval `source ~/.keychain/$HOSTNAME-sh-gpg`

in my ~/.bash_profile.

source ~/.bash_profile gives the following error:

* keychain 2.8.1 ~ http://www.funtoo.org
 * Found existing ssh-agent: 2278
 * Starting gpg-agent...
 * Known ssh key: /home/wilk/.ssh/id_rsa
 * Adding 1 gpg key(s): 370D5DFF
 * Error: Problem adding (is pinentry installed?); giving up

However, there is no error when this ~/.bash_profile is sourced by logging through ssh into the machine. Any idea what could be wrong ?

[ser]

It's silly, but ubuntu comes with two gpg versions, 1 and 2. Gpg agent comes from version two, but keychain is using version one, so this is it does not work. I have no idea how can I convince keychain to use version two.

[svenha]

Same problem here (Ubuntu 16.04). Any solutions around?

[aklaing]

I don't know if this will help:

There is a call to gpg in the last while loop of keychain. I have found that when I make essentially the same call manually from the command line, it works. It is an ugly fix and I don't know why it works. I have a makefile which contains the following targets. The first usually fails, but does the ssh part successfully, and the second part succeeds to fix the missing gpg functionality.

keys:
        keychain --nogui --clear --quiet --agents "gpg,ssh" --timeout 1440 /path/to/my/id_rsa 1234ABCD

keyfix:
        echo blech | gpg --no-options --use-agent --no-tty --sign --local-user 1234ABCD -o- >/dev/null 2>&1

I also have this in my .bashrc

export GNUPGHOME=/path/to/my/gpghome

# Do not remove!  Essential for correct operation of gpg2 and friends           
# for caching passphrases in gpg-agent.                                         
GPG_TTY=$(tty)
export GPG_TTY

[aklaing]

More of my random notes on this problem (maybe some of this will be helpful):

# I also changed ~/.gnupg/gpg-agent.conf to contain the line

# pinentry-program /usr/bin/pinentry-curses

# These two changes got my keychain invocation "make keys", referring
# to ~/makefile, to begin to work.

# The last time what I did which seemed to work was changing
# gpg to gpg2 inside keychain (its last while loop), and that seemed
# to work, but suddenly is no longer working.

# Then I
# ran the echo blech command from the while loop of keychain, and that
# worked.  Why it didn't work in the context of keychain I don't know.
# I ran keychain multiple times and each time it asks whether pinentry
# is installed.

[ncclementi]

I'm having the same problem in Ubuntu 16.04. When I kill the existing process and start again it works, but every time I restart the machine I have to do that. Any solution?

[thewtex]

I can confirm that changing the two instances of gpg --no-options to gpg2 --no-options in the keychain script worked for me on Ubuntu 16.04 with pinentry-program set to /usr/bin/pinentry-curses.

[danielrobbins]

This issue has been imported into the Funtoo Linux bug tracker. This helps us to ensure that your bug is prioritized and gets the attention it deserves. You are welcome to create a Funtoo account and participate in the Funtoo Linux workflow or follow-up in the GitHub issue (comments are not currently synchronized.) Follow the action here: https://bugs.funtoo.org/browse/FL-3410

[danielrobbins]

I've done some research on this and a number of things could be causing the issue. Try running the following commands from the console:

$ GPG_TTY=$(tty)
$ gpg --no-options --use-agent --sign --local-user 11FD00FD

Then see what it says. If pinentry is working OK, you should be prompted for a password. If the passphrase is already cached, you should just see text that says something like this:

You need a passphrase to unlock the secret key for
user: "Daniel Robbins (metro:node) [email protected]"
4096-bit RSA key, ID 1BAECB2E, created 2016-12-10 (main key ID 11FD00FD)

Anything else will indicate a problem. In my case, I reproduced the issue by not having an available signing key which prevented the default command the keychain uses to cache the passphrase into gpg-agent to fail.

[ddoherty03]

I struggled with this for a long time. What finally ended the pain was adding the '--stop others' option
to my invocation of keychain. I suspect that it was accessing an agent (the systemd launched agent?) that knew nothing of my terminal, so no setting in .bashrc (config.fish in my case) of GPG_TTY, nor any setting of the pinentry-program option in gpg-agent.conf was having any effect on the agent running before my session was launched. But that's just a guess.

[titanofold]

I got this same error with Keychain 2.8.1.

My key was expired.

[proinsias]

@titanofold – thanks, this was my issue too.

[gabrix73]

I have this in my .bashrc:

`/usr/bin/keychain --clear $HOME/.ssh/id_ed25519
source $HOME/.keychain/$(uname -n)-sh

`
When i login i get prompted to insert ssh keys password and i get:

• Waiting 5 seconds for lock...
• Found existing ssh-agent: 4332
• ssh-agent: All identities removed.
• Adding 1 ssh key(s): /home/user1/.ssh/id_ed25519
  Enter passphrase for /home/user1/.ssh/id_ed25519:
• Error: Problem adding; giving up

`
At this stage i kill the agent:

:~$ ssh-agent -k

than i launch bash again, i insert my password and it works:

• Starting ssh-agent...
• ssh-agent: All identities removed.
• Adding 1 ssh key(s): /home/user1/.ssh/id_ed25519
  Enter passphrase for /home/user1/.ssh/id_ed25519:
• ssh-add: Identities added: /home/user1/.ssh/id_ed25519

`
I'm running debian9 stretch, it's monthes i'm strugling with this.
Regards :)

[ghost]

Could you test this with the latest version of keychain, 2.8.4 and see if it is still a problem?

[ant1441]

I am seeing this, tested with the latest version of keychain.

I believe (for me at least), this is caused by my version of gpg-agent, I think it is expected that gpg-agent writes to stderr the env file, which it is not:

$ gpg-agent --daemon --write-env-file
gpg-agent[26640]: WARNING: "--write-env-file" is an obsolete option - it has no effect
gpg-agent[26642]: gpg-agent (GnuPG) 2.1.11 started
$ gpg-agent --version
gpg-agent (GnuPG) 2.1.11
libgcrypt 1.6.5
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ dpkg -S `which gpg-agent`
gnupg-agent: /usr/bin/gpg-agent

This, along with keychain unsetting GPG_AGENT_INFO before attempting to source it from the (empty) pidfile results in GPG being unable to use pinentry for my key.

Commenting out line 657 fixes this issue for me.

[Nate-Wilkins]

Just for completeness sake I ran into this error I had to update the permissions of my key to chmod 644

[stevehemingway]

I had this problem, which took me a long time to fix. I am not really sure why it worked, but I adopted @ddoherty03 's suggestion of adding a --stop others to the command line and it seemed to work.

The relevant fragment of my .bash_profile reads:

# fix it so gpg-agent works (see https://github.com/funtoo/keychain/issues/59 )
LIFE=84000
export GPG_AGENT_INFO="~/.gnupg/S.gpg-agent:$(pgrep gpg-agent):1"
eval `keychain --stop others --noask --eval --agents gpg,ssh --inherit any --timeout $LIFE id_rsa`
# note this is a bit flakey. See https://github.com/funtoo/keychain/issues/61
# supposedly the --stop others fixes a bug.
GPG_TTY=$(tty)
export GPG_TTY
echo "make gpg-agent will print an error message if cannot connect to the running agent"
gpg-agent

[PhilipDaniels]

I also recently had problems with keychain printing Error: Problem adding; giving up. Turned out to be permissions on the ~/.ssh/id* files were too wide. I discovered this by trying to add them manually with a simple ssh-add id_foo, which prints a descriptive error which keychain apparently silently eats. This was with keychain 2.8.1 on Linux Mint 18.3.

[kwhat]

Sigh, 7 months later and I am looking at the same error... After reading the comments, it seems like a more descriptive error message is in order. The program failed for some reason doesn't really help anyone.

[uhthomas]

I also came across this oddly undescriptive error message.

❯ ssh milkshake
Last login: Sat Nov  6 22:23:38 2021 from 100.74.113.114
 * Error: Problem adding; giving up

The fix for me was running ssh-add as I had forgotten to do so beforehand.

[kindlychung]

chmod 400 ~/.ssh/id_rsa_key solved it for me.

[killshot13]

chmod 400 ~/.ssh/id_rsa_key solved it for me.

Worked for me as well. Apparently, if the permissions are misconfigured on SSH/GPG keys after initially being set correctly and subsequently added to keychain/pinentry, an Error: Problem adding; giving up message will be generated.

This persists until the insecure changes are reversed using chmod 400 ~/.ssh/example_private_key on each of the affected keys.

[sascha-wi]

Sigh, 7 months later and I am looking at the same error... After reading the comments, it seems like a more descriptive error message is in order. The program failed for some reason doesn't really help anyone.

Yes hello?

[ashleyghooper]

Would be great if keychain could report that the key was expired, rather than claiming it can't find pinentry. I wasted too much time due to an expired key.

[danielrobbins]

I have updated the issue description to describe the common theme of not having descriptive error messages when a key is unable to be added. I think that this can be addressed and is a problem.

Marking as in progress.

[danielrobbins]

I just fixed this in git master. keychain will now show any error output generated when failing to add a key as a warning, for both ssh and gpg. This will appear in all versions after 2.9.0_beta3.