Bug#1021613: systemd: generates too much log for ssh connection

[Michael Biebl]

On Tue, 11 Oct 2022 22:02:31 +0200 Vincent Lefevre <vin...@vinc17.net>
wrote:
> Package: systemd
> Version: 247.3-7+deb11u1
> Severity: minor
>
> Each time I do a Subversion connection via ssh, I get 24 lines of logs
> from systemd (in addition to a few ones from sshd), e.g.
>
> Oct 11 20:36:27 joooj systemd-logind[579]: New session 379 of user svn.
> Oct 11 20:36:27 joooj systemd[1]: Created slice User Slice of UID 1001.
> Oct 11 20:36:27 joooj systemd[1]: Starting User Runtime Directory /run/user/1001...
> Oct 11 20:36:27 joooj systemd[1]: Finished User Runtime Directory /run/user/1001.
> Oct 11 20:36:27 joooj systemd[1]: Starting User Manager for UID 1001...
> Oct 11 20:36:27 joooj systemd[26819]: pam_unix(systemd-user:session): session opened for user svn(uid=1001) by (uid=0)
> Oct 11 20:36:27 joooj systemd[26819]: Queued start job for default target Main User Target.
> Oct 11 20:36:27 joooj systemd[26819]: Created slice User Application Slice.
> Oct 11 20:36:27 joooj systemd[26819]: Reached target Paths.
> Oct 11 20:36:27 joooj systemd[26819]: Reached target Timers.
> Oct 11 20:36:27 joooj systemd[26819]: Listening on GnuPG network certificate management daemon.
> Oct 11 20:36:27 joooj systemd[26819]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
> Oct 11 20:36:27 joooj systemd[26819]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
> Oct 11 20:36:27 joooj systemd[26819]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
> Oct 11 20:36:27 joooj systemd[26819]: Listening on GnuPG cryptographic agent and passphrase cache.
> Oct 11 20:36:27 joooj systemd[26819]: Reached target Sockets.
> Oct 11 20:36:27 joooj systemd[26819]: Reached target Basic System.
> Oct 11 20:36:27 joooj systemd[1]: Started User Manager for UID 1001.
> Oct 11 20:36:27 joooj systemd[1]: Started Session 379 of user svn.
> Oct 11 20:36:27 joooj systemd[26819]: Reached target Main User Target.
> Oct 11 20:36:27 joooj systemd[26819]: Startup finished in 95ms.
> Oct 11 20:36:28 joooj systemd-logind[579]: Session 379 logged out. Waiting for processes to exit.
> Oct 11 20:36:28 joooj systemd[1]: session-379.scope: Succeeded.
> Oct 11 20:36:28 joooj systemd-logind[579]: Removed session 379.

What you see here is expected behaviour:
Your login via SSH is apparently done via PAM, which triggers the start
of a systemd --user instance (with all that it entails). And systemd
dutifully logs everything when setting up that user instance (and
tearing it down again on log out).

If you generate lots of SSH logins via subversion, then this will
generate lots of log messages.
Maybe there is a way to use a more restricted environment/login shell
for subversion access which doesn't trigger PAM.

If you don't want to constantly start/stop the user instance, you can
also use linger, so the user instance will stick around if you terminate
your SSH session.



Not sure if there is much we can do about this in the Debian downstream
bug tracker.

[Vincent Lefevre]

On 2022-10-12 11:39:40 +0200, Michael Biebl wrote:
> What you see here is expected behaviour:
> Your login via SSH is apparently done via PAM, which triggers the start of a
> systemd --user instance (with all that it entails). And systemd dutifully
> logs everything when setting up that user instance (and tearing it down
> again on log out).

Well, the account was created by adduser with the --disabled-login
option. So I wonder why a systemd --user instance is started.

> If you generate lots of SSH logins via subversion, then this will generate
> lots of log messages.

Yes, this can happen several times per minute.

> Maybe there is a way to use a more restricted environment/login shell for
> subversion access which doesn't trigger PAM.

According to what I've read on serverfault.com, it is discouraged
to disable PAM (in particular, it is involved in authentication).

> If you don't want to constantly start/stop the user instance, you can also
> use linger, so the user instance will stick around if you terminate your SSH
> session.

However, I suppose that this would take useless resources. IMHO,
a systemd --user instance is not useful for such a user anyway
(and perhaps pam_systemd is not needed in any case on this machine:
this is just a personal VM, not a desktop machine, not a multi-user
server, so I'm wondering what it is used for).

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Michael Biebl]

Am 12.10.22 um 13:15 schrieb Vincent Lefevre:

> On 2022-10-12 11:39:40 +0200, Michael Biebl wrote:
>> What you see here is expected behaviour:
>> Your login via SSH is apparently done via PAM, which triggers the start of a
>> systemd --user instance (with all that it entails). And systemd dutifully
>> logs everything when setting up that user instance (and tearing it down
>> again on log out).
>
> Well, the account was created by adduser with the --disabled-login
> option. So I wonder why a systemd --user instance is started.

disabled-login means disabled password. You can still log in as that
user via other means (su, sudo, SSH keys).
Which mechanism do you use?

>> If you generate lots of SSH logins via subversion, then this will generate
>> lots of log messages.
>
> Yes, this can happen several times per minute.
>
>> Maybe there is a way to use a more restricted environment/login shell for
>> subversion access which doesn't trigger PAM.
>
> According to what I've read on serverfault.com, it is discouraged
> to disable PAM (in particular, it is involved in authentication).

I wouldn't recommend disable PAM in SSH (I assume you meant "UsePAM no"
in sshd_config), but use a different login shell for subversion where
PAM is not involved or rather, which uses a custom PAM profile where you
can exclude pam_systemd.so.

>> If you don't want to constantly start/stop the user instance, you can also
>> use linger, so the user instance will stick around if you terminate your SSH
>> session.
>
> However, I suppose that this would take useless resources. IMHO,
> a systemd --user instance is not useful for such a user anyway
> (and perhaps pam_systemd is not needed in any case on this machine:
> this is just a personal VM, not a desktop machine, not a multi-user
> server, so I'm wondering what it is used for).
>

I don't really know your particular setup, so it's a bit hard to give
proper advice.
But if the user used for subversion access is not meant to be a
*regular* user but some kind of specialized (system) user, it could
indeed be an option to disable systemd --user for this particular user.

[Michael Biebl]

Am 12.10.22 um 13:15 schrieb Vincent Lefevre:

> On 2022-10-12 11:39:40 +0200, Michael Biebl wrote:

>> If you don't want to constantly start/stop the user instance, you can also
>> use linger, so the user instance will stick around if you terminate your SSH
>> session.
>
> However, I suppose that this would take useless resources. IMHO,

Judging from your log, `systemd --user` basically just set's up
listening sockets. So all you've got is the `systemd --user` process
itself + a couple of open file descriptors.

Is that really any issue?

[Vincent Lefevre]

On 2022-10-12 13:42:55 +0200, Michael Biebl wrote:
> Am 12.10.22 um 13:15 schrieb Vincent Lefevre:
> > On 2022-10-12 11:39:40 +0200, Michael Biebl wrote:
> > > What you see here is expected behaviour:
> > > Your login via SSH is apparently done via PAM, which triggers the start of a
> > > systemd --user instance (with all that it entails). And systemd dutifully
> > > logs everything when setting up that user instance (and tearing it down
> > > again on log out).
> >
> > Well, the account was created by adduser with the --disabled-login
> > option. So I wonder why a systemd --user instance is started.
>
> disabled-login means disabled password. You can still log in as that user
> via other means (su, sudo, SSH keys).
> Which mechanism do you use?

No, you are confusing with --disabled-password:

--disabled-password
Like --disabled-login, but logins are still possible (for example
using SSH keys) but not using password authentication.

I really used --disabled-login. But the man page is really unclear.
The intent was to allow SSH connections, but "full" logins (with
additional services such as provided by systemd) are not necessary.

> I wouldn't recommend disable PAM in SSH (I assume you meant "UsePAM no" in
> sshd_config), but use a different login shell for subversion where PAM is
> not involved or rather, which uses a custom PAM profile where you can
> exclude pam_systemd.so.

Yes, I thought that this was the case for /bin/sh, as opposed to
/bin/bash (default for root, unless this has changed) or /bin/zsh.
But see below.

> I don't really know your particular setup, so it's a bit hard to give proper
> advice.
> But if the user used for subversion access is not meant to be a *regular*
> user but some kind of specialized (system) user, it could indeed be an
> option to disable systemd --user for this particular user.

This is certainly true for the special svn user, who has a
.ssh/authorized_keys file with only

command="/usr/bin/svnserve ...",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty

lines.

BTW, I think that rather than with the login shell, pam_systemd.so
inclusion should be controled by such an option. Something like
"no-systemd" (or perhaps pam-options="..."). But this is a setting
that would need to be forwarded to PAM, I suppose.

[Vincent Lefevre]

Probably not a real issue.

However, I think that there should be a way to disable systemd (and
perhaps have more control over PAM), e.g. with an authorized_keys
option as I've just suggested, as this is precisely where one can
require a limited use of ssh.

Perhaps this bug could be reassigned to openssh-server (this package
also provides /etc/pam.d/sshd, so it is also concerned by the PAM
configuration).

[Michael Biebl]

Am 12.10.22 um 14:22 schrieb Vincent Lefevre:

> On 2022-10-12 13:42:55 +0200, Michael Biebl wrote:
>> Am 12.10.22 um 13:15 schrieb Vincent Lefevre:
>>> On 2022-10-12 11:39:40 +0200, Michael Biebl wrote:
>>>> What you see here is expected behaviour:
>>>> Your login via SSH is apparently done via PAM, which triggers the start of a
>>>> systemd --user instance (with all that it entails). And systemd dutifully
>>>> logs everything when setting up that user instance (and tearing it down
>>>> again on log out).
>>>
>>> Well, the account was created by adduser with the --disabled-login
>>> option. So I wonder why a systemd --user instance is started.
>>
>> disabled-login means disabled password. You can still log in as that user
>> via other means (su, sudo, SSH keys).
>> Which mechanism do you use?
>
> No, you are confusing with --disabled-password:
>
> --disabled-password
> Like --disabled-login, but logins are still possible (for example
> using SSH keys) but not using password authentication.
>
> I really used --disabled-login. But the man page is really unclear.
> The intent was to allow SSH connections, but "full" logins (with
> additional services such as provided by systemd) are not necessary.

Apparently you can still use su, sudo etc with --disabled-login. So I
wonder if there is a real difference in practice to --disabled-password.

In any case, apparently a "login" under that user has happened (via SSH
I assume). Otherwise pam_systemd.so and `systemd --user` wouldn't have
been triggered.

[Vincent Lefevre]

On 2022-10-12 14:43:06 +0200, Michael Biebl wrote:
> Apparently you can still use su, sudo etc with --disabled-login. So I wonder
> if there is a real difference in practice to --disabled-password.

In some way, I would regard the command-via-ssh feature to behave
a bit like sudo: this is not a login, one just wants to run a
command (sudo is used to run it as another user, ssh is used to
run it remotely).

> In any case, apparently a "login" under that user has happened (via SSH I
> assume). Otherwise pam_systemd.so and `systemd --user` wouldn't have been
> triggered.

While I wanted to report a bug against adduser to ask for a
clarification, I saw:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625758
'adduser --disabled-login' does not behave as documented.

reported 11 years ago and still open!

Last comment a few months ago

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625758#72

with in particular:

- change and document (adduser(8)) that --disabled-password will behave
like --disabled-login and additionally set the shell to
/usr/sbin/nologin.
- --disabled-login and an explicitly set --shell is an error and will be
flagged as such.

Using both --disabled-login and --shell was exactly what I did
(setting a shell was necessary to be able to run the command,
even though how the command is run is not mentioned in the sshd
man page).