How to disable ‘Last Login’ welcome message in Linux

For one user, touch ~/.hushlogin and you are done. For the whole machine, never edit sshd_config and restart in one motion — validate first, because a rejected config means sshd does not come back and you cannot open a new session:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config          # set: PrintLastLog no
sudo sshd -t                            # MUST print nothing and exit 0
sudo sshd -T | grep -i printlastlog     # confirm the effective value
sudo systemctl restart ssh              # 'ssh' on Debian/Ubuntu, 'sshd' on RHEL/Fedora

Keep your current SSH session open while you do this, and prove a new login works from a second terminal before you close it. The sshd -t, sshd -T and ~/.hushlogin results below were executed here against OpenSSH 10.3p1 on macOS 26.6, using a scratch sshd on 127.0.0.1:22022 — not the system daemon, and no system file was modified. Re-running them leaves the system daemon and /etc/ssh alone: a script that starts its own sshd on that port with a throwaway host key repeats the checks and removes any ~/.hushlogin it creates. The PAM behaviour is Linux-specific and is cited, not run.

Validate the config before restarting sshd

Editing sshd_config, saving, then running sudo systemctl restart sshd with no validation in between is how people lock themselves out of remote machines. sshd -t catches the mistakes that matter. A misspelled directive — easy to type, since the option is not called PrintLastLogin:

$ sshd -t -f typo.conf
typo.conf: line 3: Bad configuration option: PrintLastLogin
typo.conf: terminating, 1 bad configuration options
rc=255

A valid directive with an invalid value:

$ sshd -t -f typo2.conf
typo2.conf line 3: unsupported option "nope".
rc=255

And a good file, which is silent:

$ sshd -t -f good.conf
rc=0

Either failure would have stopped sshd from starting after a restart. Existing connections are not the risk; new ones are, which is exactly the sort of lockout you only notice after you have hung up.

The service is not called sshd on Debian and Ubuntu

sudo systemctl restart sshd is not universal. Debian’s canonical unit for OpenSSH is ssh.service; current packages also ship sshd.service as a compatibility alias, so that command happens to work on recent releases and fails on older ones. Ask the machine rather than guessing:

systemctl list-unit-files | grep -E '^(ssh|sshd)\.service'

On RHEL, Fedora and their derivatives the unit genuinely is sshd.service. Use systemctl reload where you only changed configuration — it re-reads without tearing the listener down.

PrintLastLog no often does nothing, and PAM is why

sshd_config(5) defines the option narrowly: “Specifies whether sshd(8) should print the date and time of the last user login when a user logs in interactively”, default yes. The word doing the work is sshd. With UsePAM yes — the default on every mainstream Linux distribution — the PAM session stack runs too, and historically pam_lastlog.so in /etc/pam.d/sshd printed its own last-login line. PrintLastLog no has no authority over that module, which is why it so often appears to do nothing.

With PAM out of the picture, the directive works exactly as documented. Against the scratch daemon with UsePAM no and PrintLastLog yes, a real interactive session over SSH:

Last login: Tue Aug 11 10:54:18 2026

Flip one line to PrintLastLog no, and the effective config and the session agree:

$ sshd -T -f sshd_off.conf | grep printlastlog
printlastlog no

'Last login' lines in the session: 0

So on a Linux box where PrintLastLog no did not silence the message, the source is the PAM stack, and grep lastlog /etc/pam.d/sshd will show it. That was also a moving target in August 2026: pam_lastlog was deprecated because utmp, wtmp, btmp and lastlog are not Y2038-safe, and it was being replaced by pam_lastlog2. Fedora’s change proposal is explicit — “Migrate lastlog and all functionality associated with it (e.g. pam_lastlog, the PAM service files) to lastlog2”, targeting Fedora Linux 43 — and Ubuntu has removed pam_lastlog.so from its login PAM configuration. On those releases the module you are looking for may be pam_lastlog2.so, or simply absent, in which case sshd was printing the line all along and PrintLastLog no is sufficient.

Edit a PAM stack only with a second session open. A broken /etc/pam.d file can deny every login, including root’s, and it is not covered by sshd -t.

~/.hushlogin, verified

The per-user file needs no privileges, no daemon restart and no PAM archaeology, and it is the option to reach for first. login(1) documents it: “If the file .hushlogin exists in the user’s home directory, all of these messages are suppressed.” Two otherwise identical interactive SSH logins to the same scratch daemon, PrintLastLog yes both times, differing only in whether the file exists:

without ~/.hushlogin:
Last login: Tue Aug 11 10:54:18 2026
The default interactive shell is now zsh.

with ~/.hushlogin:
The default interactive shell is now zsh.

The last-login line is gone and nothing else changed. The file’s contents are irrelevant — only its existence is checked — and rm ~/.hushlogin restores the message. Note that this half was demonstrated on macOS, where sshd itself emits the line; on a Linux host whose message comes from PAM you may find .hushlogin is honoured by pam_lastlog‘s successor but not by every stack, so confirm with a second login rather than assuming.

What you give up

The last-login line is a free intrusion signal: a timestamp you do not recognise is often the first evidence of a compromised account. If you suppress it, replace it with something. last -n 10 "$USER" reads the same data on demand, and /var/log/auth.log (Debian) or /var/log/secure (RHEL) holds the full record.