做了这么多年 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 时代的变化。现代发行版基本都跑 systemdjournald会额外记录系统启动和关机的详细事件包括内核日志、systemd 单元状态、以及服务停止时的报文。这意味着除了传统 wtmp我们还有第二套数据源也就是journalctl。具体在后面的重启和关机定位部分会重点展开。2. 查用户登录与注销从 last 到 lastlog 的完整武器库2.1 last 指令一切登录与注销查询的核心last是查询成功登录记录的最常用命令它默认读取/var/log/wtmp按时间倒序输出登录、注销、重启和关机记录。用法很简单直接敲last就能看到rootserver:~# 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/secureDebian/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% 的需求。需求推荐命令备注查看成功登录/注销记录last读 /var/log/wtmp查看失败登录尝试lastb读 /var/log/btmp需要 root查看每个用户最近登录时间lastlog读 /var/log/lastlog查看当前在线用户w/who快速查看在线状态查看系统重启记录last -x | grep reboot或last -x reboot查看系统关机记录last -x shutdown部分发行版直接支持查看近期启动列表journalctl --list-bootssystemd 日志查看某次启动的日志journalctl -b -1负数为历史启动查看最近一次启动时间who -b/uptime -s两者可互相印证查看轮转后的旧记录last -f /var/log/wtmp.1文件路径随发行版略有差异查看原始二进制日志字段utmpdump /var/log/wtmp适合深入分析6. 操作过程中的体会最后说点个人经验。刚接触这些命令时我也犯过只记用法、不记原理的毛病导致碰到异常情况就抓瞎。后来慢慢养成一个习惯查任何历史记录先问自己“这条数据写在哪里、由谁写入、轮转策略是什么”只有把数据来源搞清楚命令参数才真正背得住。另外timeline 思维非常重要。登录记录、失败记录、重启记录、认证日志这四类信息单独看也许都“正常”拼成一条完整的时间线才能发现真正的异常。比如同一个 IP 在登录失败 100 次后突然成功然后 3 分钟后系统重启单看 lastb 只能说明有暴力破解但结合 last 和 journalctl 就能拼出一个完整的入侵场景。所以我建议运维同学自己搭一个脚本把 last、lastb、journalctl --list-boots 的结果定期汇总成报表形成常态化审计机制这样某一天真出问题时手里已经有一份完整的时间线排查效率会高非常多。