ssh command in 25.10 fails to connect with RSA key and waits

[Chris Hermansen]

After upgrading to 25.10, ssh no longer connects to my known servers with RSA or ECDSA keys.

Running

ssh -vvvv 192.168.1.21

(to connect to a server in my home network)

I see the following last few lines (I've "sanitized" a few of the lines with ***):

ebug2: pubkey_prepare: done
debug1: Offering public key: /home/***/.ssh/id_rsa RSA SHA256:+w3pYL8L+***+uPA agent
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: /home/***/.ssh/id_rsa RSA SHA256:+w3pYL8L+***+uPA agent
debug3: sign_and_send_pubkey: using <email address hidden> with RSA SHA256:+w3pYL8L+***+uPA
debug3: sign_and_send_pubkey: signing using rsa-sha2-512 SHA256:+***+uPA

And at this point, nothing...

I found this useful article on setting up ssh on Ubuntu 25.10:

www.ezone.co.uk/blog/enabling-ssh-and-key-based-login-in-ubuntu-25-10.html

which suggests, without much more detail, the use of ED25519 keys.

So I used ssh-keygen to generate an ED25519 pair and put the public key on the server "by other than ssh means"; and then I was able to connect.

The debug output given with ssh -v 192.168.1.21 now shows first offering the ED25519 key, and after the offering stanza, the server accepts stanza.

I should point out that I have the same issue connecting to my small home network Debian IOT devices and to an Ubuntu 22.04 server out in the cloud - same "off in the weeds" behaviour from the ssh client until I get an ED25519 pair in place.

I should also emphasize that I don't have a problem moving to a newer, better key technology; it's the ssh client sitting there waiting for something behaviour that's the problem.

I don't think this bug is a security vulnerability, but it could lead to people falling back to password authentication for ssh connections, which would be a security vulnerability.

ProblemType: Bug
DistroRelease: Ubuntu 25.10
Package: openssh-client 1:10.0p1-5ubuntu5
ProcVersionSignature: Ubuntu 6.17.0-6.6-generic 6.17.1
Uname: Linux 6.17.0-6-generic x86_64
ApportVersion: 2.33.1-0ubuntu3
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
Date: Fri Oct 31 10:06:24 2025
InstallationDate: Installed on 2024-04-27 (552 days ago)
InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Release amd64 (20240424)
RelatedPackageVersions:
 ssh-askpass N/A
 libpam-ssh N/A
 keychain N/A
 ssh-askpass-gnome N/A
SSHClientVersion: OpenSSH_10.0p2 Ubuntu-5ubuntu5, OpenSSL 3.5.3 16 Sep 2025
SourcePackage: openssh
UpgradeStatus: Upgraded to questing on 2025-10-30 (1 days ago)

[Mike Rans (rans)]

This might be the same ssh socket issue (https://discourse.ubuntu.com/t/25-10-gnome-49-changed-name-of-ssh-agent-socket/70033/3) I encountered in Kubuntu 25.10. What happens if you do

export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/ssh-agent.socket"

then your ssh line?

[Chris Hermansen (c-hermansen)]

Thanks for the suggestion, Mike, however there is no

$XDG_RUNTIME_DIR/ssh-agent.socket

on my system; nor is there any obvious directory in which it might be (nothing hinting at some ssh stuff in it, for example).

The environment variable

SSH_AUTH_SOCK

is set to

/run/user/1000/gcr/ssh

however, and

file /run/user/1000/gcr/ssh

reports

/run/user/1000/gcr/ssh: socket

[Benoît Jager (RCDevs Security) (benrcdevs)]

Same issue started on my desktop machine after upgrading to 25.10.

Symptoms are not exactly the same on my side as I have two ssh-ed25519 keys, and strangely only one is impacted.

When troubleshooting, it is stuck on same step as for you:
debug3: sign_and_send_pubkey: signing using ssh-ed25519 SHA256:**********

Checking processes, I see that ssh-add command is stuck. Default SSH key agent of Ubuntu is provided by Gnome through gcr-ssh-agent.service, so it may be the actually affected package.

As a workaround, I disabled it using :
systemctl --user disable --now gcr-ssh-agent.service
systemctl --user mask gcr-ssh-agent.service
systemctl --user disable --now gcr-ssh-agent.socket
systemctl --user mask gcr-ssh-agent.socket

A restart of the machine may be needed as SSH_AUTH_SOCK env variable is not directly updated.

This now works using SSH agent of openssh-client package.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Pierre PLR (ppaysant)]

I had the same issue and it seems to be caused by gnome keyring having a wrong password saved. After removing it, I was able to connect using my SSH key.

I opened "Password and Keys". In the Password / Login menu, I remove the "Unlock password for: <key name>" entry.

This is maybe related to https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/143.

I have no Idea why this entry was here.

[Nick Rosbrook (enr0n)]

Based on the comments here, it is sounding like this is caused by the switch to the gcr4 ssh agent. Marking that as an affected package.

[Alessandro Astone (aleasto)]

c-hermansen: do you also have a stuck `ssh-add` process?

Does `export SSH_AUTH_SOCK=` temporarily solve your problem?

[Chris Hermansen (c-hermansen)]

Alessandro, since I moved to an ED25519 key I don't have any problems. However if you like I can temporarily remove that key and see if things get stuck again, whether I have a stuck 'ssh-add' process and whether exporting SSH_AUTH_SOCk helps.

Let me know if you want me to test this out.

[Alessandro Astone (aleasto)]

> Let me know if you want me to test this out.

That would be helpful, yes. There seem to be multiple different issues conflating in this thread.

[Chris Hermansen (c-hermansen)]

Alessandro, I have zipped my id_ed25519 and id_ed25519.pub files and removed them.

Now when I try to ssh to one of my servers, the ssh command hangs.

    env | grep SSH

returns

    SSH_AUTH_SOCK=/run/user/1000/gcr/ssh

that file is a socket with mode srw-rw-rw-

    ps -ef | grep ssh

returns (obfuscated)

    me 4738 4476 0 06:53 ? 00:00:02 /usr/libexec/gcr-ssh-agent --base-dir /run/user/1000/gcr
    me 4741 4476 0 06:53 ? 00:00:00 /usr/bin/ssh-agent -D
    me 15983 4738 0 11:34 ? 00:00:00 /usr/bin/ssh-agent -D -a /run/user/1000/gcr/.ssh
    me 15984 4738 97 11:34 ? 00:05:25 /usr/bin/ssh-add /home/me/.ssh/id_rsa
    me 17550 15935 0 11:36 pts/0 00:00:00 ssh obfuscated-host-name
    me 17560 4738 97 11:36 ? 00:03:50 /usr/bin/ssh-add /home/me/.ssh/id_rsa
    me 24809 14488 0 11:40 pts/2 00:00:00 grep --color=auto ssh

Anything else I can uncover that might help?

[Alessandro Astone (aleasto)]

Is your id_rsa password protected?
And what about your new id_ed25519?

[Chris Hermansen (c-hermansen)]

Alessandro, both keys (rsa and ed25519) have a passphrase.

(updated 1 minute later)

I used ssh-keygen -y -f to make sure of 1) having a password and 2) that I know the password. It worked just fine.

[Mark Kirkwood (mark-kirkwood)]

Ran into this today. I see a hanging 'ssh-add' process and my ssh session is hung waiting for it. I stumbled on a workaround:

$ ssh-add # type in any password(s) as required
$ ssh server -J jump-server # should now work

i.e try to fix ssh-add so it does not need any input.