In Ubuntu GNU/Linux 12.04, I have a user johndoe that is part of an sftponly group, set up to sftp to a chroot jail using

Subsystem sftp internal-sftp

Match Group sftponly
        ChrootDirectory %h
        ForceCommand internal-sftp
        AllowTcpForwarding no

at the end of /etc/ssh/ssh_config. All components of the user's home directory are root-owned directories that are not writeable by any other user or group, as explained in man sshd_config (under ChrootDirectory). Inside his chroot jail, there is a writeable directory files:

sudo groupadd sftponly    
sudo mkdir -p /home/sftponly/johndoe/files
sudo useradd -d /home/sftponly/johndoe -g sftponly -s /usr/sbin/nologin johndoe
sudo chmod go-w /home/sftponly/{,johndoe}
sudo chown johndoe:sftponly /home/sftponly/johndoe/files
sudo chmod ug+rwX /home/sftponly/johndoe/files

(Setting the shell to /bin/false did not work with either ssh or sftp. With nologin as the shell ssh connects, shows "MOTD", and then disconnects, which is the expected behavior.)

But sftp fails with the message Received message too long 1416128883. I know this failure is caused by "MOTD" (Message Of The Day), as sftp expects a "clean login." I have tried disabling all "MOTD" pieces on the server using the following, with (these results):

  • Adding PrintLastLog no and PrintMotd no to the end of /etc/ssh/ssh_config and restarting ssh using restart ssh. (No effect. Testing with ssh shows both "MOTD" and "Last Login:".)

  • Commenting out session optional pam_motd.so in /etc/pam.d/sshd. (Prevents MOTD. But there is no corresponding entry for "LastLog" so, testing with ssh, "Last Login:" still shows up and hence sftp still fails.)

  • Commenting out session optional pam_lastlog.so and session optional pam_motd.so in /etc/pam.d/login. (No effect. Testing with ssh shows both MOTD and "Last Login:".)

  • Creating the .hushlogin file on the client using touch ~/.hushlogin. (No effect.)

I am out of ideas. Where else may this "Last Login:" message be coming from and how can it be disabled (ideally only for sftp and not for ssh logins, but, I imagine as sftp uses ssh, the message is going to be there either for both or none)?

  • Your question still appears as an unanswered question. Post your answer and accept it (or accpt another answer) – Walter A May 23 '14 at 7:33

A typo on my part was the cause of the unreasonable behavior I was experiencing above. It is /etc/ssh/sshd_config (corresponding to the ssh daemon) that must be edited, not /etc/ssh/ssh_config (corresponding to the ssh client). I leave this question here in case it may help someone else.

|improve this answer|||||
  • I'll add to this that I had to edit the line PrintLastLog yes to no instead. I'm not sure what else this setting might change, but it doesn't print the message anymore. – taylorthurlow May 5 '18 at 18:58

I deleted /var/log/lastlog and the "Last login" message was gone forever. Worked with all distros I tested: Ubuntu and SUSE.

How did I come to this idea?

which login
strings /bin/login | grep last
|improve this answer|||||
  • But this has the unwanted side effect of making lastlog unusable on the server. – Omid Apr 20 '14 at 5:25

For filtering /etc/motd in scripts I use (this example is for program git)
git pull 2>&1 | grep -vF -f ~/bin/remote.motd | egrep -v "^$|^ $"
The file ~/bin/remote.motd is a copy-paste of the motd given by the remote system.

|improve this answer|||||

On my system it came from Pam.

/etc/pam.d/postlogin to be exact.

I got rid of the message by commenting out the existing lines and adding:

session     optional      pam_lastlog.so silent
|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.