Re: *Now* what is starting ssh-agent?
On Thu 28 Jul 2022 at 10:35:07 (-0400), Greg Wooledge wrote:
> 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
> [...]
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.
> 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.
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
│ ├─user@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.
Reply to: