Whither the authentication agent?

[jimbobrae]

opensuse tumbleweed 20260122
linux v6.18.6-1-default x86_64
gnome 49 wayland

I posted a topic here. It discusses the lack of an authentication agent in Tumbleweed. There was no resolution to the issue.

This is my issue:

$ ssh-add 
Could not open a connection to your authentication agent.

The above is why I must now provide a password to access remote systems when previously it was not needed.

Common solutions do not resolve the issue.

1. ssh-keygen (with and without a passphrase), ssh-copy-id (which has never worked for me).
2. eval $(ssh-agent -s); ssh-add ~/.ssh/id-name creates a ssh-agent instance. Somehow that fails. The agent creates some environment variables:

$ ssh-agent
SSH_AUTH_SOCK=/home/jmoe/.ssh/agent/s.QCeyyzcZiJ.agent.2Fx1sCplQ2; export SSH_AUTH_SOCK;
SSH_AGENT_PID=463984; export SSH_AGENT_PID;
echo Agent pid 463984;

These vars do not appear to be public despite the export command:

$ env | grep SSH
$

3. I have browsed through Seahorse, gnome’s security app. No help there.

The aforementioned post provides debug output from ssh. The conclusion is: there is no authentication agent. The connection process proceeds the same to the point where an agent is requested.

I updated Tumbleweed since that post. I can no longer create passwordless logins, period.

Where is an authentication agent started?
Is it part of ssh? Or gnome? Or … ?

[hendersj]

It might be helpful for you to describe your end goal - why an agent is important, as opposed to using native transparent authentication.

[malcolmlewis]

@jimbobrae gnome-keyring automatically creates?

echo $SSH_AUTH_SOCK
/run/user/1000/gcr/ssh

ps -ef | grep ssh-agent

/usr/libexec/gcr-ssh-agent --base-dir /run/user/1000/gcr
/usr/bin/ssh-agent -D -a /run/user/1000/gcr/.ssh

ps -ef | grep keyring

/usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

Likewise on remotes, I just ssh-copy-id some_remote if I want root access then the remote needs some config.

[jimbobrae]

@malcolmlewis

gnome-keyring automatically creates?

I do not know.

$ show-app agent
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
jmoe       10267  0.0  0.0 310384  5284 ?        Ssl  Jan24   0:00  \_ /usr/libexec/gcr-ssh-agent --base-dir /run/user/1000/gcr
jmoe       10271  0.0  0.0  10140  4212 ?        S    Jan24   0:00  |   \_ /usr/bin/ssh-agent -D -a /run/user/1000/gcr/.ssh
jmoe      150526  0.0  0.0  81800  1976 ?        Ss   Jan26   0:00  \_ gpg-agent --homedir /home/jmoe/.gnupg --daemon

$ show-app keyring
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
jmoe        6348  0.0  0.0 313944  5596 ?        Ssl  Jan24   0:00  \_ /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets
jmoe        5431  0.0  0.0 183196  5804 ?        SLl  Jan24   0:00 /usr/bin/gnome-keyring-daemon --daemonize --login

$ echo $SSH_AUTH_SOCK
$

(show-app searches ps -aux output for the keyword.)
gnome-keyring-daemon is running. ssh cannot detect it for some reason?

[jimbobrae]

@hendersj

It might be helpful for you to describe your end goal - why an agent is important, as opposed to using native transparent authentication.

I use ssh to update remote websites. In the past I had created a passwordless login for each site I maintain. It worked flawlessly for years. Until it did not, several months ago when a password became required at each login.

What is “native transparent authentication?”

[malcolmlewis]

@jimbobrae so if gpg-agent isn’t running what happens?

On the remote hosts is the sshd config allow password login etc? I have no issues here with multiple systems running GNOME/Hyprland/multi-user connecting over ssh, cockpit client (uses ssh), qemu and sshfs. If I want direct root access, then I do need to configure the remote to allow.

No configuration changes on the remote sites with respect to sshd?

If you create a test user and login as that user, does the issue duplicate?

[hendersj]

@jimbobrae

What is “native transparent authentication?”

Not the correct name for it. What I meant was public key authentication - so you set a public key/private key pair, put the public key in the ~/.ssh/known_hosts file on the target system (make sure the permissions are right), and then when you log in with the username on that host via SSH, as long as the server is configured to support public key authentication, you don’t have to enter a password.

No agent required.

[jimbobrae]

@hendersj

set a public key/private key pair, put the public key in the ~/.ssh/known_hosts file on the target system

Yes. It is what I had done years ago and it worked as expected. Until it did not a few months ago.

Clearly something changed. The troubleshooting has narrowed to a missing authentication agent. And here I am stuck. Is it a problem with Gnome? A problem with ssh? ssh-agent? gnome-keyring-daemon? Some other problem? A configuration issue?

[hendersj]

Did something change on the server side?

GNOME wouldn’t have anything to do with it if you’re working from the command-line.

I would start with the basics - looking at the server config and the client config.

[jimbobrae]

@hendersj

Did something change on the server side?

I would not know; it is a hosting service. None of our account’s ssh data changed.

When I first created the key pair years ago, ssh defaulted to an RSA algorithm. The hosting service had since decided RSA was no longer good enough; it did grandfather it. I made a new pair anyway using Elliptic Curve (ED25519). It made no difference.

GNOME wouldn’t have anything to do with it if you’re working from the command-line.

See the first post.

I suspect gnome-keyring-daemon is defective by not providing an authentication agent ssh expects as is explained in the keyring’s man page. It did in the past.

I would start with the basics - looking at the server config and the client config.

I have done so. AFAICT nothing is amiss.

[malcolmlewis]

You might need to run ssh -vv remote-host again and just check. To me it all points at the remote system, sure your using the right id_ed25519 and id_ed25519.pub files…

[jimbobrae]

I have found a workaround: keychain.

It is a simple app that creates the necessary bits and pieces for ssh-agent to function. Its only drawback is the lack of permanent retention of passwords; it is effective only until a reboot (it does survive account logout), at which time I must enter the passwords again.

To install keychain all I needed to do was add a line of script to .bashrc. Passwordless logins work again!

[jimbobrae]

I think I have found what the issue is: a missing option for gnome-keyring-daemon. From ps:

$ show-app keyring
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
jmoe        5758  0.0  0.0 313944 10968 ?        Ssl  11:21   0:00  \_ /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets
jmoe        4875  0.0  0.0 183028  9928 ?        Sl   11:21   0:00 /usr/bin/gnome-keyring-daemon --daemonize --login

From the man page for :

-c, --components=ssh,secrets,pkcs11
           Ask the daemon to only initialize certain components.  Valid components are ssh, secrets, pkcs11.

The keyring is activated only for “secrets”. I suspect adding “ssh” to the list would resolve the issue.

Anyone know where these types of configuration are kept?