Comment 14 for bug 1812247

We checked what actually is the backend that the "ssh-add -c" is trying to reach.
First we thought that should be the ssh-agent spawned for gnome-keyring-daemon [1]

In PS that is visible as:
1 1000 4029 1 20 0 656132 15860 - SLl ? 0:24 /usr/bin/gnome-keyring-daemon --daemonize --login
0 1000 26372 4029 20 0 11304 3696 - S ? 0:00 \_ /usr/bin/ssh-agent -D -a /run/user/1000/keyring/.ssh

Note: there is also another ssh-agent running:
0 1000 4047 4036 20 0 568216 14944 poll_s Sl+ tty2 0:00 \_ /usr/lib/gnome-session/gnome-session-binary --session=ubuntu
1 1000 4146 4047 20 0 11304 320 - Ss ? 0:00 \_ /usr/bin/ssh-agent /usr/bin/im-launch env GNOME_SHELL_SESSION_MODE=ubuntu gnome-session --session=ubuntu

That binary is the one of the openssh package that we have proven before to work fine.:
$ dpkg -S /usr/bin/ssh-agent
openssh-client: /usr/bin/ssh-agent

But it is interesting that it uses
  -a /run/user/1000/keyring/.ssh
But the env var is actually different (no . in the filename):
$ echo $SSH_AUTH_SOCK
  /run/user/1000/keyring/ssh

But look at the ownership of the socket that we found in the env var:

$ sudo lsof +fg /run/user/1000/keyring/ssh
COMMAND PID USER FD TYPE FILE-FLAG DEVICE SIZE/OFF NODE NAME
gnome-key 4029 paelzer 14u unix RW,ND,0x80000 0xffff910ac4316800 0t0 130189 /run/user/1000/keyring/ssh type=STREAM

So while there is a real /usr/bin/ssh-agent running the actual socket that the env variable points to is actually owned by gnome-keyring process.

Above we have proven that with a classic ssh-agent it works fine (comment #6).
The bug task for openssh is invalid for now due to that.

Maybe the gnome-keyring backend doesn't even have the -c feature [1] doesn't list it - then it would be a feature request there.
But in any case we need to re-triage that at gnome-keyring, so that is the package I'm adding a bug task for.

[1]: https://wiki.gnome.org/Projects/GnomeKeyring/Ssh