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

[gigitek]

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@10.1.1.1: 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?

[n2o]

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.

[gigitek]

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.

[MrLavender]

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

[n2o]

Sorry I misread. My bad.

[gigitek]

@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
SSH_AUTH_SOCK=/run/user/1000/gcr/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

[n2o]

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

[gigitek]

Also this issue on Archlinux Forum is related:
https://bbs.archlinux.org/viewtopic.php?id=293602

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

[n2o]

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.