Ssh doesn't prompt for key password: agent refused operation

I’ve recently updated my Manjaro system and I noticed a change in the behavior when ssh-ing to a remote machine.
I have a ssh-key protected by a password. When I connected to a remote machine, I was asked for a password in the terminal, something like this:

$ ssh machine
Enter passphrase for /home/user/.ssh/id_rsa: 
Identity added: /home/user/.ssh/id_rsa

After the recent update:

$ ssh machine                                                                                                                                                                           
sign_and_send_pubkey: signing failed for RSA "/home/user/.ssh/id_rsa" from agent: agent refused operation
user@ Permission denied (publickey).

Also the following log is present in journalctl:

gcr-ssh-agent[14524]: couldn't prompt for password: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
gcr-ssh-agent[14524]: the /usr/bin/ssh-add command failed: Child process exited with code 1

If I install gnome-keyring (it used to work without it before) then I’m prompted for the password in a graphical prompt.

Also another workaround would be to call ssh-add before ssh-ing to the machine.
ssh-add prompts for a password in the terminal, so then ssh can use the key OK.

What has changed and how to get the old behavior back?

Check this out. There’s been a change upstream at GNOME. I have found a solution that works for me, maybe it does for you too.

Thanks for the info, I’ve seen the post before posting, but it seems that are two different situations.
The linked post is talking about gnome-keyring. I don’t have it installed, see my original post.
I’m able to connect if I install gnome-keyring (it used to work without it before): I’m prompted for the password in a graphical prompt.

Polkit maybe? - [Stable Update] 2024-03-13 - Plasma 5.27.11, Firefox, Thunderbird, AMDVLK, Qemu - #2 by philm

Sorry I misread. My bad.

@n2o Even though I don’t use gnome-keyring, it seems the issues are somehow related:

If I look at the process tree I see that gcr-ssh-agent is starting ssh-agent with the following bind address: /run/user/1000/gcr/.ssh:

$ ps auxf | grep ssh-agent

  \_ /usr/lib/gcr-ssh-agent --base-dir /run/user/1000/gcr
      \_ /usr/bin/ssh-agent -D -a /run/user/1000/gcr/.ssh

Notice the .ssh

If I look in the environment variables, ssh is using another address:

$ printenv | grep SSH

So if I start ssh with the address the ssh-agent is listening to, it works:

$ SSH_AUTH_SOCK=/run/user/1000/gcr/.ssh ssh server
Enter passphrase for key '/home/user/.ssh/id_rsa': 
Last login: Fri Mar 15 09:31:00 2024 from

It seems that the configurations are out of sync between ssh and gcr


You are right, it’s the same here. Yet it works like that so I carefully assume it’s ok like that. Maybe gcr internally uses the .ssh socket? I’m an old man with no clue so I just thank our upstream overlords that it works now and pray that they don’t take it away again :sweat_smile:

Also this issue on Archlinux Forum is related:

So my understanding: after the last update the gcr socket is active so the gcr-ssh-agent is started.
This sets the SSH_AUTH_SOCK environment variable and this will lead to using the gcr.
I did not use it before.

So to revert to my original behavior I disabled gcr:
systemctl --global disable gcr-ssh-agent.socket

This also seems to be done upstream: 4.2.1-2: stop automatically enabling the socket (05365a65) · Commits · Arch Linux / Packaging / Packages / gcr-4 · GitLab

1 Like

So just to try to understand it: ssh-agent by itself (started within a termin session for instance) needs gcr-ssh-agent.socket to be turned off because it blocks the same socket ssh-agent uses?

The solution via gcr has the advantage of working globally, also like in my case for commands started via a panel, but I totally agree that it should not block ssh-agent by default, which probably most people use.

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.