*Now* what is starting ssh-agent?

[Chris Mitchell]

Hi all,

I have my own systemd "user" .service unit that I like to use to start
ssh-agent the way I want it started, which works fine… except for the
neverending game of whack-a-mole tracking down and disabling various
legacy workarounds that go ahead and start ssh-agent unasked (or
emulate it, poorly, like gnome-keyring) and clobber my SSH_AUTH_SOCK
env-var.

Here's my service file:

$ cat /etc/systemd/user/ssh-agent.service
[Unit]
Description=SSH key agent
[Service]
Type=exec
# %t resolves to XDG_RUNTIME_DIR; see SPECIFIERS section in
systemd.unit(5)
ExecStart=/usr/bin/ssh-agent -D -a "%t/ssh-agent.socket"
[Install]
WantedBy=default.target

Sure enough, on a current laptop running Bookworm, even though I have
that service enabled and running, and I've gone through my list of
things to disable, there's a superfluous ssh-agent process running with
the default randomized socket location, and SSH_AUTH_SOCK has been
clobbered to point at that.

Here's what I know so far:

$ env | grep -i ssh
SSH_AUTH_SOCK=/tmp/ssh-XXXXXXZAaNOY/agent.3010
SSH_AGENT_PID=3011

$ ps ax | grep 3011
3011 ? Ss 0:00 /usr/bin/ssh-agent -s

$ pstree -ps 3011
systemd(1)───ssh-agent(3011)

Here I get confused. The path shown by ps rules out the possibility
that it's some other utility pretending to be ssh-agent. Unless I'm
mistaken, that pstree result indicates that this ssh-agent process was
started by systemd, but:

$ grep -rl ssh-agent /usr/lib/systemd/
/usr/lib/systemd/user-environment-generators/90gpg-agent
/usr/lib/systemd/user/gpg-agent-ssh.socket
/usr/lib/systemd/user/ssh-agent.service

Even though gpg-agent is running, I think it can be ignored because:
* it wouldn't show up in ps as "/usr/bin/ssh-agent",
* that environment generator only sets the SSH_AUTH_SOCK env-var if
"enable-ssh-support" is enabled per "gpgconf --list-options
gpg-agent", which it is not, and
* Those two ssh-related env-vars don't match gpg-agent's PID or
ssh-agent-socket path.

And /usr/lib/systemd/user/ssh-agent.service is not the culprit, because:
* /etc/systemd/user/ssh-agent.service has a higher priority, which
causes systemd to ignore the one under /usr/lib/, and
* /usr/lib/systemd/user/ssh-agent.service uses the socket location
"$XDG_RUNTIME_DIR/openssh_agent"

Continuing the search:
$ grep -rl ssh-agent /etc/systemd/
Returns one hit, which is my custom service file as shown above

$ grep -rl ssh-agent ~/.config/systemd/
Returns nothing, unsurprisingly.

Things that are already disabled:
* gnome-keyring is not installed
* /etc/X11/Xsession.options option use-ssh-agent is commented out
* XFCE4's "Application Autostart" config has no entry for ssh-agent
* XFCE4's "Launch GNOME services on startup" is disabled (If enabled,
this option launches gnome-keyring if available, which by default
would emulate ssh-agent and clobber the env-var)
* $ grep -rl ssh-agent ~/.config/autostart/ returns nothing, as expected

Anyone got any idea where I should look next to identify what's
actually starting that rogue ssh-agent process & clobbering my env-var,
and prevent it from doing so?

Cheers!
-Chris

PS. Please keep all replies on-list, thanks!

[Erwan David]

Le 26/07/2022 à 20:40, Chris Mitchell a écrit :
> Hi all,
>
> I have my own systemd "user" .service unit that I like to use to start
> ssh-agent the way I want it started, which works fine… except for the
> neverending game of whack-a-mole tracking down and disabling various
> legacy workarounds that go ahead and start ssh-agent unasked (or
> emulate it, poorly, like gnome-keyring) and clobber my SSH_AUTH_SOCK
> env-var.
>

ssh-agent is usually started by your session manager. I do not know
wether all DE use this, but you can find it in

/etc/X11/Xsession.d/90x11-common_ssh-agent

[Greg Wooledge]

On Tue, Jul 26, 2022 at 03:40:48PM -0300, Chris Mitchell wrote:
> Here's my service file:
>
> $ cat /etc/systemd/user/ssh-agent.service

According to systemd.unit(5) this directory is for "User units created
by the administrator".

> Here's what I know so far:
>
> $ env | grep -i ssh
> SSH_AUTH_SOCK=/tmp/ssh-XXXXXXZAaNOY/agent.3010
> SSH_AGENT_PID=3011
>
> $ ps ax | grep 3011
> 3011 ? Ss 0:00 /usr/bin/ssh-agent -s
>
> $ pstree -ps 3011
> systemd(1)───ssh-agent(3011)

PID 1 is the system instance of systemd. Not a user instance.
The ssh-agent with PID 3011 is being started by the system instance, so
it is a system unit. It's not your locally defined user unit.

Things you should look at next, I suppose:

systemctl status ssh-agent
systemctl --user status ssh-agent

Starting an ssh-agent via systemd is completely outside of my experience,
though, and I don't really understand why you'd attempt it. It's not
clear to me *at all* how you would communicate the environment variables
from the ssh-agent invocation over to the user's login session.

[Michael Biebl]

Can you post the output of
systemd-cgls

[Chris Mitchell]

On Tue, 26 Jul 2022 21:54:18 +0200
Erwan David <er...@rail.eu.org> wrote:

> ssh-agent is usually started by your session manager. I do not know
> wether all DE use this, but you can find it in
>
> /etc/X11/Xsession.d/90x11-common_ssh-agent

True. The snippet in that file is nested in a conditional, though:
if has_option use-ssh-agent; then
…

If I'm not mistaken, disabling "use_ssh_agent" in
/etc/X11/Xsession.options causes that conditional to fail, so
/etc/X11/Xsession.d/90x11-common_ssh-agent will do nothing.

man Xsession(5) uses the wording "If the line ‘use-ssh-agent’ is
present in Xsession.options", but man Xsession.options(5) says "All of
the above options are enabled by default" and instructs to disable
them by prefixing the option with "no-". Prior experience suggests that
commenting the line out *is* sufficient to disable it, but just to be
sure I have uncommented the line and changed it to "no-use-ssh-agent".
Even after a reboot, this has made no difference to the situation.

$ grep -i ssh ~/.xsession-errors returns no results, and that file
*does* have entries showing other environment variables being set via
dbus-update-activation-environment.

I suppose I could try commenting out the whole snippet in
/etc/X11/Xsession.d/90x11-common_ssh-agent, or moving the file away, but
at this point I'm reasonably confident Xsession is not the culprit.

Thanks for the lead, though. I know a bit more about how Xsession works
now than I did yesterday.

Cheers!
-Chris

[Greg Wooledge]

On Wed, Jul 27, 2022 at 09:08:59AM -0300, Chris Mitchell wrote:
> On Tue, 26 Jul 2022 21:54:18 +0200
> Erwan David <er...@rail.eu.org> wrote:
>
> > ssh-agent is usually started by your session manager. I do not know
> > wether all DE use this, but you can find it in
> >
> > /etc/X11/Xsession.d/90x11-common_ssh-agent
>
> True. The snippet in that file is nested in a conditional, though:
> if has_option use-ssh-agent; then
> …
>
> If I'm not mistaken, disabling "use_ssh_agent" in
> /etc/X11/Xsession.options causes that conditional to fail, so
> /etc/X11/Xsession.d/90x11-common_ssh-agent will do nothing.

That all sounds correct, and matches up with your earlier message stating
that ssh-agent is a direct child of systemd PID 1. It's not being started
by Xsession.

We really need to see the systemd diagnostics that have been requested
by multiple people, now.

[to...@tuxteam.de]

On Wed, Jul 27, 2022 at 09:08:59AM -0300, Chris Mitchell wrote:

> On Tue, 26 Jul 2022 21:54:18 +0200
> Erwan David <er...@rail.eu.org> wrote:
>
> > ssh-agent is usually started by your session manager. I do not know
> > wether all DE use this, but you can find it in
> >
> > /etc/X11/Xsession.d/90x11-common_ssh-agent
>
> True. The snippet in that file is nested in a conditional, though:
> if has_option use-ssh-agent; then
> …
>
> If I'm not mistaken, disabling "use_ssh_agent" in
> /etc/X11/Xsession.options causes that conditional to fail, so
> /etc/X11/Xsession.d/90x11-common_ssh-agent will do nothing.
>
> man Xsession(5) uses the wording "If the line ‘use-ssh-agent’ is
> present in Xsession.options", but man Xsession.options(5) says "All of
> the above options are enabled by default" and instructs to disable
> them by prefixing the option with "no-". Prior experience suggests that
> commenting the line out *is* sufficient to disable it,

It isn't, see below.

> but just to be
> sure I have uncommented the line and changed it to "no-use-ssh-agent".
> Even after a reboot, this has made no difference to the situation.

I think it doesn't work as you think it does. Obviously, has_option
is a shell function. It is defined in /etc/X11/Xsession:

has_option() {
# Ensure that a later no-foo overrides an earlier foo
if [ "$(echo "$OPTIONS" | grep -Eo "^(no-)?$1\>" | tail -n 1)" = "$1" ]; then
return 0
else
return 1
fi
}

Why prefixing things with `no-' doesn't help you I can't say either.
Since this is all shell script, I'd insert some code in your
90x11-common_ssh-agent to clarify the situation. E.g. some little
thing echoing hello to some file in /tmp at strategic places.

Then you know whether to continue chasing that one or looking elsewhere.

Cheers
--
t

[Chris Mitchell]

Jul. 26, 2022 17:00:46 Greg Wooledge <gr...@wooledge.org>:

> On Tue, Jul 26, 2022 at 03:40:48PM -0300, Chris Mitchell wrote:
>> Here's my service file:
>>
>> $ cat /etc/systemd/user/ssh-agent.service
>
> According to systemd.unit(5) this directory is for "User units created
> by the administrator".

Yup, that's me!
In practice, it means units placed there are user units that are
available to all users on the system, so they can
start/stop/enable/disable/… their own instances of those units via
"systemctl --user" commands (or root can do the same for all users at
once with "systemctl --global). A unit in this directory will supersede
a same-named unit in /usr/lib/systemd/user, and may in turn be
superseded on a user-by-user basis via their respective
~/.config/systemd/user directories.

> PID 1 is the system instance of systemd.  Not a user instance.
> The ssh-agent with PID 3011 is being started by the system instance,
> so it is a system unit.  It's not your locally defined user unit.

Oh, yes. I should have realized that. Weird that the system instance
would be configured to start an ssh-agent at all, but I'll definitely
look there next.

> Things you should look at next, I suppose:
>
> systemctl status ssh-agent
> systemctl --user status ssh-agent

The --user one shows that my custom "global" user unit at
/etc/systemd/user is up and running as expected, which I can verify by
manually changing SSH_AUTH_SOCK to point to the socket specified there
and accessing the agent. If the *system* systemd instance is actually
launching an ssh-agent and injecting corresponding env-vars into my
regular user environment, that is deeply strange, and I'm reasonably
sure I haven't done anything that could cause that outcome.

# systemctl status ssh-agent.service
Unit ssh-agent.service could not be found.

# systemctl list-units --all *ssh*
UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.

> Starting an ssh-agent via systemd is completely outside of my
> experience, though, and I don't really understand why you'd attempt
> it.  It's not clear to me *at all* how you would communicate the
> environment variables from the ssh-agent invocation over to the
> user's login session.

My setup is to have each user's "user" systemd instance manage their
ssh-agent (which is also how the Bookworm package handles it, though
with some differences in the implementation details). Being a
long-running daemon type process that provides a service to other
processes, ssh-agent struck me as an ideal candidate for being handled
by the service manager. The only environment variable that remains
relevant now that systemd handles the process control stuff is
SSH_AUTH_SOCK, and because I specify a consistent socket location, I
can set that statically for all login sessions, the same way you would
go about adding a custom location to PATH or whatever.

Advantages include:
* hands-on learning experience with systemd, which is clearly here to
stay,
* make ssh-agent start, and behave consistently, regardless of what DE
I use, or no DE, or no X or Wayland or graphical anything,
* any user who has a non-zero number of active login sessions gets
exactly one ssh-agent process, regardless of what "type" of session(s)

For example: if I log in to XFCE4, load a few ssh keys into my
ssh-agent, and something causes X to hang, I swap to VT1 and log in
there. Systemd no-ops my ssh-agent.service because it's already
running, and access to ssh-agent works right there in VT1, including the
already-loaded keys. Now I restart lightdm, which kills the session
that started my ssh-agent.service, but because I still have a non-zero
number of active login sessions (VT1), systemd keeps that service
running. Then I can swap back to the lightdm greeter and log in to
XFCE4, or KDE, or Enlightenment, or whatever, and my ssh-agent is
already up and ready with the keys I loaded earlier. Just for fun, if I
want to make ssh-agent socket-activated for every user on the system
instead of auto-started at login, I can drop a ~5 line ssh-agent.socket
file in /etc/systemd/user/ alongside the ssh-agent.service file,
systemctl --global disable the .service unit and enable the .socket
unit instead, and that's it.

I've been using this "global" systemd user unit to manage ssh-agent for
a couple of years now, and it's just about perfect… except when some
legacy workaround comes along and clobbers things.

Cheers!
-Chris

[Chris Mitchell]

First, for context:

$ systemd-cgls --user-unit ssh-agent.service
Unit ssh-agent.service
(/user.slice/user-1000.slice/us...@1000.service/app.slice> └─3166
/usr/bin/ssh-agent -D -a /run/user/1000/ssh-agent.socket

That is my custom "global" user ssh-agent.service, not the rogue
ssh-agent.

The rogue ssh-agent is also started:

$ env | grep -i ssh

SSH_AUTH_SOCK=/tmp/ssh-XXXXXX3Q3EAs/agent.3302
SSH_AGENT_PID=3303

The full output of
# systemd-cgls
is over 200 lines, and paste.debian.net rejected it with the message
"do not spam", so here we go:

https://pastebin.com/68wWRnyb

Cheers!
-Chris

[Chris Mitchell]

Still picking away at this…

The PIDs are, of course, a moving target, as every time I log out and
back in to test a change, ssh-agent instances are getting shut down and
new ones started. As of right now:
* my systemd-managed ssh-agent is PID 3017
* the rogue ssh-agent is PID 7687

$ systemctl --user status ssh-agent.service
● ssh-agent.service - SSH key agent
Loaded: loaded (/etc/xdg/systemd/user/ssh-agent.service; enabled;
vendor preset: enabled) Active: active (running) since Thu 2022-07-28
08:02:14 ADT; 1h 21min ago Main PID: 3017 (ssh-agent)
Tasks: 1 (limit: 9302)
Memory: 560.0K
CPU: 5ms
CGroup: /user.slice/user-1000.slice/us...@1000.service/app.slice/ssh-agent.service
└─3017 /usr/bin/ssh-agent -D -a /run/user/1000/ssh-agent.socket

From the output of systemd-cgls I see that the rogue ssh-agent process
is part of the .scope CGroup corresponding to my X login session.

# systemctl status session-8.scope
● session-8.scope - Session 8 of User chris
Loaded: loaded (/run/systemd/transient/session-8.scope; transient)
Transient: yes
Active: active (running) since Thu 2022-07-28 08:59:48 ADT; 25min
ago Tasks: 254
Memory: 957.6M
CPU: 2min 5.903s
CGroup: /user.slice/user-1000.slice/session-8.scope
├─ 7588 lightdm --session-child 14 23
├─ 7625 xfce4-session
├─ 7687 /usr/bin/ssh-agent -s
etc.

man systemd.scope(5) says:
Scope units are not configured via unit configuration files, but are
only created programmatically using the bus interfaces of systemd.
[…] Unlike service units, scope units manage externally created
processes, and do not fork off processes on its own.

By my reading, that seems to indicate that the rogue ssh-agent (PID
7687) is a direct child of systemd's system instance (PID 1) only
because my XFCE4 session and all of its associated processes are running
contained in a "scope" (to take advantage of systemd's resource
management capabilities?), and this does not indicate that said
ssh-agent is in any direct or relevant sense being managed by systemd.
Can anyone confirm or correct my understanding here?

Also, in the absence of more promising leads, I followed Tomas' advice
and inserted "echo" statements at every decision point in
90x11-common_ssh-agent, which confirmed that the initial "if
has_option" check is returning False and none of the code in that if
block is being run. I'm convinced that Xsession is not the culprit.

Any ideas where I might look next? Anyone know if it's possible to ask
systemd what process "externally created" a process in a .scope?

Cheers!
-Chris

[Greg Wooledge]

On Thu, Jul 28, 2022 at 10:34:50AM -0300, Chris Mitchell wrote:
> From the output of systemd-cgls I see that the rogue ssh-agent process
> is part of the .scope CGroup corresponding to my X login session.
>
> # systemctl status session-8.scope
> ● session-8.scope - Session 8 of User chris
> Loaded: loaded (/run/systemd/transient/session-8.scope; transient)
> Transient: yes
> Active: active (running) since Thu 2022-07-28 08:59:48 ADT; 25min
> ago Tasks: 254
> Memory: 957.6M
> CPU: 2min 5.903s
> CGroup: /user.slice/user-1000.slice/session-8.scope
> ├─ 7588 lightdm --session-child 14 23
> ├─ 7625 xfce4-session
> ├─ 7687 /usr/bin/ssh-agent -s
> etc.

Looks like it's coming from login stuff, somehow.

Curious, I looked at my own session.

unicorn:~$ ps -ef | grep ssh-agent
greg 956 912 0 Jul09 ? 00:00:04 /usr/bin/ssh-agent /home/greg/.xsession
greg 968 1 0 Jul09 ? 00:00:00 ssh-agent -s
greg 1510760 984 0 10:24 pts/2 00:00:00 grep ssh-agent

unicorn:~$ systemctl status session-1.scope
● session-1.scope - Session 1 of user greg
Loaded: loaded (/run/systemd/transient/session-1.scope; transient)
Transient: yes
Active: active (running) since Sat 2022-07-09 08:23:23 EDT; 2 weeks 5 days>
Tasks: 1176
Memory: 9.7G
CPU: 1w 5d 8h 51min 25.285s
CGroup: /user.slice/user-1000.slice/session-1.scope
├─ 697 /bin/login -p --
├─ 856 -bash
├─ 871 /bin/sh /usr/bin/startx
├─ 893 xinit /etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc>
├─ 894 /usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth />
├─ 912 /bin/bash /home/greg/.xsession
├─ 956 /usr/bin/ssh-agent /home/greg/.xsession
├─ 968 ssh-agent -s
├─ 971 rxvt -font 7x13 -geometry 80x24+0+116
[...]

My .xsession file contains only this line concerning ssh-agent:

hash ssh-agent 2>/dev/null && eval "$(ssh-agent -s)"

So... in my case... "ssh-agent -s" (PID 968) is the one I requested. What
is the *other* one, PID 956? It's a child of 912 (shown earlier), so
let's trace that back:

unicorn:~$ ps -fp 912
UID PID PPID C STIME TTY TIME CMD
greg 912 893 0 Jul09 tty1 00:00:00 /bin/bash /home/greg/.xsessi
unicorn:~$ ps -fp 893
UID PID PPID C STIME TTY TIME CMD
greg 893 871 0 Jul09 tty1 00:00:00 xinit /etc/X11/xinit/xinitrc

/etc/X11/xinit/xinitrc is a shell script that contains only one non-comment
line:

. /etc/X11/Xsession

Looking for related stuff:

unicorn:~$ grep -r ssh-agent /etc/X11/Xsession*
/etc/X11/Xsession.d/90x11-common_ssh-agent:# $Id: 90x11-common_ssh-agent 305 2005-07-03 18:51:43Z dnusinow $
/etc/X11/Xsession.d/90x11-common_ssh-agent:SSHAGENT=/usr/bin/ssh-agent
/etc/X11/Xsession.d/90x11-common_ssh-agent:if has_option use-ssh-agent; then
/etc/X11/Xsession.d/90x11-common_ssh-agent: if [ -f /usr/bin/ssh-add1 ] && cmp -s $SSHAGENT /usr/bin/ssh-agent2; then
/etc/X11/Xsession.d/90x11-common_ssh-agent: # use ssh-agent2's ssh-agent1 compatibility mode
/etc/X11/Xsession.options:use-ssh-agent

So, I suppose Debian is starting this ssh-agent via its Xsession even
though I have my own .xsession file which is starting my own instance of
ssh-agent.

I guess you've already disabled that one...?

Anyway, your login is completely different from mine (you're using lightdm,
while I'm using a console login and startx), so you'll have to pursue your
own investigation from here.

Given the order of the processes shown in your session-8, it looks like
it might be an XFCE thing. Maybe start there? I can't help you with
that, though.

[David Wright]

I did much the same …

> My .xsession file contains only this line concerning ssh-agent:
>
> hash ssh-agent 2>/dev/null && eval "$(ssh-agent -s)"

… but I don't do that. So my ssh-agent is still "properly" parented,
rather than an adoptee of 1.

I assume that some process above ssh-agent has died, unintentionally
or otherwise.

> > Any ideas where I might look next? Anyone know if it's possible to ask
> > systemd what process "externally created" a process in a .scope?

I'm not sure what you mean by this, unless it's the (wrong) idea that
systemd "injected" the ssh-agent into your scope, evidenced by its
parent being PID 1. My scope is clearly generated merely by logging in.
Everything in it is mine, all mine … …

Control group /:
-.slice
├─user.slice
│ └─user-1000.slice
│ ├─us...@1000.service
│ │ ├─app.slice
│ │ │ ├─at-spi-dbus-bus.service
│ │ │ │ ├─5409 /usr/libexec/at-spi-bus-launcher
│ │ │ │ ├─5414 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2…
│ │ │ │ └─5419 /usr/libexec/at-spi2-registryd --use-gnome-session
│ │ │ ├─pipewire.service
│ │ │ │ ├─1103 /usr/bin/pipewire
│ │ │ │ └─1108 /usr/bin/pipewire-media-session
│ │ │ └─dbus.service
│ │ │ ├─1106 /usr/bin/dbus-daemon --session --address=systemd: --nofork --n…
│ │ │ └─5466 /usr/libexec/dconf-service
│ │ └─init.scope
│ │ ├─1088 /lib/systemd/systemd --user
│ │ └─1089 (sd-pam)
│ └─session-4.scope
│ ├─1082 /bin/login -p --
│ ├─1105 -bash
│ ├─2107 /bin/sh /usr/bin/X11/startx
│ ├─2129 xinit /etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -k…
│ ├─2130 /usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth /tmp/server…
│ ├─2174 /bin/bash /home/auser/.xsession
│ ├─2218 /usr/bin/ssh-agent /bin/bash /home/auser/.xsession
│ ├─2228 /usr/bin/fvwm
│ ├─2237 /usr/lib/fvwm/2.6.8/FvwmPager 7 4 none 0 8
│ ├─2238 /usr/lib/fvwm/2.6.8/FvwmButtons 9 4 none 0 8 MyButtons
│ ├─2239 /usr/lib/fvwm/2.6.8/FvwmEvent 11 4 none 0 8 MyEvent
│ ├─2250 xterm -geometry 110x38+0+0 -xrm *Page: 4 3
│ ├─2252 bash
│ ├─2266 xterm -geometry 110x38+0+0 -xrm *Page: 3 3
│ ├─2293 bash
[ … ]
│ ├─5671 systemd-cgls --no-pager
│ └─5672 less
├─init.scope
│ └─1 /sbin/init
└─system.slice
├─xfstt.service
│ └─608 /usr/bin/xfstt --notcp
[ … ]
and the rest of the system services.

All the parent/child relationships are as you would expect, except
that each xterm was started by a deceased instance of xtoolwait
(for correct placement) and so are all adoptees of PID 1.

> > Also, in the absence of more promising leads, I followed Tomas' advice
> > and inserted "echo" statements at every decision point in
> > 90x11-common_ssh-agent, which confirmed that the initial "if
> > has_option" check is returning False and none of the code in that if
> > block is being run. I'm convinced that Xsession is not the culprit.

I'd like to see the contents of $STARTUP before it's exec'd by
/etc/X11/Xsession.d/99x11-common_start, because that's what
actually does the business.

Cheers,
David.

[Chris Mitchell]

On Thu, 28 Jul 2022 10:08:22 -0500
David Wright <deb...@lionunicorn.co.uk> wrote:

> On Thu 28 Jul 2022 at 10:35:07 (-0400), Greg Wooledge wrote:

> I did much the same …
>
> > My .xsession file contains only this line concerning ssh-agent:
> >
> > hash ssh-agent 2>/dev/null && eval "$(ssh-agent -s)"

I don't appear to have a .xsession file at all:

(Right after a "sudo updatedb")
$ locate .xsession
/home/chris/.xsession-errors
/home/chris/.xsession-errors.old
/home/chris/.xsession-startup-dump

> > Looking for related stuff:
> > …

> > /etc/X11/Xsession.options:use-ssh-agent
> >
> > So, I suppose Debian is starting this ssh-agent via its Xsession
> > even though I have my own .xsession file which is starting my own
> > instance of ssh-agent.
> >
> > I guess you've already disabled that one...?

$ grep ssh-agent /etc/X11/Xsession.options
no-use-ssh-agent

> > Anyway, your login is completely different from mine (you're using
> > lightdm, while I'm using a console login and startx), so you'll
> > have to pursue your own investigation from here.
> >
> > Given the order of the processes shown in your session-8, it looks
> > like it might be an XFCE thing. Maybe start there? I can't help
> > you with that, though.

Fair enough. Thanks for your insight up to this point!

> I assume that some process above ssh-agent has died, unintentionally
> or otherwise.
>
> > > Any ideas where I might look next? Anyone know if it's possible
> > > to ask systemd what process "externally created" a process in a
> > > .scope?
>
> I'm not sure what you mean by this, unless it's the (wrong) idea that
> systemd "injected" the ssh-agent into your scope, evidenced by its
> parent being PID 1. My scope is clearly generated merely by logging
> in. Everything in it is mine, all mine … …

> All the parent/child relationships are as you would expect, except
> that each xterm was started by a deceased instance of xtoolwait
> (for correct placement) and so are all adoptees of PID 1.

Hm. Okay, so now that those xterms are adoptees of PID 1, is there some
way you could discover that the now-deceased parents from which PID 1
adopted them were instances of xtoolwait, if you didn't already know
that?

I'm thinking that if I could get the name of the now-dead process that
started the unwanted ssh-agent process and then died and left ssh-agent
to be adopted by PID 1, that would likely be a helpful clue. But I'm
teetering on the very edge of my comprehension of the system here, and
I have no idea whether that piece of information still exists once said
parent process has died, or how to retrieve it if so.

> I'd like to see the contents of $STARTUP before it's exec'd by
> /etc/X11/Xsession.d/99x11-common_start, because that's what
> actually does the business.

Right before the exec statement in that file, I've added the line:
echo "$STARTUP" >> ~/.xsession-startup-dump

After logging out and back in, that .xsession-startup-dump file
contains one line:
x-session-manager

/usr/bin/x-session-manager is a link (via /etc/alternatives) to
/usr/bin/startxfce4

Cheers!
-Chris

[Greg Wooledge]

On Thu, Jul 28, 2022 at 02:51:04PM -0300, Chris Mitchell wrote:
> I don't appear to have a .xsession file at all:
>
> (Right after a "sudo updatedb")
> $ locate .xsession
> /home/chris/.xsession-errors
> /home/chris/.xsession-errors.old
> /home/chris/.xsession-startup-dump

It's something you either create, or don't create. People who use startx
are practically guaranteed to be the types who would create their own
.xsession files.

Desktop Environment users who login with a GUI Display Manager tend not
to be be the types of people to create a .xsession file, but it's never
guaranteed.

> Hm. Okay, so now that those xterms are adoptees of PID 1, is there some
> way you could discover that the now-deceased parents from which PID 1
> adopted them were instances of xtoolwait, if you didn't already know
> that?

Not via "ps" or any other standard tools, no. The kernel doesn't track
"birth parents" like that. The only way you could figure it out is if
something writes that PID in a log file, and you happen to find that log.

[Chris Mitchell]

On Thu, 28 Jul 2022 14:51:04 -0300
Chris Mitchell <ch...@oldnest.ca> wrote:

> > On Thu 28 Jul 2022 at 10:35:07 (-0400), Greg Wooledge wrote:

> > > Given the order of the processes shown in your session-8, it looks
> > > like it might be an XFCE thing. Maybe start there? I can't help
> > > you with that, though.
>
> Fair enough. Thanks for your insight up to this point!

Found it! It was indeed very much "an XFCE thing". It's even a
documented behaviour, if you know where to look:
https://docs.xfce.org/xfce/xfce4-session/advanced#ssh_and_gpg_agents

After creating the two xfconf entries per that page:
xfconf-query -c xfce4-session -p /startup/ssh-agent/enabled \
-n -t bool -s false
xfconf-query -c xfce4-session -p /startup/gpg-agent/enabled \
-n -t bool -s false

…and logging out and in again, no more rogue ssh-agent:

$ pgrep -a ssh-agent
2903 /usr/bin/ssh-agent -D -a /run/user/1000/ssh-agent.socket

$ systemctl --user status ssh-agent.service
● ssh-agent.service - SSH key agent
Loaded: loaded (/etc/xdg/systemd/user/ssh-agent.service; enabled;

vendor preset: enabled) Active: active (running) since Thu 2022-07-28
15:15:13 ADT; 14min ago Main PID: 2903 (ssh-agent)

Tasks: 1 (limit: 9302)
Memory: 560.0K
CPU: 5ms
CGroup:
/user.slice/user-1000.slice/us...@1000.service/app.slice/ssh-agent.service

└─2903 /usr/bin/ssh-agent -D -a /run/user/1000/ssh-agent.socket

Victory! Thanks again to everybody who offered pointers.

And I've added another entry in the list of "helpful" automatic stuff to
disable when configuring a new desktop system. I'm starting to
seriously consider that I might be happier with just a decent window
manager after all.

Cheers!
-Chris