Linux登录与重启记录查询：从last到journalctl的运维实战

做了这么多年 Linux 运维，我几乎每周都要翻几遍登录和重启记录。不管是排查服务器异常重启、追踪某台机器到底被谁登过，还是纯粹想确认自己凌晨发的维护工单有没有生效，手里有没有一套趁手的查询指令，差别非常大。网上搜“Linux 查看登录记录”会出来一堆碎片话术，但很少有人把用户登录、注销、系统重启、关机这几类历史记录一次性讲透。这篇就围绕这几个场景，把最核心的指令、日志文件、参数和踩坑点全部梳理一遍，属于那种可以直接贴在运维笔记里的实操型内容。

先说适用范围：如果你管着若干台 Linux 服务器，或者你只是在自己电脑上想搞清楚系统最近发生了什么，这篇文章都合适。不需要太深的内核知识，但要有一颗“日志是运维第一生命力”的心。文中所用命令基于常见发行版（RHEL/CentOS/Rocky、Ubuntu/Debian 都测过），systemd 体系的会单独标注。

1. Linux 记录登录和关机信息的底层机制

很多人第一步就走错了：想在日志里查登录记录，却拿 cat 去读/var/log/wtmp，发现全是乱码。原因很简单，Linux 里这类会话和系统运行状态信息，默认存储在三个二进制文件中，它们不是普通文本日志，设计初衷就是给专用工具读取和高效写入的。

这三个文件分别是：

• /var/log/wtmp：记录所有成功登录、注销、系统启动、关机、运行级别变化等会话级事件。
• /var/log/btmp：记录所有失败的登录尝试。
• /var/log/lastlog：记录每个用户最近一次成功登录的时间。

它们通常是二进制的 utmp 格式存储，所以直接 cat、tail、grep 都毫无意义，必须依靠专门的命令去解析，比如本次主题的主角last、lastb、lastlog，或者底层一点的utmpdump。

为什么会设计成二进制而不是纯文本？很大程度是性能和统一接口的考虑。登录、登出、重启这类动作非常频繁，每条记录的结构是固定的（用户名、终端、来源、时间戳等字段），用定长或长度前缀的结构化记录，写入效率高，也方便程序逐条读取和统计。相比纯文本日志，结构化数据在解析时不用做大量字符串匹配。同时 utmp/wtmp 是 POSIX 体系里很老的设计，今天大多数 Linux 命令（who、w、last）都直接依赖这套接口，这样保证整个系统的用户会话信息格式统一，不会今天一个样明天一个样。

这里有个很多人没意识到的问题：last看到的登录记录，和 SSH 服务自己的认证日志（比如/var/log/secure或/var/log/auth.log）并不是同一个东西。last读的是 wtmp，只记录“登录成功、建立会话、注销”这种粗粒度事件；而 SSH 认证日志会记载更细的过程，例如公钥指纹、认证方式、具体报错信息等。两者可以互补，查安全事件时最好都翻一遍。

另外一个重点是 systemd 时代的变化。现代发行版基本都跑 systemd，journald会额外记录系统启动和关机的详细事件，包括内核日志、systemd 单元状态、以及服务停止时的报文。这意味着除了传统 wtmp，我们还有第二套数据源，也就是journalctl。具体在后面的重启和关机定位部分会重点展开。

2. 查用户登录与注销：从 last 到 lastlog 的完整武器库

2.1 last 指令：一切登录与注销查询的核心

last是查询成功登录记录的最常用命令，它默认读取/var/log/wtmp，按时间倒序输出登录、注销、重启和关机记录。用法很简单，直接敲last就能看到：

root@server:~# last user1 pts/1 192.168.1.100 Mon Jan 20 10:30 still logged in user2 pts/0 192.168.1.50 Mon Jan 20 09:15 - 10:20 (01:05) reboot system boot 5.15.0-91-generic Mon Jan 20 08:00 still running

每一列的意思依次是：用户名、登录终端（pts 表示远程伪终端，tty1 通常表示本地控制台）、来源主机名或 IP、登录时间、注销时间和登录时长。如果显示still logged in，说明该会话当前还挂着。

真正要高效使用last，光敲默认命令不够，下面这些参数是高频场景必备的：

• -a：把来源主机名/IP 显示在最后一列，当终端宽度不够导致折行时能极大提升可读性。
• -n 数量：只看最近 N 条记录，比如last -n 20。
• -x：显示系统关机、重启、运行级别变化等记录，这是查重启关机历史的关键参数，后面单独讲。
• -F：显示完整时间戳，不只是日期和时分，还会带上秒和时区，适合精确定位。
• -i：将来源主机名转换为 IP 地址显示，对查来源非常有用，免去手动 DNS 解析。
• -s 时间、-t 时间：指定查询起始和结束时间，格式类似20250120或2025-01-20 10:00:00，适合范围筛选。
• -f 文件：指定读取其他 wtmp 文件，例如读取轮转后的/var/log/wtmp.1。这个参数极其实用，因为默认的 wtmp 可能只有最近一小段时间的记录。

实战中查某个具体用户，直接加用户名即可：

last user1 last user1 -n 10 -F -i

上面第一条是查该用户最近的登录记录，第二条进一步限制为最近 10 条，显示完整时间，并把来源转成 IP，非常适合作审计输出。

2.2 lastb：查看失败登录的黑名单级记录

有成功登录，就有大规模爆破尝试。lastb读的是/var/log/btmp，专门记录登录失败的尝试。它的参数和last基本一致：

lastb -n 20 lastb user1 -i

注意：查看 btmp 日志需要 root 权限，这本身就是一个安全设计，避免普通用户轻易看到其他人的暴力破解痕迹。实际生产环境中，lastb几乎是我检查服务器是否被恶意扫描的第一道哨兵，如果看到某个 IP 反复尝试 root 登录，基本可以确认有人在爆破。这时候我会接着用last查同一 IP 有没有登录成功，做好安全分析闭环。

lastb有个小坑：记录里会出现:0、tty1这类本地终端，不全是远程 SSH 的失败尝试，别一看到就慌。

2.3 lastlog：快速定位每个用户最近登录时间

lastlog读取/var/log/lastlog，输出系统里每位用户的最近一次登录时间。它的作用不在于看登录历史，而在于快速判断哪些账号长时间没人用过。运维巡检时，lastlog经常会列出一大堆系统账号，它们的最近登录时间显示**Never logged in**，这是正常的；重点关注的是那些普通用户账号，如果某人的最近登录时间停在了几个月前，就需要考虑账号是否还在使用，甚至是否有安全风险。

lastlog -u user1可以查单个用户，lastlog -t 30可以查最近 30 天内有登录过的用户。后者适合做定期活跃度盘点。

2.4 utmpdump：直接解析二进制日志的底牌

如果有一天last命令因为某种原因用不了，或者你想看更原始的记录内容，可以试试utmpdump。它能把 wtmp、btmp、utmp 等二进制文件按字段结构 dump 出来。例如：

utmpdump /var/log/wtmp

输出会比较“生猛”，每个字段用方括号包裹，看起来不如last友好，但它能展示一些last不会显示的细节，比如进程号 PID、会话 ID 等。在排查一些极端情况时（例如怀疑某条记录被删除），它很有用。不过平时以last为主就够了。

2.5 当前在线用户指令：who、w、users

看历史记录之前，先看清当下的状态。who、w、users三个命令都是查在线用户的，但它们侧重不同：

• who：显示当前登录的用户、终端、登录时间和来源，相当于“当前版 last 摘要”。
• w：在 who 的基础上增加了 CPU 使用率、空闲时间、当前执行的命令，信息维度更丰富。
• users：只输出用户名，适合脚本里快速判断有哪些用户在线。
• who -b：显示系统上次启动时间。
• who -r：显示当前运行级别。

实际排查时我一般先w看有没有可疑用户挂着，再看last看历史连接。两者结合比单独用任何一个都靠谱。

3. 重启与关机历史：三个层面交叉定位

查登录记录大家基本知道用last，但查“系统哪天重启过、哪天关机过”很多人就卡住了。其实重启和关机在 wtmp 里本来就是特殊的“用户记录”，用户名位置会显示reboot或shutdown。只要会用对参数，查起来并不难。

3.1 用 last -x 精确定位重启与关机时间点

看系统重启和关机记录的第一选择：

last -x | head -30

命令会显示出reboot system boot、shutdown、runlevel等特殊记录。reboot system boot后面的时间就是这台机器内核启动的时间点，也就是开机时间；shutdown对应的是关机时间点。举个例子：

reboot system boot 5.15.0-91-generic Mon Jan 20 08:00 still running shutdown system down 5.15.0-91-generic Mon Jan 20 07:55 - 08:00 (00:05)

这组输出非常直观：机器在 07:55 关机，在 08:00 重新启动，总共关机约 5 分钟。如果只关心最近一次：

last -x -n 1 reboot last -x -n 1 shutdown

这两条分别给出最近一次重启和关机时间，写脚本做定时检测都够用。要注意的是，last -x显示的runlevel记录通常与 reboot 记录成对出现，表示 init 运行级别切换，关心详细变化时也能参考。

3.2 journalctl 视角：从 systemd 日志审视开关机周期

systemd 体系里journalctl掌握了非常详细的启动与关闭过程。最实用的一个参数是：

journalctl --list-boots

它会列出本机每一次启动的序号（负数表示过去的第几次启动）、启动时间、日志时间范围。例如：

-2 45a1f1a... Mon 2025-01-20 07:55:12 CST—Mon 2025-01-20 08:00:03 CST -1 b9c9d6a... Mon 2025-01-20 08:00:05 CST—Mon 2025-01-20 12:30:10 CST 0 3e4f19a... Mon 2025-01-20 18:20:11 CST—Mon 2025-01-20 18:35:22 CST

序号 0 是当前这次启动，-1 是上一次，-2 是上上次。如果要看上一次启动的完整日志，可以：

journalctl -b -1

只看错误级别的日志：

journalctl -p err -b -1

这个能力是传统 last 给不了的，因为 wtmp 只记录了启动和关机的时间点，而 journald 还能告诉你那次启动过程中有没有服务挂掉、内核有没有 panic、有没有 OOM。排查异常重启时，我通常先用last -x确定时间点，再用journalctl -b -1 -p err看那一次启动有没有异常报错，两条命令配合，整个重启原因基本就拼出来了。

3.3 区分正常关机和异常断电：细节里的魔鬼

很多时候，用户关心的问题不是“什么时候重启”，而是“那次重启是正常计划内，还是突然断电”。这类判断不能单靠时间点，要综合几条消息：

• 正常关机前，systemd 会有一段优雅停机过程，日志里会出现Stopping Session、Stopping User Manager、Reached target Shutdown等记录。异常断电则不会有这些，日志通常突然中断。
• 重启后如果看到内核报“filesystem has been modified”或“recovering journal”，往往说明上次关机不是干净退出，文件系统做了恢复。
• 用last -x看时长也会有端倪：如果两次启动时间相差非常短，说明可能只是 reboot；如果间隔很久，中间还有 shutdown 记录，说明是一次完整关机流程。

再配合硬件层信息，比如journalctl -k -b -1 | grep -i "watchdog\|thermal"，能进一步判断是否因为温度过高或看门狗触发了重启。这类问题原因排查是一整个专题，本文先把“如何看历史”讲透，具体原因定位以后可以单独写一篇。

3.4 长期开关机统计：uptime、who -b 以及日志轮转的边界

如果只是想快速知道系统已经运行多久，uptime就够了：

uptime

输出中的up 3 days, 2:10就是连续运行时间。who -b则直接显示系统本次启动时间。这些适合快速了解当前状态，但不适合做历史分析，因为一旦重启它们就重置了。

真要拉出过去几个月甚至一年的重启记录，就得靠日志轮转后的旧 wtmp 文件。发行版默认会用 logrotate 按周或按月轮转 wtmp，比如/var/log/wtmp.1、/var/log/wtmp.1.gz。查询时可以用last -f指定文件，例如：

last -x -f /var/log/wtmp.1

也可以多个文件一起看，先last -x，再last -x -f /var/log/wtmp.1，把两个结果拼在一起，就能拼出更长的历史。唯一的限制是轮转策略和保留周期，默认情况下 wtmp 可能只保留 4 周左右，如果需要保留更久必须提前调整 logrotate 配置。

ac命令值得一提，它来自psacct或acct包，可以统计用户的连接时间。比如ac -d按天统计所有用户的登录时长，适合做简单的资源使用审计。不过它对系统重启关机的记录维度不如 last 直接，这里点到为止。

4. 实战：一次完整的安全登录审计过程

理论讲得再多，不如完整跑一遍。下面这个场景来自我日常排查“某台服务器被人频繁爆破”的真实流程，读者可以直接照搬到自己的机器上。

4.1 第一步：用 lastb 确认是否存在失败登录和来源 IP

当收到登录异常告警时，我的习惯是先看失败登录：

lastb -n 30 -i

输出会逐条显示失败的账号、终端、来源 IP 和时间：

root ssh:notty 103.88.46.210 Mon Jan 20 03:12 - 03:12 (00:00) root ssh:notty 185.220.101.34 Mon Jan 20 03:11 - 03:11 (00:00) admin ssh:notty 90.156.212.10 Mon Jan 20 03:10 - 03:10 (00:00)

如果发现同一 IP 反复刷屏，十有八九是扫描器或暴力破解程序。注意lastb输出中ssh:notty表示通过 SSH 尝试登录但没有分配终端，这种通常是 sshd 在认证阶段推送过来的测试，也可能是真实的密码破解尝试。

4.2 第二步：查同一 IP 是否有成功登录

失败只是前菜，更关键的是确认这些 IP 有没有成功突破防线：

last -i | grep "103.88.46.210"

如果没有任何输出，说明这个 IP 最多只是尝试，没有成功。如果出现了登录记录，就已经是安全事故级别了，需要立即处理。这条命令的设计思路就是“失败记录确认攻击存在，成功记录确认攻击效果”，两步闭环。

4.3 第三步：检查指定用户的近期会话和在线状态

如果攻击者猜中了某个低权限账号，需要看该账号所有会话：

last user1 -F -i -n 20

-F参数在这里很重要，它会把登录和注销时间精确到秒，方便和告警时间比对。如果该用户 “still logged in”，马上执行：

w

查看它当前正在运行的命令，判断是不是已经挂载了可疑进程。

4.4 第四步：把开关机记录纳入完整时间线

安全审计不只是看账号，系统异常重启也可能是攻击者的行为，比如提权后强制重启以加载恶意内核模块。所以顺手把重启和关机记录拉出来：

last -x -F

再配合：

journalctl --list-boots --no-pager | tail -20

这样你能把攻击时间点和系统重启时间点做交叉对比。我见过不少案例，攻击者登录后明明没做什么，但服务器半小时后重启了，单独看登录日志找不到问题，一对照 journalctl 才发现是内核 panic 导致的自动重启。

4.5 第五步：延伸检查 SSH 认证细节日志

last和lastb看不到 SSH 握手过程的细节。想看到类似“哪个密钥登录的”“是否用键盘交互”“失败原因是什么”，需要查 sshd 日志：

• RedHat 系：/var/log/secure
• Debian/Ubuntu 系：/var/log/auth.log

例如：

grep "sshd.*Failed password" /var/log/auth.log | tail -20 grep "sshd.*Accepted publickey" /var/log/auth.log | tail -20

这两条能帮你聚焦“成功登录的方式”和“失败最多的账号”。如果发现登录方式是Accepted password而不是publickey，建议后续加固为密钥登录。安全审计有一定深度以后，可以把这几个命令组合成一个小脚本，每次巡检自动生成登录审计报告。但要记住，日志记录可能本身就不完整（或者说存在被篡改的可能性，毕竟有 root 权限的话删/var/log/wtmp*也不难），所以任何日志数据都应视为证据链的一部分，而非全部事实。

5. 常见问题与排查技巧实录

做运维久了，解决过的问题多了，反而觉得“命令记不全”不是大问题，真正坑人的是那些看起来正常实际有坑的细节。下面这些是我日常使用里踩过频率最高的坑。

5.1 日志轮转导致历史记录“消失”的真正原因

很多用户跑last只能看到最近几周记录，第一反应是系统出问题了。其实是因为 wtmp 是按周期轮转的。以 Ubuntu 为例，logrotate 默认每周轮转一次 wtmp，保留 4 个归档文件。也就是说，超过 4 周的记录会被清理掉，这不是故障，而是策略。要调整，可以修改/etc/logrotate.d/wtmp里的轮转周期和保留份数。

排查时如果发现历史记录缺失，不要盲目判定被入侵，先看看/var/log/下有哪几个 wtmp 归档：

ls -lh /var/log/wtmp*

然后用last -f /var/log/wtmp.1读取旧文件，就能接上历史时间线。这招在排查“三个月前到底有没有重启过”时特别有用。

5.2 时区显示一切正常，但时间确实差了几个小时

last的时间显示默认跟随系统时区。一旦服务器时区配置混乱，比如容器镜像、云服务器初始时区用的 UTC，而浏览器或你的办公环境是北京时间，就会看到相差 8 小时的记录。千万不能忽略这个因素。确认系统时区：

timedatectl

如果时区确实不对，可以用timedatectl set-timezone Asia/Shanghai修正。但注意，时区设置变化不会自动改历史日志里存的时间戳，因为 wtmp 记录的本质是 Unix 时间戳，显示出来的差异只是解析时用的时区不同。换句话说，UTC 下用 last 看到 02:00，在北京时区下会显示 10:00，它们是同一个时刻。做时间比对时，建议所有主机统一时区，防止人工阅读时的混淆。

5.3 btmp 和 wtmp 的访问权限：普通用户看不到失败记录

有的新手在普通用户下执行lastb会报 Permission denied，这不是命令不存在，而是文件权限限制。看一下：

ls -l /var/log/wtmp /var/log/btmp /var/log/lastlog

默认情况下，这些文件通常属于utmp组或仅 root 可读。日常巡检用普通用户的操作习惯，在碰到需要读取 btmp 时，要么 sudo，要么把用户加入utmp组。安全起见，btmp 不要放开读权限给所有人，因为它记录的是失败尝试，里面可能包含大量尝试过的账号名，泄露给普通用户等于变相提供了信息。

5.4 “上次关机”总是查不到问题的排查思路

偶尔会有用户问：我明明关过机，为什么last shutdown没记录？通常原因有三类。

第一类，日志轮转清掉了。第二类，非正常断电，系统来不及写 wtmp 记录，这种情况下关机会缺失，但下一次开机会有 reboot 记录。第三类，虚拟机快照回滚，整个 wtmp 被回退到历史状态，看起来所有记录都“丢失”，实际上是被快照覆盖了。遇到这种情况，我的建议是结合 journald 时间线判断，如果journalctl --list-boots能列出多次启动，说明只是 wtmp 丢了，系统日志还在；如果 journald 也丢了，那基本可以确认是快照回滚或者有人主动清理了。

5.5 记录被清空/被篡改后，运维能做和不能做的事情

必须承认一个现实：任何有 root 权限的人都可以清空 wtmp、btmp、lastlog，甚至 journald 的日志目录/var/log/journal/。这意味着在纯本机视角下，日志证据的完整性是无法绝对保证的。安全要求高的环境通常会将日志实时转发到独立的日志服务器，或者至少使用只读挂载、远程 syslog 等方式保存副本。这也是运维层面比较推荐的兜底方案，哪怕本机日志被清理，异地还有一份原始记录。

5.6 排查技巧速查表

下面这个表是我贴在笔记本里的高频查询速查，基本覆盖日常 80% 的需求。

6. 操作过程中的体会

最后说点个人经验。刚接触这些命令时，我也犯过只记用法、不记原理的毛病，导致碰到异常情况就抓瞎。后来慢慢养成一个习惯：查任何历史记录，先问自己“这条数据写在哪里、由谁写入、轮转策略是什么”，只有把数据来源搞清楚，命令参数才真正背得住。

另外，timeline 思维非常重要。登录记录、失败记录、重启记录、认证日志这四类信息，单独看也许都“正常”，拼成一条完整的时间线才能发现真正的异常。比如同一个 IP 在登录失败 100 次后突然成功，然后 3 分钟后系统重启，单看 lastb 只能说明有暴力破解，但结合 last 和 journalctl 就能拼出一个完整的入侵场景。所以我建议运维同学自己搭一个脚本，把 last、lastb、journalctl --list-boots 的结果定期汇总成报表，形成常态化审计机制，这样某一天真出问题时，手里已经有一份完整的时间线，排查效率会高非常多。