[07:55] <lordievader> Good morning
[16:00] <bumblefuzz> I have a server that won't display the motd
[16:00] <bumblefuzz> and I can't figure out why
[16:01] <bumblefuzz> when I run 'cat /run/motd.dynamic' it returns no such file
[16:02] <Ussat> Things that make you go WTF, actual email I got this am:  "Could you check and see why I am not able to access bridgebox, see the attached screenshots for details. I just moved to a new office space and have a new ip address "
[16:04] <bumblefuzz> ok, so when I run 'sudo run-parts /etc/update-motd.d/' I get the motd
[16:05] <bumblefuzz> so something is keeping these scripts from running
[16:05] <bumblefuzz> any ideas?
[16:14] <sdeziel> Ussat: at least they made the connection between the IP change and the loss of access ;)
[16:22] <bumblefuzz> how can I figure out why motd isn't showing on login?
[16:25] <Ussat> True(ish)
[16:26] <sdeziel> bumblefuzz: showing motd on login is /etc/pam.d/login's job
[16:26] <sdeziel> but since you don't seem to have motd.dynamic generated, that not going to help you :/
[16:29] <bumblefuzz> so, why isn't it generating motd.dynamic?
[16:29] <sdeziel> that's what I'm trying to figure... this used to be simple but it isn't anymore
[16:32] <sdeziel> bumblefuzz: is motd-news.timer enabled for you? check with "systemctl is-enabled motd-news.timer"
[16:33] <bumblefuzz> enabled
[16:35] <sdeziel> I'd check the journalctl output of the .timer and accompanying  .service, maybe they failed
[16:41] <bumblefuzz> sorry how do I do that?
[16:48] <bumblefuzz> 'journalctl | grep motd-news.timer' shows 'succeeded' many times
[16:49] <bumblefuzz> same for journalctl | grep motd-news.service
[16:49] <bumblefuzz> no failures in either case
[17:02] <sdeziel> journalctl -b0 -u motd-news.service
[17:12] <bumblefuzz> no entries
[17:13] <sdeziel> that means it didn't run for the current boot
[17:28] <bumblefuzz> so, how do I get it to run?
[17:30] <bumblefuzz> it's enabled in /etc/default/motd-news
[17:34] <sdeziel> bumblefuzz: man update-motd says that pam_motd is the one running the scripts in /etc/update-motd.d/. I'd double check this is invoked when you log in
[17:45] <bumblefuzz> grep motd /etc/pam.d/* shows https://paste.ubuntu.com/p/fmRfztJhBT/
[17:50] <sdeziel> bumblefuzz: if you are using SSH to log in, check what sshd's UsePAM is set to
[17:54] <bumblefuzz> that's it
[17:56] <bumblefuzz> I enabled it and it worked
[17:56] <bumblefuzz> I don't understand what PAM is
[17:56] <bumblefuzz> or what enabling/disabling it at login does
[18:05] <sdeziel> bumblefuzz: oh cool!
[18:18] <bumblefuzz> I see some stuff that says it's password authentication
[18:18] <bumblefuzz> and others that it's for plugins?
[18:19] <bumblefuzz> if I'm using ssh keys wouldn't it be better to turn password authentication off?
[18:20] <sdeziel> bumblefuzz: yes, PasswordAuthentication=no is always better if it works for you
[18:21] <sdeziel> I'd say it's one of the easiest way to improve your SSH security
[18:24] <bumblefuzz> right... but what is the UsePAM field for?
[18:57] <sarnold> bumblefuzz: PAM is a pluggable authentication tool; it's what lets you swap between using local /etc/shadow vs using sssd vs using ldap and kerberos, etc
[18:58] <sarnold> bumblefuzz: openssh comes from the openbsd project; they hate the PAM idea, and just use /etc/shadow
[18:58] <sarnold> bumblefuzz: if you disable PAM in openssh, I think all you're left with is /etc/shadow support baked into openssh itself, not the PAM stack that the rest of your system is using
[18:59] <sarnold> bumblefuzz: I think if you ran openssh as a *user* account on a high-port with no ability to log in as another user, you might also need to unset the UsePAM, but I've not personally tried that one