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.
ssh-keygen (with and without a passphrase), ssh-copy-id (which has never worked for me).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
$
- 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 … ?
It might be helpful for you to describe your end goal - why an agent is important, as opposed to using native transparent authentication.
@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.
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?
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?”
@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?
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.
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?
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.
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.
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 have done so. AFAICT nothing is amiss.
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…
1 Like
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!
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?