Keepassxc: Linux, ssh-agent: "sign_and_send_pubkey: signing failed: agent refused operation"

[t-aus-m]

Expected Behavior

Having activated the ssh-agent feature of keepassxc, signing into an ssh server with any of the provided keys should work without any problem.

Current Behavior

Before starting keepassxc, there are no identities provided to the ssh-agent.

$ ssh-add -l                             
The agent has no identities.

After starting keepassxc, there are all identities present, that are expected.

$ ssh-add -l                             
2048 SHA256: *something something* *identity name 1* (RSA)
2048 SHA256: *something something* *identity name 2* (RSA)
2048 SHA256: *something something* *identity name 3* (RSA)

So if I now try to log into a server that is setup with one of the keys:

$ ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
user@server-ip: Permission denied (publickey).

I get the same result with two Systems. I'm completely sure that the Keys and their Passwords are correct. When I export them to my local filesystem and manually add them, everything works fine.

Context

Both systems I had this issue on are running Ubuntu 18.10, I've tried this with 4 different servers from 4 different hosts. The issue persists across all of them.

Debug Info

KeePassXC - Version 2.3.4
Revision: 6fe821c

Bibliotheken:

• Qt 5.11.1
• libgcrypt 1.8.3

Betriebssystem: Ubuntu 18.10
CPU-Architektur: x86_64
Kernel: linux 4.18.0-13-generic

Aktivierte Erweiterungen:

• Auto-Type
• Browser Integration
• Legacy Browser Integration (KeePassHTTP)
• SSH Agent
• YubiKey

[hifi]

Do you have the require confirmation box checked in KeePassXC?

Technically after the key has been added to the agent successfully KeePassXC is not part of the signing process.

EDIT: Also, what's the value of your SSH_AUTH_SOCK environment variable? If it points to /run/user then it's a GNOME Keyring started one and it may be buggy. Although Ubuntu 18.10 ships with new enough version if it it shouldn't matter too much but it's still possible.

[t-aus-m]

I've just rechecked:

Do you have the require confirmation box checked in KeePassXC?

I have.

Also, what's the value of your SSH_AUTH_SOCK environment variable?

It does indeed point to /run/user.

[hifi]

Try disabling that and if it doesn't help don't use GNOME Keyring as an SSH agent, that's pretty much what I can tell you.

[t-aus-m]

Disabling what exactly? The confirmation box? I just tried that and it does not solve the problem.

And how do I not use GNOME Keyring as an SSH-Agent? I have no Idea about that one.

[Lgmrszd]

Can confirm this bug. It happens if "Require user confirmation.." checkbox enabled, after disabling it and restarting keepassxc it works fine.

[hifi]

If that indeed is the issue then the best we could do is add a warning first time the checkbox is selected that not all agents support it or need extra configuration.

[t-aus-m]

For some reason it works now. Looks like some update fixed my issue.

[roded]

I've just experienced the same issue, unchecking the "Require user confirmation..." checkbox solved the issue. ssh-agent is running as a user systemctl service.

KeePassXC - Version 2.4.1
Revision: 7bafe65

[aligator]

you have to install either x11-ssh-askpass or any other replacement: https://wiki.archlinux.org/index.php/SSH_keys#Alternative_passphrase_dialogs
I use lxqt-openssh-askpass

If you use a replacement, which is not installed to /usr/lib/ssh/x11-ssh-askpass you may have to change the environment variable.
For this add the following to /etc/environment
SSH_ASKPASS=/usr/bin/lxqt-openssh-askpass

(I use Manjaro.)

[cl0ne]

In addition to @aligator's comment consider the following:

Confirmation with ksshaskpass works only when ksshaskpass executable is symlinked to /usr/lib/ssh/ssh-askpass.

(Arch Linux, KDE)

[idotobi]

$ hostnamectl
  Operating System: Arch Linux
            Kernel: Linux 5.6.8-arch1-1
      Architecture: x86-64

🎉 After 3h I finally found the solution to my problem. I'll post it here in case anyone runs in the same issue.

tldr: Adding the environment variable DISPLAY to the systemd file in .config/systemd/user/ssh-agent.service (which I took from Arch Wiki) makes ssh-askpass work as expected.

[Unit]
Description=SSH key agent

[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
Environment=DISPLAY=:0
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK

[Install]
WantedBy=default.target

Long story:

For me the problem was that ssh-askpass did not work right after booting the PC, but only after manually restarting the service via systemctl --user restart ssh-agent.service.

By getting the enviornment variables of the ssh-agent process before and after the restart I found that DISPLAY was only part of the environment after the restart.

FYI: You can get the environment variables of a running process in a nice format via:

ps -aux | grep ssh        # => get $pid 
cat /proc/$pid/environ | tr \\0 \\n

If anyone knows if there is a better way than hardcoding DISPLAY please let me know.