Raspbery pi 4, Ubuntu Mate 22.04 lts. The keys are stored in keepassxc, when the database is unlocked, they are automatically added to ssh-agent. When authorizing by key, I get an error in the log: debug1: get_agent_identities: ssh_fetch_identitylist: communication with agent failed When you try again, write: debug1: get_agent_identities: ssh_get_authentication_socket: Connection refused This problem manifests itself on the arm64 architecture, on x86_64 with identical settings everything works without problems. The problem appeared after updating to version 8.9p1, I tried to build 9.0p1 from the debian repository, but the error persists.
Created attachment 3587 [details] ssh_debug_log.txt
Comment on attachment 3587 [details] ssh_debug_log.txt > debug2: get_agent_identities: ssh_agent_bind_hostkey: communication with agent failed It's possible that your agent is crashing or disconnecting after it receives the SSH_AGENT_EXTENSION session-bind@openssh.com message. If so, then the bug lies with the agent - it should ignore messages that it does not understand rather than fail.
FYI https://datatracker.ietf.org/doc/html/draft-miller-ssh-agent-04#page-11 describes the expected behaviour of an agent when receiving unknown extension requests
And how to solve this problem? As far as I understand, after upgrading to 8.9p1, users of ArchLinux encountered similar behavior without keepassxc, I saw that they rolled back over to 8.8p1
(In reply to testing from comment #4) > And how to solve this problem? Confirm that keepassxc is indeed crashing (eg by attaching an strace -p or gdb to it then reproducing the problem) and if it crashes, report the problem to the keepassxc folks.
I have already communicated about this problem by keepassxc developers, they say that the problem is in ssh-agent
Do you have a link to a keepassxc bug or email thread on the subject? If they think the problem is in ssh-agent, the a debug log from the agent would be useful (-d flag). Depending on how your shell, desktop or keepassxc starts ssh-agent, it might be a little awkward though.
(In reply to testing from comment #6) > I have already communicated about this problem by keepassxc > developers, they say that the problem is in ssh-agent The ssh logs seem to suggest otherwise. Attach an strace to both ssh-agent and keepassxc (strace -p [pid], you'll need to run that as root for at least ssh-agent and probably both) and see which one exits or stops listening when you reproduce the problem.
Looking at how keepassxc's integration works (https://keepassxc.org/docs/#faq-ssh-agent-how) it looks like it's just acts as a client to the agent not a proxy like I originally thought. The documentation says "and it acts as a client for an existing agent." which makes me wonder if you're using OpenSSH's ssh-agent or something else like the gpg-agent? Is that true on both systems? You can find out with something like: $ sudo lsof $SSH_AUTH_SOCK COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME ssh-agent 2486 dtucker 3u unix 0xffffffc036ff5e80 0t0 3273328 /tmp/ssh-oDfYy0e9aQrN/agent.2486 type=STREAM
Thanks for the help. As it turned out in Ubuntu, gnome-keyring is used and all problems are related to it. I even found a message about the problem in their git a month ago https://gitlab.gnome.org/gnome/gnome-keyring/-/issues/105 I just removed it and added to the ssh-agent autostart and everything worked. Thank you very much.
You're welcome. I added the agent socket path to the debug output so this kind of thing should be easier to spot in future. https://github.com/openssh/openssh-portable/commit/0979e29356915261d69a9517a1e0aaade7c9fc75\
Closing bugs from openssh-9.1 release cycle