missing ssh prompt to touch yubikey device when using gnome

Bug #1869897 reported by Andreas Hasenack
56
This bug affects 9 people
Affects Status Importance Assigned to Milestone
GNOME Shell
New
Unknown
gnome-shell (Ubuntu)
Triaged
Wishlist
Unassigned

Bug Description

I can't exactly pinpoint which gnome package is responsible for this. It might be gnome-keyring. Let's go with gnome-shell first.

openssh 8.2p1[1] in focal has support for U2F authentication. This is a new feature we will highlight in the release notes and a blog post.

You can create a keypair and the authentication only succeeds if you have the u2f hardware device plugged in, and touch it at the moment of authentication.

In a console only env, it works like this:
"""
andreas@nsnx:~$ env|grep SSH
andreas@nsnx:~$ ssh -i .ssh/id_ecdsa_sk 10.0.100.75
Confirm user presence for key ECDSA-SK SHA256:bS6vX6b+Bp8Xu/LF4Gw10dV0Y6AkjFPjPoO5q0A546M
Welcome to Ubuntu Focal Fossa (development branch) (GNU/Linux 5.4.0-21-generic x86_64)
...
Last login: Tue Mar 31 13:35:44 2020 from 10.0.100.1
"""

The "Confirm" prompt is asking the user to touch the hardware device (a yubikey in this case).

If I use openssh's ssh-agent, it still works as expected and I see that prompt:

"""
andreas@nsnx:~$ env|grep SSH
andreas@nsnx:~$ eval $(ssh-agent)
Agent pid 68267
andreas@nsnx:~$ env|grep SSH
SSH_AUTH_SOCK=/tmp/ssh-75OwXd9gR6tq/agent.68252
SSH_AGENT_PID=68267
andreas@nsnx:~$ ssh -i .ssh/id_ecdsa_sk 10.0.100.75
Warning: Permanently added '10.0.100.75' (ECDSA) to the list of known hosts.
Confirm user presence for key ECDSA-SK SHA256:bS6vX6b+Bp8Xu/LF4Gw10dV0Y6AkjFPjPoO5q0A546M
Welcome to Ubuntu Focal Fossa (development branch) (GNU/Linux 5.4.0-21-generic x86_64)
(...)
Last login: Tue Mar 31 14:33:18 2020 from 10.0.100.1
"""

But with "gnome's ssh-agent" (I'm waving my hands here a bit), it just stalls. The prompt is swallowed by something. Here I opened a new gnome terminal in my existing focal desktop session:

"""
andreas@nsnx:~$ env|grep SSH
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
SSH_AGENT_PID=4655
andreas@nsnx:~$ ssh -i .ssh/id_ecdsa_sk 10.0.100.75
<hangs here, and the yubikey starts flashing>
"""

It only moves forward if I touch the device, which is expected. But the "Confirm user presence" prompt is nowhere to be seen.

I'm not sure how gnome-keyring interacts with ssh-agent. I see it is spawned by gnome-keyring-daemon:
   4556 ? Sl 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login
   6449 ? S 0:00 \_ /usr/bin/ssh-agent -D -a /run/user/1000/keyring/.ssh

But the PID referenced by the SSH_AGENT_PID shell variable above points to another copy, spawned by gnome-session-binary:
   4583 tty3 Sl+ 0:00 \_ /usr/libexec/gnome-session-binary --systemd --systemd --session=ubuntu
   4655 ? Ss 0:00 \_ /usr/bin/ssh-agent /usr/bin/im-launch env GNOME_SHELL_SESSION_MODE=ubuntu /usr/bin/gnome-session --systemd --session=ubuntu

In any case, the actual prompt "Confirm user presence for key" comes from openssh code:
./ssh-agent.c: "Confirm user presence for key %s %s",
./sshconnect2.c: "Confirm user presence for key %s %s",

My guess is that the gnome wrapper, whatever it is, is not expecting that prompt.

1. https://www.openssh.com/txt/release-8.2

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: gnome-shell 3.36.0-2ubuntu2
ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27
Uname: Linux 5.4.0-21-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu21
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Mar 31 11:29:06 2020
DisplayManager: gdm3
InstallationDate: Installed on 2019-10-13 (169 days ago)
InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Beta amd64 (20191010)
RelatedPackageVersions: mutter-common 3.36.0-2ubuntu1
SourcePackage: gnome-shell
UpgradeStatus: Upgraded to focal on 2020-01-30 (60 days ago)

Revision history for this message
Andreas Hasenack (ahasenack) wrote :
description: updated
description: updated
Changed in gnome-shell (Ubuntu):
importance: Undecided → Wishlist
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks Andreas, could you report it upstream on https://gitlab.gnome.org/GNOME/gnome-shell/issues ?

It would be nice to have that working but we don't consider it as a rls blocker issue.

tags: added: rls-ff-notfixing
removed: champagne
Revision history for this message
Andreas Hasenack (ahasenack) wrote :
description: updated
Changed in gnome-shell (Ubuntu):
status: New → Triaged
Revision history for this message
Davide Marchi (danjde) wrote :

The same problem with ssh PAM OATH and Gnome Shell 3.28.4

Via ssh no problem, via "Gnome File" filemanager gui using "sftp://user@192.168.88.250:22/home/user" no any window to ask the one time secret key, and the process fails.

sftp://vage@192.168.88.250:22/home/vage

Jul 26 18:42:16 localhost dbus-daemon[1155]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Jul 26 18:42:16 localhost NetworkManager[1207]: <info> [1595781736.3070] dhcp4 (eth1): nameserver '208.67.220.220'
Jul 26 18:42:16 localhost nm-dispatcher: req:1 'dhcp4-change' [eth1]: new request (1 scripts)
Jul 26 18:42:16 localhost NetworkManager[1207]: <info> [1595781736.3071] dhcp4 (eth1): state changed bound -> bound
Jul 26 18:42:16 localhost nm-dispatcher: req:1 'dhcp4-change' [eth1]: start running ordered scripts...
Jul 26 18:42:16 localhost systemd[1]: Starting Network Manager Script Dispatcher Service...
Jul 26 18:42:16 localhost systemd[1]: Started Network Manager Script Dispatcher Service.

If request I can try from a newer OS.

Changed in gnome-shell:
status: Unknown → New
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.