谁登录了机器：登录日志

在哪里查看成功和失败的登录、如何阅读 last、lastb 和 journalctl、如何通过 sudo 追踪操作，以及如何配置日志保留。

更新于 2026年8月23日

每次登录机器都会留下痕迹。能在五分钟内读懂这些痕迹，正是从容的事件复盘与凭空猜测之间的区别。

快速概览

last -a -n 20
lastb -a -n 20
lastlog
who
w

last 显示成功登录及其地址，lastb 显示失败尝试，lastlog 显示每个用户上次登录的时间。who 和 w 显示当前谁在机器上。

如果 lastlog 显示某个系统用户（如 www-data）有登录日期，那就是需要认真调查的重要理由。

systemd 日志

journalctl -u ssh -n 100
journalctl -u ssh --since "2026-08-20" --until "2026-08-21"
journalctl _COMM=sshd | grep "Accepted"
journalctl _COMM=sshd | grep "Failed password" | tail -50

关键行：

行	含义
`Accepted publickey for artem`	使用密钥成功登录
`Accepted password for root`	使用密码成功登录——值得警惕
`Failed password for invalid user admin`	暴力破解不存在的用户名，背景噪音
`Disconnected from authenticating user`	尝试被中止

在 Debian 和 Ubuntu 上，相同事件会重复记录在 /var/log/auth.log 中；在 AlmaLinux 上则记录在 /var/log/secure 中。

grep "Accepted" /var/log/auth.log
grep -c "Failed password" /var/log/auth.log

公网地址每天出现数百次失败尝试是正常的。异常的是另一回事：来自您不认识的地址的成功登录。fail2ban 有助于应对这些噪音。

登录后做了什么

journalctl -t sudo -n 100
grep sudo /var/log/auth.log
cat /home/artem/.bash_history

命令历史并不可靠：它很容易被清除，而且在非交互式会话中不会被记录。sudo 日志要诚实得多——它由系统维护，而不是由 shell 维护。这也是文章用户与 sudo 中所述的“普通用户加 sudo”方案的另一个理由。

完整的内核级审计：

apt install -y auditd
auditctl -w /etc/passwd -p wa -k passwd_changes
ausearch -k passwd_changes

存储

默认情况下，systemd 日志可能只存在于内存中，重启后就会丢失。这对事件复盘很不利。文件 /etc/systemd/journald.conf：

[Journal]
Storage=persistent
SystemMaxUse=500M
MaxRetentionSec=1month

systemctl restart systemd-journald
journalctl --disk-usage

大小限制是必须的：日志一旦吃满磁盘，服务就会停止。

常见错误

错误	后果	解决方案
日志在重启之间未保存	痕迹丢失	`Storage=persistent`
只依赖 `.bash_history`	数据容易被伪造	检查 sudo 和 auditd 日志
未限制日志大小	磁盘被占满	`SystemMaxUse`
把暴力破解噪音当成入侵	误报	关注 `Accepted`，而不是 `Failed`

如果您发现来自他人地址的成功登录，那么机器本身的日志就不能再被视为可靠：登录者可能已经修改过它们。请按照文章被入侵的迹象操作，并做好机器需要重装的准备。