[Bug 1893716] Re: scripts in /etc/update-motd.d/ run even on login via non-interactive scp and sftp sessions

[Christian Ehrhardt ]

I must re-state that agree one might expect (I did) that on non-interactive shells these motd content would not execute at all.
... but it does ... why?

Nowadays this is all from libpam which has pam_mount (man page) and is
enabled by default here:

root at j:~# grep -Hrn motd /etc/pam*
/etc/pam.d/login:31:# This includes a dynamically generated part from /run/motd.dynamic
/etc/pam.d/login:32:# and a static (admin-editable) part from /etc/motd.
/etc/pam.d/login:33:session    optional   pam_motd.so motd=/run/motd.dynamic
/etc/pam.d/login:34:session    optional   pam_motd.so noupdate
/etc/pam.d/sshd:31:# This includes a dynamically generated part from /run/motd.dynamic
/etc/pam.d/sshd:32:# and a static (admin-editable) part from /etc/motd.
/etc/pam.d/sshd:33:session    optional     pam_motd.so  motd=/run/motd.dynamic
/etc/pam.d/sshd:34:session    optional     pam_motd.so noupdate

Ok on a login shell (/etc/pam.d/login) it makes sense, but on ssh I'd
expect (just like the reporter) to be only shown if interactive.

At least that is a great place to disable this manually if needed,
but sadly disabling this in only /etc/pam.d/sshd also removes it for an ssh-based login shells.
So an ssh based login shell will not be configured by /etc/pam.d/login :-/
Pam is trying to outsmart us ... :-/

After all [1] says "... which  is  displayed  by  the pam_motd(8) module
on interactive shell logins." which should, but isn't true.


One can debate if it is good or not in the first place to log in for every command as there will be a lot more every time (e.g. audit entries, syslog entries, the env being spawned, ...), overall this is only one of the things that makes this conceptually wrong.

But still I find it embarrassing to see this trivial test to be so bad:

$ time for i in $(seq 1 100); do ssh -i /tmp/id-rsa-test
testuser1 at 10.253.194.246 "ls ~"; done

- With pam_motd.so enabled in /etc/pam.d/sshd => 0m59,709s
- With pam_motd.so disabled in /etc/pam.d/sshd => 16,159s

On any cloud or hipervisor that scales a lot not only the expired time
but also the cycles will add up to quite a lot. So either way it comes
to slowdown as well as unnecessary price or power consumption

I'm tempted to suggest a discussion to disable it in /etc/pam.d/sshd
unless we find a way to make it only happen on interactive logins.

P.S. I have the feeling we had this discussion, maybe others will
remember better - I need to talk to a few people ...

[1]: http://manpages.ubuntu.com/manpages/bionic/man5/update-motd.5.html

** Tags added: server-todo

** Changed in: update-motd (Ubuntu)
   Importance: Wishlist => High

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to update-motd in Ubuntu.
https://bugs.launchpad.net/bugs/1893716

Title:
  scripts in /etc/update-motd.d/ run even on login via non-interactive
  scp and sftp sessions

Status in update-motd package in Ubuntu:
  Triaged

Bug description:
  My client has 200+ devices automatically uploading information via
  sftp and scp to a server every few minutes. After a recent update, I
  noticed the load on their server spiking through the roof. Upon
  investigation, I discovered a horde of landscape-sysinfo and
  /usr/bin/lsb_release processes running that correlated with login
  session notifications in /var/log/syslog and the load spikes.

  It appears that even in non-interactive sessions where this
  information will never be seen, the configuration options below in
  /etc/pam.d/sshd cause these items to be launched (in fact, probably
  everything in /etc/update-motd.d). This only started on the system in
  question after a recent set of system updates were installed.

  The content of /etc/update-motd.d/* really, really, really shouldn't
  be executed if the session in question is not interactive, as it
  provides no value at all. Unfortunately, to disable it for these non-
  interactive sessions, we also have to disable it for the interactive
  ones as well where it has some value (though not enough to make
  spiking the load on this server through the roof an acceptable
  tradeoff).

  # Print the message of the day upon successful login.
  # This includes a dynamically generated part from /run/motd.dynamic
  # and a static (admin-editable) part from /etc/motd.
  #session    optional     pam_motd.so  motd=/run/motd.dynamic
  #session    optional     pam_motd.so noupdate

  Also, looking at the script 00-header in /etc/update-motd.d/,
  /usr/bin/lsb_release is being improperly launched, as /etc/lsb_release
  does include the necessary information:

  [ -r /etc/lsb-release ] && . /etc/lsb-release

  if [ -z "$DISTRIB_DESCRIPTION" ] && [ -x /usr/bin/lsb_release ]; then
          # Fall back to using the very slow lsb_release utility
          DISTRIB_DESCRIPTION=$(lsb_release -s -d)
  fi

  # cat /etc/lsb-release
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=16.04
  DISTRIB_CODENAME=xenial
  DISTRIB_DESCRIPTION="Ubuntu 16.04.7 LTS"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/update-motd/+bug/1893716/+subscriptions