On Wed, May 30, 2018 at 8:52 AM Allison Karlitskaya <allison.karlitskaya@redhat.com> wrote:
hi,

Cockpit 169 (released today) contains a change to take advantage of the recently added PAM support for /etc/motd.d to display a helpful note to the admin about how to start or access cockpit.

The required PAM changes have already landed in Fedora 28.

It seems that the PAM configuration of Fedora 28 (at least in our test images here) doesn't use pam_motd at all, though.

I'd like to start a discussion about what would be appropriate here.  We want at least a message displayed when people log in to an interactive session with ssh, but it might also be useful to display a message at the virtual console, before or after login.

Thoughts?


I had a short conversation about this on IRC with Allison and Martin Pitt which I'll summarize for the wider discussion, as well as including some additional thoughts I've had while typing.

The current state on Fedora Server is that we have a specialized version of /etc/issue that will display something along the lines of:
Admin Console: https://0.0.0.0:9090/ or https://[::::]:9090/
(with the actual public IP address of the machine there)

Cockpit has recently grown the capability to generate certain files when the cockpit.socket unit is started, allowing us to have more control over what messages we want people to see. In particular, Cockpit 169 now has the ability to generate files in /etc/motd.d that will enable systems that have pam_motd.so in their PAM session stack to display the Cockpit console address after the user logs in. These generated files can also insert the machine's public hostname instead of the simple IP address we have now, which will play better with SSL Certificates.

Today, the /etc/issue implementation is only seen by people who can see a console login, either by having a keyboard and monitor attached to the machine or else via a physical or virtual serial connection. With this new pam_motd.so implementation, we will be able to inform users about the admin console who are using other login mechanisms, most notably SSH.

However, this will require modification of the default configuration on Fedora Server (at minimum) or possibly Fedora in general. Presently, no PAM stack shipped by default on Fedora includes pam_motd.so. I think that the value of having Cockpit information in the MOTD is worthwhile, so we should consider adding it to at least the SSHD PAM stack, so that users who have only remote access to the machines can still be informed of the availability of the Cockpit admin console.

Another approach would be to make it more generally available by adding it to the 'postlogin' PAM stack, which would mean that the MOTD would be seen by anyone logging in via any standard login mechanism. If we did this, we'd assuredly remove the /etc/issue implementation, as it would be redundant. The downside to this is that the default configuration for postlogin is to also run on things like `su` and `sudo -i`, so that could be noisy. We could deak with this by splitting the 'postlogin' stack into one that handled "real" logins (sshd, getty, etc.) and one that handles local privilege escalations (su, sudo, etc.). This would require coordination with the PAM maintainers in Fedora.

The middle-ground approach would be to add pam_motd.so solely to the SSHD PAM stack and then leave /etc/issue to display the console for local purposes. The Cockpit folks can chime in if I've gotten this right, but apparently there's a newer way we can generate the /etc/issue content so that it can now display the hostname as well. So we'd retire the current way we're doing it for IP addresses. The benefit to this approach is that for rack-mounted systems that probably have a common serial interface console (or just a rolling cart monitor), the user can just glance at the login prompt and see that Cockpit is available without requiring them to log in first.

I'm looking for us to come to a general consensus on how we present this information to the user. I'd appreciate any input you might be willing to provide.

Thank you for reading to the end, I know it was a long one.