[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1094997: marked as done (regression: ssh-agent started via systemd does not allow key usage confirmation)

Your message dated Tue, 22 Apr 2025 11:44:47 +0200
with message-id <aAdlD3cNNgO0BpBN@toe.zugschlus.de>
and subject line Re: Bug#1094997: regression: ssh-agent started via systemd does not allow key usage confirmation
has caused the Debian Bug report #1094997,
regarding regression: ssh-agent started via systemd does not allow key usage confirmation
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1094997: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1094997
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: openssh-client
Version: 1:9.9p1-3
Severity: normal

Hi,

since a few releases of openssh-client, the ssh-agent is started
automatically via systemd --user. The unit in question is stored in
/usr/lib/systemd/user/ssh-agent.service

I am using a yubikey and want to give explicit confirmation for my key
being used. I am therefore giving the -c option to ssh-add. This has
stopped working since a while. This is a regression that makes it
impossible to use an important security feature.

mh@swivel:~ $ ssh-add -e /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
Card removed: /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
mh@swivel:~ $ ssh-add -c -s /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
Enter passphrase for PKCS#11:
Card added: /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
mh@swivel:~ $ ssh torres hostname
sign_and_send_pubkey: signing failed for RSA "PIV AUTH pubkey" from agent: agent refused operation
mh@torres.zugschlus.de: Permission denied (publickey).
mh@swivel:~ $ 

I guess that the agent refuses operation since it cannot open the
requester asking for confirmation if started from systemd. adding the
same key without -c works:

mh@swivel:~ $ ssh-add -e /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
Card removed: /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
mh@swivel:~ $ ssh-add -s /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
Enter passphrase for PKCS#11:
Card added: /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
mh@swivel:~ $ ssh torres hostname
torres
mh@swivel:~ $

Starting a new ssh-agent manually works as well:

mh@swivel:~ $ ssh-agent -s
SSH_AUTH_SOCK=/tmp/ssh-IWV24n2D7lTk/agent.8332; export SSH_AUTH_SOCK;
SSH_AGENT_PID=8333; export SSH_AGENT_PID;
echo Agent pid 8333;
mh@swivel:~ $ export SSH_AUTH_SOCK=/tmp/ssh-IWV24n2D7lTk/agent.8332
mh@swivel:~ $ ssh-add -e /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
Card removed: /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
mh@swivel:~ $ ssh-add -c -s /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
Enter passphrase for PKCS#11:
Card added: /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
mh@swivel:~ $ ssh torres hostname
[confirmation requester coming up]
torres
[58/5056]mh@swivel:~ $

I guess that some environment variable or access right is missing to the
ssh-agent that asks for confirmation.

There should be a workaround to allow agent confirmation still being
used.

Greetings
Marc

-- System Information:
Debian Release: trixie/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.12.11-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openssh-client depends on:
ii  adduser           3.137
ii  libc6             2.40-6
ii  libedit2          3.1-20250104-1
ii  libfido2-1        1.15.0-1+b1
ii  libgssapi-krb5-2  1.21.3-4
ii  libselinux1       3.7-3.1
ii  libssl3t64        3.4.0-2
ii  passwd            1:4.17.0~rc1-1
ii  zlib1g            1:1.3.dfsg+really1.3.1-1+b1

Versions of packages openssh-client recommends:
ii  xauth  1:1.1.2-1.1

Versions of packages openssh-client suggests:
pn  keychain                   <none>
ii  ksshaskpass [ssh-askpass]  4:6.2.5-1
pn  libpam-ssh                 <none>
pn  monkeysphere               <none>
ii  ssh-askpass                1:1.2.4.1-16+b1

-- no debconf information

--- End Message ---
--- Begin Message --- 
Version: 1:10.0p1-2

On Sun, Feb 02, 2025 at 01:06:24PM +0100, Marc Haber wrote:
> since a few releases of openssh-client, the ssh-agent is started
> automatically via systemd --user. The unit in question is stored in
> /usr/lib/systemd/user/ssh-agent.service
> 
> I am using a yubikey and want to give explicit confirmation for my key
> being used. I am therefore giving the -c option to ssh-add. This has
> stopped working since a while. This is a regression that makes it
> impossible to use an important security feature.

I was able to reproduce this behavior on both my notebook and my
desktop. And then, all of a sudden, after an unstable update, my
notebook began working again without starting the agent manually in a
window.

The issue stayed on my desktop after doing the same update.

That made me curious, and I investigate further. In the journal of the
ssh-agent, there was a row of xcb related error messages, while I knew
that my KDE session was running with Wayland. A few hours of debugging
later, I noticed that in the agent's environment, only XDG_RUNTIME_DIR
was set, while on the Notebook, I had a bunch of other XDG environment
variables:

$ set | grep XDG
XDG_CONFIG_DIRS=/home/mh/.config/kdedefaults:/etc/xdg:/usr/share/desktop-base/kf5-settings
XDG_CURRENT_DESKTOP=KDE
XDG_MENU_PREFIX=plasma-
XDG_RUNTIME_DIR=/run/user/1001
XDG_SEAT=seat0
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SESSION_CLASS=user
XDG_SESSION_DESKTOP=KDE
XDG_SESSION_ID=3
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1
XDG_SESSION_TYPE=wayland
XDG_VTNR=1

I then looked for packages that might be responsible to inject those
environment variables and that were present on the notebook, but not on
the desktop. After installing dbus-user-session, xdg-desktop-portal-kde
and xdg-user-dirs, the XDG variables are now present and ssh-agent works
on the desktop as well.

I did not go into depth which package was responsible for that, I am
happy that things work now. Judging from the description, it might be
xdg-user-dirs, and since that package generates a config file in my
$HOME, I suspect that removing it will not make the issue reappear
again.

This is to document the issue so that other people might find this.

Greetings
Marc

--- End Message ---
Reply to: