ssh logins doesn't show the MOTD when connecting with public key authorisation

[Laryllan]

This is merely a minor annoyance, but nonetheless worth a bug report for the servers papercut team:

The method to display a MOTD described in the official Ubuntu server guide, chapter 22 (https://help.ubuntu.com/9.10/serverguide/C/update-motd.html) doesn't work as soon as you connect with public key authorisation.

Connecting /w password only shows the MOTD correctly.

[Chuck Short (zulcss)]

Im not able to reproduce this which version are you using?

Regards
chuck

[Laryllan (laryllan)]

I'm using:
openssh-server 1:5.1p1-6ubuntu2

Running Ubuntu 9.10.
At this time, I don't have any server running Lucid available.
Both openssh-clients on Karmic an Lucid have the same problem, which should be normal cause the client doesn't generate the MOTD I guess...

[Thierry Carrez (ttx)]

Can't reproduce either with a basic publickey karmic setup, running the same version (1:5.1p1-6ubuntu2). Something else in your configuration must prevent it from being shown...

[Dustin Kirkland  (kirkland)]

ls -alF $HOME/.hushlogin

Is that file present?

[Laryllan (laryllan)]

Nope. It isn't present on both servers - not on the one showing the MOTD nor the one not showing the MOTD.

[Dustin Kirkland  (kirkland)]

And what's the output of:

ls -alF /var/run/motd /etc/motd /etc/update-motd.d

[Thierry Carrez (ttx)]

The strange thing being, you get the MOTD when doing password authentication, but you don't get it when you do publickey authentication. Can you still reproduce that, and if yes, could you attach your /etc/ssh/sshd_config ?

[Laryllan (laryllan)]

@Dustin:

From the server showing the MOTD, I get the following output:
lrwxrwxrwx 1 root root 13 2009-05-09 18:58 /etc/motd -> /var/run/motd
-rw-r--r-- 1 root root 168 2010-03-31 19:07 /var/run/motd

/etc/update-motd.d:
total 12
drwxr-xr-x 2 root root 4096 2009-11-10 06:36 ./
drwxr-xr-x 94 root root 4096 2010-03-31 06:39 ../
-rwxr-xr-x 1 root root 149 2009-07-14 03:25 00-header*
lrwxrwxrwx 1 root root 54 2009-11-07 14:14 90-updates-available -> /usr/lib/update-notifier/update-motd-updates-available*
lrwxrwxrwx 1 root root 41 2009-11-10 06:36 91-release_upgrade -> /usr/lib/update-manager/check-new-release*
lrwxrwxrwx 1 root root 52 2009-11-07 14:14 99-reboot-required -> /usr/lib/update-notifier/update-motd-reboot-required*

From the server _not_ showing the MOTD (public key) the output looks like this:
ls -alF /var/run/motd /etc/motd /etc/update-motd.d
lrwxrwxrwx 1 root root 13 2010-02-13 18:51 /etc/motd -> /var/run/motd
-rw-rw-rw- 1 root root 161 2010-03-17 06:56 /var/run/motd

/etc/update-motd.d:
insgesamt 12
drwxr-xr-x 2 root root 4096 2010-03-23 06:35 ./
drwxr-xr-x 111 root root 4096 2010-03-31 06:52 ../
-rwxr-xr-x 1 root root 149 2009-07-14 03:25 00-header*
lrwxrwxrwx 1 root root 46 2010-03-23 06:35 50-landscape-sysinfo -> /usr/share/landscape/landscape-sysinfo.wrapper*
lrwxrwxrwx 1 root root 54 2010-02-13 19:00 90-updates-available -> /usr/lib/update-notifier/update-motd-updates-available*
lrwxrwxrwx 1 root root 41 2010-02-13 19:35 91-release_upgrade -> /usr/lib/update-manager/check-new-release*
lrwxrwxrwx 1 root root 52 2010-02-13 19:00 99-reboot-required -> /usr/lib/update-notifier/update-motd-reboot-required*

[Laryllan (laryllan)]

@Thierry:

I will try to reproduce the behaviour in the next days, when I'll have access to the server.
Right now I'm not eager to lock me out by mistake...

[karloskar (karloskarmattsson)]

This might be way off but if I remember this correctly it has something to do with with the "UsePAM" setting in sshd_config.

[Thierry Carrez (ttx)]

@Laryllan:
Could you attach your /etc/ssh/sshd_config file, or tell us if you set UsePAM ?

[Laryllan (laryllan)]

Sure, here it is: I don't use PAM.

# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM no

[Thierry Carrez (ttx)]

The MOTD is generated through PAM, so the fact that you have "UsePAM no" probably affects your results. In the same vein, you have "PrintMotd no"... Having the combination of the 2 parameters probably prevents the motd from being displayed in certain cases.

I'd suggest trying
UsePAM yes
Or
PrintMotd yes

and report what happens.

[Laryllan (laryllan)]

Selecting 'PrintMotd yes' has no effect, I tried that already.

Choosing 'UsePAM yes' shows the Motd.

But: I don't want to allow logins using a simple password, but want to make sure the exchange of keys is used.
Can you (or anybody else) confirm that every user _has_ to have the key?

[Thierry Carrez (ttx)]

If you use:
PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes

then SSH will only allow public-key auth. The server has the public key in authorized_keys, you need to have the corresponding private key.

[Launchpad Janitor (janitor)]

[Expired for openssh (Ubuntu) because there has been no activity for 60 days.]

[Dan Dascalescu (ddascalescu+launchpad)]

Same here, on Ubuntu 14.04:

* Selecting 'PrintMotd yes' has no effect if UsePAM is no.

Choosing 'UsePAM yes' shows the Motd.

IMO, this is is a bug. The MOTD should be controlled solely by PrintMotd. Is there a rationale behind hiding the MOTD if the user logs in with a public key?

[Antoni Baranski (sauraus)]

I am also curious to understand why MOTD is being controlled by UsePAM Yes and not just PrintMotd.

[Avamander (avamander)]

I was struggling so long to figure out why I was shown no MOTD. Now I know. I was told disabling PAM makes ssh more secure but does that apply to key based auth?

[Marslo (imarslo)]

I encounter this issue also, MOTD not show when UsePAM no in sshd_config

My environment:
- OS: Ubuntu 16.04.1 LTS
- uname -a: Linux Jenkins 4.4.0-57-generic #78-Ubuntu SMP Fri Dec 9 23:50:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
- openssh-client: 7.2p2-4ubuntu2.1, amd64

[Nish Aravamudan (nacc)]

I'm sort of confused by the bug report.

Here are the relevant snippets from the man-pages:

          UsePAM Enables the Pluggable Authentication Module interface. If set to
             ``yes'' this will enable PAM authentication using
             ChallengeResponseAuthentication and PasswordAuthentication in
             addition to PAM account and session module processing for all
             authentication types.

             Because PAM challenge-response authentication usually serves an
             equivalent role to password authentication, you should disable
             either PasswordAuthentication or ChallengeResponseAuthentication.

             If UsePAM is enabled, you will not be able to run sshd(8) as a
             non-root user. The default is ``no'

...

     PrintMotd
             Specifies whether sshd(8) should print /etc/motd when a user logs
             in interactively. (On some systems it is also printed by the
             shell, /etc/profile, or equivalent.) The default is ``yes''

...

PrintMotd *only* is documented as controlling interactive logins. I believe all affected users so far have indicated (if at all) they are using key-based authentication, which is unaffected by PrintMotd's setting either way.

UsePAM, on the other hand, displays the MOTD because /etc/pam.d/sshd contains (on 16.04, at least) by default:

# 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

and PAM is managing the ssh login session when so configured for sshd.

At this point, I think it's not a bug, and I'm marking it as invalid. Please reopen as new with justification if you feel this is incorrect.