There's not really such a thing as "an sftp login".  There's only "logins" (or more correctly, authentications), after which zero or more sessions may be established, zero or more of which may ask for the sftp subsystem.  

For normal logins, "last logged in at" messages are collected from either PAM or from within sshd itself then sent to the user at the start of their shell session.  For sftp sessions, there is no shell session.  Potentially you could send the message back in a ssh protocol banner message (which sshd does in the case of a denial by the PAM account stack) but that change would affect all sessions, not just the sftp ones.

Created attachment 2194 [details]
Always send PAM auth+account messages via banner

Here's one way you could do it: get sshd to always send the PAM account messages.  You'd need pam_lastlog.so or equivalent in the PAM config, eg:

account    required     pam_lastlog.so

however in the case of linuxpam, pam_lastlog only supports "session" .

correction: it looks like the ability to run pam_lastlog in the account stack was added recently: http://www.linux-pam.org/Linux-PAM-html/sag-pam_lastlog.html (between 1.1.5 and 1.1.6 by the look of it).

But the auth and account functionality of pam_lastlog is completely different from the session. It will lock out users that did not login on the system recently enough.

Hello,

I need to provide AT&T an update on this.  Please let me know ALU's plan to move this forward.

Comment on attachment 2194 [details]
Always send PAM auth+account messages via banner

I have no objections for sending the messages on success as well as failure.

When will this enhancement will be included in OpenSSH and in what release?  

I recommend that the Importance of this enhancement be changed from 5 to 1 because of the need to inform the sftp user of the date and time of the last valid login (authentication) and the number of consectutive login (authentication)attempts prior to the current successful one.

Updated patch to current and applied.  It's a slight improvement but I'm not sure it resolves the original report since AFAIK none of the original reporters tested it for their use case.

Not sure if this is related but I'm now seeing password expiration warnings when logging in as a user which does not have a password expiration date set.

For example:

[root@f33 test_keys]# ssh -i id_rsa user1@localhost hostname 2>&1
Warning: your password will expire in 32766 days.

This account is an LDAP user which is defined using the rfc2307bis schema.

Also, this message does not appear when logging in to a server running OpenSSH 8.3 on Fedora 32.  I have checked the sshd_config and pam.d configuration on both systems which shows no difference at all.

(In reply to Michael Watters from comment #9)
> [root@f33 test_keys]# ssh -i id_rsa user1@localhost hostname 2>&1
> Warning: your password will expire in 32766 days.

That sounds like one of the PAM stacks is returning that message, but previously not in a way sshd would send to the client. You can check this with my pam-test-harness tool:

$ wget https://www.dtucker.net/patches/pam-test-harness.c
$ cc -o pam-test-harness pam-test-harness.c -lpam
$ sudo ./pam-test-harness -s sshd -u $LOGNAME

which will give output something like:

$Id: pam-test-harness.c,v 1.35 2020/11/19 07:36:45 dtucker Exp $
conversation struct {conv=0x4017cd, appdata_ptr=0x405210}
pam_start(sshd, dtucker, &conv, &pamh) = 0 (Success)
pam_get_item(pamh, PAM_SERVICE, ...) = 0 (Success)
    PAM_SERVICE = sshd (unchanged)
pam_set_item(pamh, PAM_TTY, "/dev/pts/6") = 0 (Success)
pam_set_item(pamh, PAM_RHOST, "[...]) = 0 (Success)
getlogin returned NULL (No such device or address) , skipping PAM_RUSER
pam_authenticate(pamh, 0x0)
    conversation called with 1 messages data 0x405210
        PROMPT_ECHO_OFF: Password:  = 0 (Success)
pam_acct_mgmt(pamh, 0x0) = 0 (Success)
pam_open_session(pamh, 0x0) = 0 (Success)
pam_setcred(pamh, 0x0) = 0 (Success)
pam_get_item(pamh, PAM_SERVICE, ...) = 0 (Success)
    PAM_SERVICE = sshd (unchanged)
pam_get_item(pamh, PAM_USER, ...) = 0 (Success)
    PAM_USER = dtucker (unchanged)
pam_get_item(pamh, PAM_TTY, ...) = 0 (Success)
    PAM_TTY = /dev/pts/6 (unchanged)
Standard environment variables:
PAM environment variables:
   [...]
uid 0 euid 0 gid 0 egid 0
pam_close_session(pamh, 0) = 0 (Success)
pam_end(pamh, 0) = 0 (Success)

Does that also output the expiry warning and if so, after which pam call?

Thanks for the response.  It looks like the problem was that the user did not have a password set in our LDAP database.  I reset the password for the user and the warning message is no longer being displayed.  Previously the password contained a null value which may be causing some issues in PAM.

retarget to 8.6

retarget after 8.6p1 release

looks like the fix was committed a few releases ago.

closing bugs resolved before openssh-8.9

This fix appears to have introduced a regression:  it emits the accumulated loginmsg as a banner, but does not clear it and so later (in session.c, in do_login calling display_loginmsg) those messages are emitted again as plain session text.

It looks like the fix would be to call sshbuf_reset(loginmsg) after calling userauth_send_banner().