服务器出问题之后第一时间想弄清楚的事情往往只有一个谁进来过。last和lastlog就是专门干这件事的两个命令前者按时间线把登录、登出、重启、关机全部列出来后者按用户维度告诉你每个账号最后一次登录是从哪个 IP、哪个终端、什么时间进来的。两个命令都属于util-linux包主流发行版默认就装好不需要额外配置属于出问题才想起来、但真到那时候又必须会用的那类工具。这篇文章不打算把 man 手册翻译一遍而是按实际运维场景来组织先讲清楚wtmp、lastlog、btmp、utmp这几个文件分别装了什么再分别拆last和lastlog的常用参数和输出字段然后用一套完整的验证流程走一遍登录审计、异常 IP 定位、从未登录账户盘点这几个高频动作最后补上日志轮转、记录被清空如何判断、以及一批排查清单。如果你平时要处理服务器安全审计、账户清理、故障回溯或者只是想在多用户机器上看看谁动过系统这篇可以直接照着操作。需要提前说明的是last和lastlog展示的都是已经落盘的历史记录它们不是实时监控工具。想看当前在线用户得用who、w、users想看认证过程的详细日志得用journalctl -u sshd或者auditd。这几个工具是互补关系不是替代关系后面会在对应章节说明什么时候该换工具。1. last 与 lastlog 核心能力速览先把两个命令的定位摆清楚避免用错场景。last是事件流视角一条登录就是一行适合回答昨天晚上八点到十点之间谁登过机器lastlog是账户视角一个用户一行适合回答这个账号到底有没有人用过。能力项说明所属软件包util-linux主流发行版默认安装last 数据来源/var/log/wtmp二进制记录文件lastlog 数据来源/var/log/lastlog按 UID 索引的稀疏文件lastb 数据来源/var/log/btmp登录失败记录当前在线用户/var/run/utmp由 who / w / users 读取输出排序last 默认时间倒序lastlog 默认按 UID 升序是否需要 root读取 wtmp/lastlog 通常需要 root 或相应文件读权限是否可指定文件last 支持 -f 指定任意 wtmp 格式文件lastlog 不支持是否支持按时间过滤last 支持 -s / -p / -tlastlog 支持 -b / -t天数是否支持按用户过滤两者均支持适用场景登录审计、账户盘点、故障回溯、合规检查不适用场景实时监控、命令级操作审计、文件访问审计这张表里最容易被忽略的是最后两行。很多人以为last能查到某人登录后执行了什么实际上它只记录会话的开始和结束中间干了什么完全看不到。要做命令级审计得上auditd、sudo日志、bash的PROMPT_COMMAND或者script这些不在本文范围内。第二个容易被忽略的是权限。/var/log/wtmp一般是root:utmp 0664/var/log/lastlog一般是root:root 0644部分发行版是root:utmp 0664。普通用户能否读取取决于发行版和utmp组的成员配置。如果执行命令后输出为空或者报权限错误先检查文件权限不要急着怀疑记录丢了。2. 适用场景与使用边界2.1 这个工具适合谁第一类是负责 Linux 服务器日常运维的工程师。机器多人共用、账号轮转频繁、出了问题需要回溯上一次登录是什么时候这类场景last和lastlog是成本最低的入口。第二类是做安全基线检查的人员。合规要求里经常有一条定期检查长期未登录账户并禁用lastlog输出的Never logged in就是最直接的判断依据配合chage -l看密码有效期一套组合拳能覆盖大部分账户治理需求。第三类是普通开发者在多用户共享的开发机、跳板机上想确认自己的会话记录、排查为什么我刚登录就被踢掉这类问题用last -x看重启和运行级别变化往往能直接定位。2.2 能解决什么问题确认某个账户最近一次登录的时间和来源 IP。统计一段时间内的登录次数识别异常高频登录。发现从未登录过的账户识别可能的默认账户、测试账户、后门账户。判断系统是否在非预期时间重启过last -x reboot。排查用户说自己登不上到底是密码问题还是根本没发起过连接结合lastb。审计su、sudo之外的会话级痕迹比如某个pts终端对应哪个来源。2.3 不适合什么场景last和lastlog都不记录命令。想看谁删了数据库这种问题它们帮不上忙。它们也不记录文件访问。想看谁读了 /etc/shadow得靠auditd。它们的数据可以被清空。wtmp是普通文件root 权限下truncate -s 0就没了攻击者拿到 root 后第一件事往往就是清日志。所以这类记录只能作为辅助证据不能作为唯一证据。真正的审计要求场景需要把日志实时转发到独立的日志服务器或者开启systemd-journald的远程转发让本地记录被清除也不影响留存。最后一点登录记录涉及个人信息。在合规环境下采集、保存、分析这些数据需要有明确的目的和授权范围导出结果不要随意传播测试环境验证完及时清理。3. 日志文件机制与环境准备在动手敲命令之前把几个文件的职责分清楚后面所有排查都会顺很多。文件路径记录内容读取命令写入者/var/log/wtmp成功登录、登出、重启、关机、运行级别变化lastsystemd-update-utmp / login / sshd/var/log/btmp登录失败记录lastblogin / sshd/var/log/lastlog每个用户最后一次登录lastloglogin / sshd/var/run/utmp当前登录会话who / w / userslogin / sshd / systemd/var/log/secure 或 /var/log/auth.log认证过程详细日志文本工具 / journalctlsshd / sudo / su这里有个细节值得单独说wtmp、btmp、lastlog、utmp都是二进制格式不能用cat、tail、grep直接看。强行cat /var/log/wtmp会输出一堆乱码grep也匹配不到任何有意义的字符串。这不是文件损坏是设计如此。要看内容只能用对应的命令或者用utmpdump转成可读文本。lastlog还有一个特殊性它是稀疏文件文件偏移量直接对应 UID。也就是说 UID 1000 的用户记录写在偏移量 1000 乘以结构体大小的位置UID 65534 的记录写在很靠后的位置。这导致ls -lh看到的文件大小可能有几十 MB 甚至上百 MB但du -h看实际占用可能只有几十 KB。这是正常现象不是磁盘异常。3.1 环境确认清单在开始测试前建议先确认下面几项# 1. 确认命令是否存在及版本 last --version lastlog --version lastb --version # 2. 确认相关文件存在及权限 ls -l /var/log/wtmp /var/log/btmp /var/log/lastlog /var/run/utmp 2/dev/null # 3. 确认当前身份 id whoami # 4. 确认当前在线用户对照组 who wlast --version输出的版本号来自 util-linux不同版本的参数支持有差异。比如--time-format、-s、-p这些参数在较老的发行版如 CentOS 7 自带的 util-linux 2.23上可能不存在执行会报invalid option。遇到这种情况不要怀疑命令写错先看版本。如果ls显示/var/log/wtmp不存在说明系统的wtmp记录功能被关闭了。这在容器环境、精简镜像、部分云主机自定义镜像里很常见。检查方式# 查看 systemd 是否屏蔽了 wtmp 更新 systemctl status systemd-update-utmp 2/dev/null ls -l /usr/lib/systemd/system/systemd-update-utmp* # 检查是否有指向 /dev/null 的软链接 ls -l /var/log/wtmp如果/var/log/wtmp是一个指向/dev/null的符号链接那所有登录记录都被丢掉了last永远是空的。这种情况需要删掉软链接并从备份恢复或者接受没有历史记录这个事实改用journalctl作为替代数据源。4. last 命令语法与基础用法last的基本语法是last [选项] [用户名...] [终端...]不接任何参数时它读取/var/log/wtmp按时间从近到远输出全部记录。输出长这样字段含义下一节展开root pts/0 192.168.1.100 Mon Jan 15 09:12 still logged in alice pts/1 10.0.0.23 Mon Jan 15 08:45 - 10:30 (01:45) bob pts/2 172.16.5.8 Sun Jan 14 22:10 - 23:05 (00:55) reboot system boot 5.15.0-91-generi Sun Jan 14 03:00 still running root tty1 Sun Jan 14 02:58 - down (00:02) wtmp begins Sun Jan 14 02:55:33 20244.1 常用参数速查参数作用典型用法-n 数量只显示最近 N 条last -n 20-数量简写形式等价于 -nlast -20-f 文件指定 wtmp 格式文件last -f /var/log/wtmp.1-t 时间显示指定时间之前的记录last -t 20240115000000-s 时间显示指定时间之后的记录新版本last -s 20240101-p 时间显示指定日期的记录新版本last -p 20240115-x显示关机、运行级别变化等系统事件last -x-i来源显示为 IP 而非主机名last -i-R不显示主机名或 IP 列last -R-a主机名显示在最后一列last -a-F显示完整时间年月日时分秒last -F-w显示完整用户名和域名last -w--time-format指定时间输出格式last --time-formatiso-s和-p这两个参数在 util-linux 2.30 之后才加入CentOS 7 用户大概率用不了替代方案是-t配合管道过滤后面会给出写法。4.2 按时间和数量过滤最常见的需求是只看最近 20 条# 两种写法等价 last -n 20 last -20想看某个时间点之前的记录# 格式为 YYYYMMDDHHMMSS可以省略后面的部分 last -t 20240115000000 last -t 20240115想看某个时间之后的记录新版本用-slast -s 20240101老版本没有-s时用-t加管道反选虽然笨但能用# 显示 2024-01-01 之后、2024-01-15 之前的记录 last -t 20240115000000 | awk $0 ~ /2024/ $0 !~ /2023/更稳妥的做法是先导出到文件再用awk按日期列过滤避免不同版本的输出格式差异导致匹配失败。4.3 按用户和终端过滤# 只看指定用户 last alice last alice bob # 只看指定终端 last pts/0 last tty1 # 组合使用 last alice pts/0按终端过滤在排查某个 pts 会话是谁开的时特别有用。比如发现pts/3上有可疑操作last pts/3能直接告诉你这个会话属于谁、从哪来、开了多久。4.4 查看系统重启和关机记录这是last最容易被低估的用法。服务器莫名其妙断过一次想知道是重启了还是被关机了直接last -x reboot last -x shutdown last -x-x会把reboot、shutdown、runlevel这些系统事件一起列出来。输出里的reboot和shutdown是伪用户名不对应真实账户system boot是内核版本。判断依据很简单有reboot system boot说明系统重启过前面的会话如果有- down结尾说明是被正常关机带下去的。5. last 输出字段解析与实战验证5.1 逐列拆解拿一行典型输出alice pts/1 10.0.0.23 Mon Jan 15 08:45 - 10:30 (01:45)列位置内容说明第 1 列alice登录用户名第 2 列pts/1终端设备pts 为伪终端SSH、图形终端内的 shell第 3 列10.0.0.23登录来源本地登录时为空第 4 列起Mon Jan 15 08:45登录时间之后- 10:30登出时间仍在线的显示 still logged in括号内(01:45)会话持续时长格式为 时:分终端类型需要单独说明tty1到tty6本地虚拟控制台物理机接显示器登录。pts/0、pts/1伪终端SSH 登录、screen/tmux内的新会话、图形界面里的终端窗口都会分配 pts。:0X11 图形会话。reboot、shutdown、runlevel系统事件伪用户不是真实账户。still logged in表示会话还没结束此时括号里没有时长。- down表示系统在这个会话期间关机了时长是关机时间减去登录时间。5.2 验证流程制造一条记录再查想确认记录机制是否正常工作最直接的办法是制造一条可识别的记录再查回来。步骤如下第一步开一个 SSH 会话或者本地终端记录当前时间和来源。第二步用who确认当前会话存在who输出里应该能看到你的用户名、终端号和登录时间。第三步用last查自己last $(whoami) -n 5正常情况下第一行就是当前会话状态为still logged in来源字段与你实际的 IP 或主机名一致。第四步退出该会话再次登录后查询状态应该变成带时长的时间区间last $(whoami) -n 5如果第一次查有记录、退出再查记录消失了说明wtmp写入有问题回到第 3 节检查文件状态。5.3 用 -F 看完整时间默认输出省略了年份跨年查询时容易误判。-F参数会输出完整时间last -F -n 10输出变成alice pts/1 10.0.0.23 Mon Jan 15 08:45:12 2024 - Mon Jan 15 10:30:44 2024 (01:45)做日志比对、工单记录、跨年审计时建议固定带上-F避免1 月 15 日到底是今年还是去年这种歧义。5.4 用 -i 避免 DNS 反解干扰last默认会尝试把来源 IP 反解成主机名。这个行为在两种情况下会拖慢命令DNS 服务器响应慢或者内网没有配置反向解析。表现是命令卡住几秒甚至十几秒才出结果。解决方法是加-ilast -i -n 20-i强制显示 IP不做反解既快又准确。做审计时也建议固定用-i因为主机名可能被篡改或者存在同名冲突IP 更可靠。5.5 统计登录次数last本身不带统计功能但输出格式稳定用管道处理很方便# 统计每个用户成功登录次数排除系统伪用户 last -i | grep -v -E ^(reboot|shutdown|runlevel|wtmp) | awk {print $1} | sort | uniq -c | sort -rn这条命令的每一步都有明确目的grep -v去掉系统事件和结尾行awk {print $1}取第一列用户名sort | uniq -c计数最后sort -rn按次数倒序。输出可以直接作为账户活跃度排名的依据。如果想统计某个 IP 的登录次数把$1换成$3即可last -i | grep -v -E ^(reboot|shutdown|runlevel|wtmp) | awk {print $3} | sort | uniq -c | sort -rn | head -20这条在识别暴力破解的内网跳板、异常来源时非常有用。6. lastlog 命令用法与账户盘点lastlog和last的数据源完全不同它是按 UID 索引的所以输出是一个用户一行默认按 UID 升序排列包含系统账户。6.1 基础用法不接参数时输出全部账户lastlog输出格式Username Port From Latest root pts/0 192.168.1.100 Mon Jan 15 09:12:33 0800 2024 bin **Never logged in** daemon **Never logged in** alice pts/1 10.0.0.23 Mon Jan 15 08:45:12 0800 2024字段含义字段说明Username账户名Port最后一次登录使用的终端从未登录则为空From最后一次登录的来源 IP 或主机名Latest最后一次登录时间从未登录显示Never logged in6.2 按用户过滤lastlog -u alice lastlog -u alice,bob排查单个账户时这是最快的方式比全量输出再 grep 更干净。6.3 按时间窗口过滤lastlog的时间过滤是按天数算的不是日期字符串# 显示最近 7 天内登录过的账户 lastlog -t 7 # 显示 30 天之前登录过的账户含从未登录 lastlog -b 30这两个参数组合起来可以做僵尸账户盘点-b 90找出 90 天没登录的再加上grep Never logged in找出从来没登录过的。# 超过 90 天未登录的账户 lastlog -b 90 # 从未登录过的账户 lastlog | grep -i never logged in注意-b和-t在部分老版本上行为略有差异某些版本-b会把从未登录的账户也包含进来某些不会。做批量处理前建议先用小范围数据验证一次输出结构。6.4 验证 lastlog 是否正常工作lastlog和wtmp是两套独立记录有可能一个正常一个异常。验证方法# 1. 记录当前时间 date # 2. 查看自己账户的 lastlog 记录 lastlog -u $(whoami) # 3. 新开一个 SSH 会话后再查一次 lastlog -u $(whoami)第二次查询的时间应该更新为刚才那次登录的时间。如果last有新记录但lastlog没更新通常是/var/log/lastlog权限问题或者被设成了只读。检查ls -l /var/log/lastlog stat /var/log/lastlog正常情况下所有者是 root权限 0644 或 0664。如果被改成只读0444且所有者不是 root写入会失败。6.5 识别需要处理的账户这一节是lastlog最实用的地方。账户盘点通常分三步第一步找出所有从未登录过的账户lastlog | grep -i never logged in | awk {print $1}第二步把这些账户和系统必需账户做对比。bin、daemon、sys、sync、games、man、lp、mail、news、uucp、proxy、www-data、backup、list、irc、gnats、nobody、systemd-network、systemd-resolve这些是发行版自带的服务账户属于正常情况不要动。第三步剩下的才是需要关注的人为创建但从未使用的账户、离职人员遗留账户、测试账户、以及最需要警惕的——不在预期清单里的账户。对这些账户用chage -l看密码策略用id看所属组确认无误后再决定锁定还是删除# 查看账户密码有效期信息 chage -l suspicious_user # 查看账户 UID、GID、所属组 id suspicious_user # 锁定账户保留账户但禁止登录 usermod -L suspicious_user # 锁定并设置过期日期 usermod -L -e 1 suspicious_user删除账户前务必确认该账户没有被任何服务进程使用用ps -ef | grep username和find / -user username检查一遍避免误删导致服务异常。7. 登录审计实战与异常排查7.1 定位异常来源 IP第一步统计所有登录来源last -i | grep -v -E ^(reboot|shutdown|runlevel|wtmp) | awk {print $3} | sort | uniq -c | sort -rn第二步对可疑 IP 反查详细记录last -i | grep 203.0.113.45第三步交叉验证认证日志。last只能看到成功登录如果这个 IP 同时存在大量失败记录说明在做爆破# 查看失败登录记录需要 root lastb | grep 203.0.113.45 | head -50 # 统计失败次数最多的来源 lastb | awk {print $3} | sort | uniq -c | sort -rn | head -20lastb读的是/var/log/btmp。如果这个文件不存在或者为空说明系统没有记录失败登录需要检查sshd配置里的SyslogFacility和 PAM 配置或者该文件被清理过。有些发行版出于磁盘考虑默认关闭了btmp写入。7.2 判断记录是否被清空这是安全排查里最关键的一步。last输出的最后一行永远是以wtmp begins开头的它告诉你当前wtmp文件里最早的记录是什么时间。这一行是判断日志是否被清洗的核心依据。last | tail -1输出类似wtmp begins Sun Jan 14 02:55:33 2024判断逻辑如果wtmp begins的时间比系统安装时间晚很多且中间没有合理的日志轮转解释说明记录被清空过。如果/var/log/wtmp文件大小异常小比如几 KB但机器已经运行了几个月同样可疑。如果wtmp.1、wtmp.2这些轮转文件存在但不连续中间有缺口也要警惕。检查轮转文件和文件时间ls -l /var/log/wtmp* ls -l /var/log/btmp* stat /var/log/wtmpstat输出的Modify时间是最后一次写入时间Change是元数据变更时间。如果Change时间远晚于Modify且你并没有做过权限调整那可能存在人为干预。7.3 结合 journalctl 交叉验证wtmp可以被清空但journald的日志通常在另一个位置两者交叉比对能提高判断准确度# 查看 sshd 登录成功记录 journalctl -u sshd --since 2024-01-01 --until 2024-01-31 | grep -i Accepted # 查看登录失败记录 journalctl -u sshd --since 2024-01-01 | grep -i Failed password # 查看 sudo 使用记录 journalctl _COMMsudo --since today把journalctl里的Accepted publickey for alice from 10.0.0.23和last里的记录对上时间、用户、IP 三项一致才算验证通过。如果journalctl有记录但last没有基本可以确认wtmp被清理过。需要提醒的是journald默认也可能不持久化Storagevolatile时日志只存在内存重启即丢。做审计要求高的环境应该把Storage设为persistent并配置远程转发。7.4 排查用户说登不上这类问题分两种根本没连上或者连上了但会话立刻断开。先看有没有成功记录last -i $(whoami) -n 10 last -i | grep username如果没有成功记录再看失败记录lastb | grep username | head -20有失败记录但没成功记录说明密码或密钥验证失败方向转向认证配置。如果成功记录存在但时长只有几秒说明登录后立即被踢方向转向 shell 配置、/etc/profile、PAM 的pam_nologin、磁盘配额、或者sshd的MaxSessions限制。这时候last提供的登录时间 持续时长就是最直接的线索。8. 日志轮转、归档与长期留存wtmp和btmp会持续增长不轮转的话几年下来能到几百 MB。主流发行版通过logrotate管理配置文件通常在/etc/logrotate.conf或者/etc/logrotate.d/下。8.1 查看当前轮转配置# 查看主配置里是否有 wtmp 相关条目 grep -n wtmp\|btmp\|lastlog /etc/logrotate.conf # 查看独立的配置文件 ls -l /etc/logrotate.d/ | grep -i wtmp\|btmp cat /etc/logrotate.d/wtmp 2/dev/null典型配置长这样/var/log/wtmp { missingok monthly create 0664 root utmp rotate 1 }含义是文件不存在时不报错按月轮转新建文件权限 0664、所有者 root、组 utmp保留 1 份历史。也就是说系统上最多同时存在wtmp和wtmp.1两个文件。8.2 查询历史轮转文件last的-f参数可以指定任意 wtmp 格式文件这是查历史记录的标准方式# 查询上一份轮转文件 last -f /var/log/wtmp.1 # 组合查询当前文件 历史文件 last -f /var/log/wtmp last -f /var/log/wtmp.1 # 如果有多份历史文件按时间顺序处理 for f in /var/log/wtmp.*; do echo $f last -f $f -n 5 done需要说明的是last -f不会自动去读轮转文件必须手动指定。所以为什么last只能看到最近一个月的记录这个问题的答案往往就是rotate 1加上按月轮转历史记录被覆盖了。8.3 调整留存策略如果审计要求保留更长时间需要改轮转配置。修改前先备份原文件cp /etc/logrotate.d/wtmp /etc/logrotate.d/wtmp.bak然后把rotate 1改成rotate 12保留 12 份monthly保持不变这样大约能保留一年。改完用logrotate -d做一次 dry run确认配置语法没问题logrotate -d /etc/logrotate.conf-d是调试模式只打印将要执行的动作不真正执行。输出里能看到每个文件的轮转判断结果确认无误再去掉-d实际执行。调大留存份数会占用更多磁盘空间单个wtmp文件大小取决于系统的登录频率。按经验中等负载的服务器月均几十 KB 到几百 KB一年也就几 MB成本可以接受。但如果你要常年留存更推荐的做法是定期导出成文本归档而不是无限增加轮转份数# 导出当前 wtmp 为文本按日期命名归档 last -F -f /var/log/wtmp /var/backups/login-audit-$(date %Y%m%d).log # 归档后可以压缩 gzip /var/backups/login-audit-*.log文本归档的好处是可以直接用grep、awk处理不受二进制格式和命令版本限制。8.4 清空日志的正确姿势测试环境需要重置记录时直接用重定向会失败因为 shell 会尝试以普通文件方式打开而wtmp可能被进程持有。正确写法是用truncate# 清空 wtmp保留文件本身和权限 truncate -s 0 /var/log/wtmp # 清空 btmp truncate -s 0 /var/log/btmp # 清空 lastlog 前先备份 cp /var/log/lastlog /var/backups/lastlog.bak truncate -s 0 /var/log/lastlogtruncate -s 0只把文件长度设为 0不改变 inode、权限和所有者写入进程持有的文件描述符依然有效后续记录会正常追加。相比之下rm后重建会导致权限变化还可能因为进程持有旧 inode 而出现新记录写不进去的问题。清空lastlog后所有账户的lastlog查询都会显示Never logged in直到各自重新登录一次。这个操作在生产环境要慎重清空前必须备份。9. 常见问题与排查方法下面这张表覆盖了last和lastlog使用过程中最常见的异常现象。问题现象可能原因排查方式解决方案last 输出为空wtmp 不存在或被软链到 /dev/nullls -l /var/log/wtmp恢复文件或改用 journalctllast 只有 wtmp begins 一行wtmp 被清空last 查看 wtmp begins 时间结合 journalctl 交叉验证执行 last 报 Permission denied当前用户不在 utmp 组或无读权限ls -l /var/log/wtmp用 root 执行或调整权限last 卡住十几秒才输出DNS 反解超时对比加 -i 前后耗时固定使用 last -ilast -s 报 invalid optionutil-linux 版本过老last --version改用 -t 加管道过滤lastlog 全部显示 Never logged inlastlog 被清空或权限异常ls -l /var/log/lastlog备份后重建文件lastlog 文件很大但 du 很小稀疏文件特性正常现象ls -lh 与 du -h 对比无需处理lastb 无输出btmp 不存在或未启用失败记录ls -l /var/log/btmp检查 PAM 和 sshd 配置时间显示缺年份默认输出格式省略年份加 -F 参数固定使用 last -F用户名显示不全用户名过长被截断加 -w 参数last -w记录里有陌生账户可能是后门或遗留账户lastlog -u 用户名 / id 用户名确认后 usermod -L 锁定某会话时长异常短登录后被 PAM 或 shell 配置踢出查看 /etc/profile、pam_nologin逐项排查登录后脚本9.1 关于last 看不到最近的登录这是咨询频率最高的问题原因通常有三个按概率排序第一个是登录方式不写wtmp。某些容器环境、非标准 SSH 实现比如某些 Web 终端、kubectl exec不会触发wtmp写入。这类登录在who里也看不到属于设计限制无解只能用应用层日志替代。第二个是wtmp轮转后没查历史文件。表现是上周的登录能查到昨天的查不到这时候看ls -l /var/log/wtmp*有没有.1文件有的话用-f指定查询。第三个是时区问题。last显示的时间是本地时区但如果服务器时区被改过或者登录时区和当前时区不一致时间对比会错位。用timedatectl确认当前时区用last -F看完整时间戳避免误判。9.2 关于用户名显示成数字last输出第一列偶尔会出现纯数字这是因为该 UID 对应的账户已经被删除但wtmp里的历史记录还在。last找不到用户名映射时会退化成显示 UID。处理方式很简单这是历史记录的正常表现不需要修复。如果确实要清理只能清空wtmp但那会丢失所有其他记录不划算。更好的做法是在删除账户前先导出该账户的登录记录归档last -F -i 用户名 /var/backups/user-login-用户名-$(date %Y%m%d).log9.3 关于 lastlog 的写入延迟部分环境下lastlog的更新不是在登录瞬间完成而是由 PAM 的pam_lastlog模块在会话建立后写入。如果登录后立刻执行lastlog查询可能看到的是上一次的记录。这不是 bug稍等片刻或者重新登录一次即可。做自动化测试时建议在登录和查询之间留出几秒间隔避免时序问题。10. 最佳实践与使用建议第一把last -F -i作为默认查询方式。-F消除年份歧义-i避免 DNS 反解导致的卡顿和主机名伪造风险两个参数加起来几乎没有副作用养成习惯能省掉很多解释成本。第二审计时永远做交叉验证。last和lastlog只覆盖会话级信息真正判断一个账户是否异常至少要同时看lastb的失败记录、journalctl -u sshd的认证日志、sudo的操作日志。单一数据源得出的结论容易误判尤其是wtmp本身可以被清理这一前提。第三给日志留存定一个明确策略。默认的rotate 1加按月轮转实际上只能回溯一个月左右。有审计要求的场景要么把rotate调到 12要么定期导出文本归档要么配置journald远程转发。三者至少要做一个不要等到出事才发现记录只剩一周。第四账户盘点做成周期性任务。每月跑一次lastlog -b 90和lastlog | grep -i never logged in输出结果人工过一遍。这件事单次成本很低但能及早发现遗留账户、测试账户和异常新增账户。配合chage -l检查密码有效期基本能覆盖账户治理的主要面。第五测试环境的清空操作要留痕。truncate -s 0 /var/log/wtmp这类命令执行前先cp备份执行后记录时间和操作人。生产环境原则上不做清空只做归档和轮转。第六涉及登录记录的处理要注意合规。这类数据能定位到具体人员的行为和时间采集、保存、导出、共享都需要有明确授权范围。导出的审计文件不要放在公开可访问的目录测试完成后及时清理避免个人信息外泄。第七.bash_history和last要分开理解。前者是命令历史可以被用户自行修改或清空后者是会话记录普通用户改不了。两者结合看才能大致还原一个会话的全貌。但两者都不具备法律意义上的完整性涉及取证场景应该交给专业流程处理。最后补一个容易被忽略的组合last -x加上journalctl --list-boots能把系统重启记录和内核启动日志对上排查机器为什么半夜重启了这类问题时比单看任何一个都管用。