服务器登录日志全解析：从默认记录到异常排查与安全加固

1. 先给结论：服务器不止会记，而且记录得比你想象的细

先说个真实经历。上周帮一位朋友排查一台CentOS云服务器，他说收到一条“登录失败”的短信通知，问我要不要紧。我让他把/var/log/secure里那一段拉出来看，结果他愣住了：不光是那一条失败记录，前后还躺着几十条相同来源IP的尝试，连时间精确到秒、尝试过的用户名、来源端口、SSH客户端版本号都在。他问：“这些东西是谁写进去的？我明明没有装任何监控软件啊。”

这就是大多数人第一次面对登录日志时的真实反应：以为“没装监控 = 没记录”，但实际上操作系统从安装好的第一天起就在默默记录登录行为。这个问题的答案是：服务器不仅会记，而且默认就会记。你不需要装任何额外软件，登录日志一直都在，只是你平时没去看而已。

1.1 登录日志到底记了什么

一次登录事件，无论是成功还是失败，系统至少会留下这些信息：

• 发生登录的时间（精确到秒）
• 尝试登录的用户名（就算这个用户根本不存在也会记）
• 来源IP和源端口
• 认证方式：密码、公钥、键盘交互等
• 结果是成功还是失败
• 如果成功，还会记录建立会话的终端类型、会话开始和结束时间

这些信息分散在几种不同的日志里，各管一段：

• 认证过程日志：记录密码校验、公钥比对、PAM模块执行结果，比如“Failed password for root from 1.2.3.4 port 22 ssh2”
• 登录状态日志：记录一次会话的开始、结束、持续时长，对应last和who命令看到的内容
• 审计日志：如果配置了auditd，可以进一步记录登录后执行了哪些命令、打开了哪些文件，这是更细一层的追溯

很多新人以为“异常登录”和“日志”是两件事，其实是同一件事的两面。所谓异常登录，本质上就是日志里出现了你不认识的记录。先把日志这个东西搞清楚，后面的判断才有依据。

1.2 默认开启吗？会不会被管理员偷偷关掉

有人会担心：是不是有些服务器默认不记录，或者被安全策略关掉了？

以 Linux 为例，SSH 服务从编译时就默认接入了 syslog 体系，登录信息走的是auth或authpriv设备通道。只要系统里 syslog（rsyslog 或 systemd-journald）还在运行，记录就不会断。CentOS 系的/var/log/secure、Debian/Ubuntu 系的/var/log/auth.log，都是这个通道的默认落盘位置。

Windows 更直接。安全审计是 Windows 系统的基础组件之一，登录成功对应事件ID 4624，登录失败对应事件ID 4625。只要你没通过组策略手动关掉相应审计项，这些事件默认就会写进安全事件日志。我见过一些 Windows 管理员为了让系统“少写日志”而清掉安全审计策略，这种做法相当危险，真出事的时候所有证据都没了。

所以结论很明确：只要系统是正常安装、正常运行的，登录日志就是默认存在的。你找不到记录，绝大多数情况不是“没有记录”，而是不知道去哪看，或者时间对不上没搜对地方。

2. 日志文件到底藏在哪里：Linux、Windows、云平台各自的查法

不同系统的日志存放路径天差地别，但核心逻辑是一致的：都分“认证日志”和“会话日志”两层。下面把三种常见场景分别过一遍。

2.1 Linux 上最常用的三件套

Linux 上排查登录日志，我平时基本只用三组命令：

# 查看成功登录的历史会话 last # 查看失败登录尝试（lastb 需要 root 权限，读取 /var/log/btmp） lastb # 查看实时的登录会话 who w

last读完的是/var/log/wtmp，里面记录的是“哪些用户从哪个IP登录过、登录时长、何时退出”。lastb读取的是/var/log/btmp，专门记录失败尝试。注意一点，btmp文件不是所有系统默认都预分配的，如果文件不存在，lastb会报错“No such file or directory”。这个文件的分配通常由 syslog 或 systemd 的 tmpfiles 机制在启动时创建，某些精简安装的容器镜像可能没有，需要手动touch /var/log/btmp并确认权限。

想看更详细的认证过程，就得去翻认证日志：

# Debian/Ubuntu tail -n 200 /var/log/auth.log # CentOS/RHEL tail -n 200 /var/log/secure # 使用 systemd 日志的系统也可以这样查 journalctl -u sshd --since "yesterday"

典型的记录长这样：

Jan 15 03:12:47 web-server sshd[23854]: Failed password for root from 203.0.113.10 port 51234 ssh2 Jan 15 03:12:48 web-server sshd[23856]: Received disconnect from 203.0.113.10 port 51234:2: too many authentication failures Jan 15 03:12:49 web-server sshd[23858]: Invalid user admin from 203.0.113.10 port 51235

这里面每一行字段的含义都很直接：时间、主机名、进程名、事件内容。看到Failed password for root说明有人用root账号试密码失败了；看到Invalid user admin说明这个叫 admin 的用户根本不存在，扫描器在猜用户名。

2.2 Windows 服务器看事件ID

Windows 的登录日志不在普通文件里，而是存放在“安全事件日志”中，文件位置是C:\Windows\System32\winevt\Logs\Security.evtx。日常排查不需要直接读文件，用事件查看器或者 PowerShell 就够了。

需要重点记住的事件ID有这些：

用 PowerShell 查也很方便：

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 20 | Select-Object TimeCreated, Message | Format-List

想只看某个时间段的失败登录，可以加StartTime和EndTime参数：

$start = Get-Date "2026-01-01 00:00:00" $end = Get-Date "2026-01-01 23:59:59" Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=$start; EndTime=$end} | Select-Object TimeCreated, Message

Windows 日志里的 4625 事件会带上登录类型（2表示本地键盘登录，3表示网络登录，10表示远程交互登录）、源IP、进程名，信息量不比 Linux 少。

2.3 云平台上的登录记录要分开看

如果你用的是云服务器，那么除了操作系统日志，还要看云平台侧的控制台登录日志和操作审计。这类日志一般记录“谁通过网页控制台登录了这台服务器”“谁重启过实例”“谁修改过安全组规则”。

云平台日志和系统日志是互补的，而不是互相替代：

• 系统日志记录的是操作系统内部的认证行为，包括SSH、远程桌面
• 云平台日志记录的是控制台层面的管理操作，比如通过网页VNC登录、重置密码、调整配置

我见过一个案例，有人在云控制台的“远程登录”里输错了密码，系统日志没记录，但云平台的操作记录里有。反过来，SSH暴力破解在系统日志里刷屏，云平台侧却可能毫无动静。所以排查的时候两部分都要看，只看任何一边都可能漏掉关键信息。

另外，服务器一旦上了公网，被扫描是常态，并不等于被入侵。云平台上看到一条失败登录告警，先冷静，接着去系统日志里核对细节，而不是立刻紧张。

3. 一眼识别“异常”登录：攻击指纹、正常误报、高危信号

日志文件摆在那里，几千行记录，怎么判断哪些才是真正值得关注的“异常”？这里分享我自己的工作方法，不用什么高大上的工具，纯手工也能看出门道。

3.1 暴力破解和扫描器的典型指纹

凡是互联网上暴露过默认SSH端口（22）的服务器，几乎每天都有人来试密码。这些扫描行为有非常典型的特征，基本一眼就能认出来：

• 同一IP短时间内大量失败尝试
• 尝试的用户名明显是字典枚举：root、admin、test、guest、ubuntu、oracle 等等
• 用户名五花八门，包含一堆不存在的用户：backup、deploy、mysql、tomcat、minecraft
• 每次连接间隔极短，几秒钟就试好几组密码
• 来源IP常常是海外动态宽带IP或IDC机房的IP

举个最常见的例子，很多扫描机器人专门盯着互联网上的 Minecraft 服务器相关端口，或者是拿一批常见用户名去批量试探。你会在日志里看到类似这样的组合：

Jan 15 04:02:11 web sshd[24001]: Invalid user minecraft from 198.51.100.23 port 60001 Jan 15 04:02:12 web sshd[24002]: Failed password for invalid user mcserver from 198.51.100.23

这种就属于典型的自动扫描，不代表有人盯上你，而是全网无差别攻击的一部分。看到之后不用慌，但也不能放任不管，后面会讲怎么配置自动封禁。

3.2 容易被误判成“异常”的正常登录

反过来，有些记录看起来像是异常，其实完全正常，误判了可能把自己吓一跳。

最典型的几个场景：

• 家里宽带是动态IP：今天登录来源是 100.64.x.x，明天变成 100.66.x.x，这不代表异地登录，只是运营商给你换了出口IP。
• 经过跳板机或堡垒机登录：团队里多个人通过同一台跳板机连服务器，日志里看到的永远是跳板机的IP，而不是每个人的真实IP。如果你不记得自己有从那个IP登录过，别急着下结论，先想想是不是同事或者CI系统在用。
• UTC时区导致的“半夜登录”：很多服务器默认时区是UTC，中国时间凌晨3点，日志里往往显示的是前一天晚上7点。你看到一条“凌晨登录成功”的记录，换算回北京时间可能只是晚上正常操作。
• 自动部署工具和监控探针：ansible、salt、consul这类工具会定时连服务器，它们在日志里会显示成各种登录成功记录。如果这些账号用的人不多，偶尔看一眼觉得陌生，其实每天都在规律运行。

我自己的经验是：判断一条登录是否异常，永远要把时区换算、登录方式、业务场景三者放在一起看。单独看“来源IP陌生”很容易误判，关键是结合时间段和行为是否规律。

3.3 真正需要警惕的高危信号

如果出现下面这些情况，优先级就要提高了：

• 原本从未用公钥登录过的账号，突然出现一条公钥登录成功记录
• 同一个账号在极短时间内从两个相距很远的地区登录，排除跳板机后基本可以认定凭据泄露
• 日志里出现了你完全不知道的新用户名，并且登录成功
• 登录成功之后，紧接着有审计日志显示执行了下载、打包、权限切换等敏感命令
• 系统里多了新的 authorized_keys 公钥内容，或者 /etc/cron.d/ 下面多了新文件

有过一次这样的场景：我接到告警后去查last，发现一个刚创建不久的系统账号在凌晨成功登录过，而这个账号只有当初创建数据库任务时用过。后来查了审计日志，发现登录后立刻执行了curl下载脚本，基本可以确认被入侵。这种情况就不能再当扫描误报处理了，要按应急响应流程走。

4. 日志是怎么被写进文件的：auth.log 背后的生产流水线

很多人看过日志，但不知道日志是怎么来的。了解这个机制特别有用，因为你会懂得为什么同一个事件会出现两行内容、为什么有些内容查不到、为什么时间戳可能不可信。

4.1 sshd、PAM、syslog 三者怎么配合

以 Linux 下最常见的情况为例，一次 SSH 密码登录大概走这么几步：

1. 客户端连上服务器的22端口，sshd 收到连接请求
2. sshd 调用 PAM（可插拔认证模块）完成用户名密码校验
3. PAM 把校验结果交给 pam_unix 模块记录到 syslog
4. sshd 自己也会针对登录事件再过一遍日志输出
5. 各种日志信息经过 syslog（rsyslog 或 systemd-journald）分类，认证类信息写入auth.log或secure
6. 登录成功建立会话后，sshd 还会通过系统调用把会话信息写进 wtmp 文件

所以你在日志里经常会看到同一个事件的两条记录，比如：

Jan 15 03:12:47 web sshd[23854]: Failed password for root from 203.0.113.10 port 51234 ssh2 Jan 15 03:12:47 web sshd[23854]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=203.0.113.10 user=root

这两条都在说同一件事：root用户密码验证失败。一条是 sshd 自己输出的，一条是 PAM 记录下来的。看到重复内容不用奇怪，不是出了两条独立登录事件。

4.2 哪些信息会被记录，哪些永远不会被记录

这是很多人最关心的部分。直接说结论：

会记录的信息：用户名、来源IP、源端口、认证类型、连接时间、断开时间、会话时长、sshd版本和客户端版本、尝试次数。

不会记录的信息：登录密码本身。密码在校验时要么转成哈希比对，要么直接丢弃，日志里只保存“校验失败/成功”这个结果，不会把明文密码写进文件。如果哪个系统在日志里明文记录密码，那是相当严重的安全事故。

另外，默认情况下，登录之后的命令输入也不会被记录。也就是说，攻击者成功登录后执行了什么命令，光靠 auth.log 是看不出来的，必须靠 shell 的历史记录或者auditd审计日志。这就是为什么我经常建议重要的服务器开启 auditd，它能记录一条命令是谁在什么时候、从哪个终端、以什么权限执行的。

4.3 为什么有些记录会平白无故“消失”

有几次排查异常登录时，我发现记录对不上：窗口期内应该有的记录就是找不到。原因往往是下面几个：

• 服务器时间漂移：NTP 没配置好，服务器时间比真实时间慢了十几个小时，按错误时间去搜当然搜不到
• 日志被 logrotate 轮转：日志文件被切过了，你要找的时间段可能在昨天的压缩包里
• 容器环境日志直接打到 stdout：容器一销毁，日志跟着丢失，连渣都不剩
• syslog 服务异常：rsyslog 进程崩了，或者磁盘满了，新日志写不进去
• 系统发生过快照回滚：虚拟化平台上如果从旧快照恢复，恢复之后的所有日志都会被抹掉，时间线上的日志会突然断层

还有一类比较容易踩坑：CentOS 7 这类带 systemd 的系统，journald 默认会把日志放内存，如果意外断电，未落盘的日志直接丢失。所以特别重要的服务器，我会在/etc/systemd/journald.conf里把Storage=设成persistent，并且在 rsyslog 里保证核心日志有落盘。

4.4 时间戳怎么才算可信：NTP 和时区问题

排查登录日志时，“时间对不上”是最常见的坑。很多服务器出厂默认是 UTC 时间，而业务同事习惯用北京时间。日志里显示凌晨3点，其实北京时间是上午11点，正常人都会以为“有人半夜登录了”而吓一跳。

我的建议是，把三件事一次做对：

# 查看当前时区和时间状态 timedatectl status # 改成中国标准时间 timedatectl set-timezone Asia/Shanghai # 开启并配置 NTP 时间同步 timedatectl set-ntp true

如果你想手动指定时间同步源，就在/etc/chrony.conf（CentOS/RHEL 8+）或者/etc/systemd/timesyncd.conf（Ubuntu）里配置上游 NTP 服务器，然后重新启动计时服务。时间同步能消除“日志时间和现实对不上”的问题，也能避免因为时钟漂移导致的关键日志排错困难。我习惯把所有服务器的时区统一设置成Asia/Shanghai，这样不管谁去看日志，都不用再做心理换算了。

5. 一次异常登录的完整排查链路：从收到告警到得出结论

看再多理论，不如完整走一次排查。下面用我实际排查过一次“凌晨异常登录”的经历来演示，具体步骤可以直接迁移到其他服务器上。

5.1 第一步：先定位可疑记录

假设你收到一条告警短信：服务器在凌晨2点有过失败登录。第一件事不是立刻断网，而是先看日志，确认到底发生了什么。

# 看最近失败的登录记录 lastb | head -n 50 # 看认证日志里最近的变化 grep "Failed password" /var/log/auth.log | tail -n 50

如果发现大量来自同一个IP的失败尝试，先把该IP的所有行为提取出来看：

grep "203.0.113.10" /var/log/auth.log | tail -n 100

上面的操作会把所有包含该IP的日志行全部拉出来，包括它尝试过的用户名、成功与否、用了什么认证方式。如果全是Failed，那基本就是扫描，还没成功，不需要过度恐慌。

5.2 第二步：从“异常时间点”反向找回完整上下文

如果告警说的是“某天某时有一笔成功登录”，你不能只看那个瞬间，得把那个时间点前后一段时间的日志全部捞出来。比如用 journald 指定时间窗口：

journalctl -u sshd --since "2026-01-15 02:00:00" --until "2026-01-15 02:30:00"

也可以直接对 auth.log 做筛选：

awk '/2026-01-15 02:/' /var/log/auth.log

拿到这段时间窗口的记录后，去做三件事：

1. 确认这个时间点有没有人成功登录了系统
2. 看来源IP是什么、用户名是什么
3. 查一下这个来源IP是谁家的，可以用whois命令查归属，也可以直接去IP查询站点确认是住宅网络还是机房地址

5.3 第三步：检查登录之后有没有“后续动作”

如果确认了一次成功登录来自陌生IP，那就要关心这个账号登录之后干了什么。这部分的排查重点：

# 当前在线会话 who # 检查所有用户 awk -F: '$3>=1000 {print $1, $3, $7}' /etc/passwd # 检查所有用户主目录下的 authorized_keys find /home -name authorized_keys -exec cat {} \; 2>/dev/null # 检查新增的定时任务 ls -la /etc/cron.d/ /var/spool/cron/ 2>/dev/null # 检查登录成功之后的命令历史（前提是 shell 有记录） find /home -name .bash_history -exec tail -n 50 {} \; 2>/dev/null

重点看三处：authorized_keys里有没有不认识的公钥、cron 目录下有没有新增的任务文件、用户列表里有没有不应存在的系统账号。如果这三样里出现不正常的东西，那就不再是“登录异常”这么简单，而是很可能已经入侵成功。

5.4 第四步：确认被入侵后先做什么

如果判断基本确认被入侵，不要急着去“清除后门”，优先顺序应该是：

1. 切断对外服务：云服务器先在安全组里关闭相关公网入口，防止攻击者继续连进来
2. 保留现场：在云平台上给实例打快照，把 auth 日志、最近的命令历史、进程列表先拷一份出来备用
3. 修改凭据：重置所有可疑账号的密码，删掉不认识的 SSH 公钥
4. 重装或恢复：对于没有把握彻底清理后门的系统，直接重装系统或者用干净快照恢复，之后再逐个恢复业务

很多人一发现问题就先删日志或者重启服务器，反而把证据毁了，这个顺序要注意。

6. 与其每次吓一跳，不如让登录日志变得可管理可报警

日志本身只是“记录”，真正让日志有价值的，是把它们变成主动告警和自动防护。下面是我认为每个服务器都应该做的几项最小配置，全部做完也不会超过半小时。

6.1 SSH 服务本身的最小加固

不管日志怎么记，先把 SSH 本身的可攻击面缩小，后面告警量会大幅下降。推荐配置在/etc/ssh/sshd_config里：

PermitRootLogin no PubkeyAuthentication yes PasswordAuthentication no MaxAuthTries 3 LoginGraceTime 30

这几项的意思依次是：禁止root直接密码登录、开启公钥认证、关闭密码认证、限制单次连接最多试3次、超过30秒未完成登录就断开。

有人犹豫要不要禁 root 登录，我的建议是：一定要禁。日常运维用普通用户登录后su -提权，攻击者想摸到 root 还要多绕一层，日志里也能留下更清晰的痕迹。改完配置后记着sshd -t检查语法，再systemctl reload sshd热加载，避免把远程连接搞断。这个坑我踩过一次——语法没验证直接重启，结果 SSH 全断了，还要去控制台走 VNC 救回来。

6.2 用 fail2ban 挡住重复攻击

日志已经在记录攻击了，接下来就让它自动干活。fail2ban会去扫描认证日志，发现某个IP在一段时间内失败次数超限，就自动在防火墙层封禁它。

一个实用配置片段：

# /etc/fail2ban/jail.local [sshd] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 5 bantime = 3600 findtime = 600

含义：10分钟内同一个IP失败超过5次，封禁1小时。CentOS 系统把logpath改成/var/log/secure即可。如果服务器用了非默认端口，port需要改成实际端口，避免封禁策略没绑定到正确的服务上。

安装和启动方式不同发行版略有差异，但基本上systemctl enable --now fail2ban就能跑起来。跑起来之后，配合日志观察，你会发现刷屏的攻击记录迅速变少，因为来源IP大量被封了。

6.3 日志保留和集中化

本地日志最大的问题是：服务器一旦被攻破，攻击者可以顺手清掉日志。所以更稳妥的方式是把日志同步到另一台服务器或者对象存储上。

最简单的方案是给 rsyslog 加一条转发规则，例如把认证日志发到远程日志服务器：

# /etc/rsyslog.d/remote.conf authpriv.* @192.0.2.100:514

远程日志服务器需要开放对应的 UDP/TCP 514 端口。如果不想自建日志服务器，也可以靠 logrotate 把本机日志保留更久，再配合云平台的对象存储定期打包上传。日志文件的保留周期我一般设半年以上，毕竟很多安全事件的追溯周期比想象中长。

6.4 最小可行的告警脚本

不一定非得上一套复杂的 SIEM，一个简单的 cron 脚本就够了。比如每天晚上执行一次统计，把失败次数超过阈值的IP列出来，然后通过 webhook 推到群机器人。

一个很粗但能用的思路：

#!/usr/bin/env bash # /usr/local/bin/check_ssh_failed.sh THRESHOLD=30 REPORT=$(grep "Failed password" /var/log/auth.log | grep -oP 'from \K[0-9.]+' | sort | uniq -c | sort -nr | awk -v t="$THRESHOLD" '$1 >= t') if [ -n "$REPORT" ]; then echo "$REPORT" | while read count ip; do curl -s -X POST "$WEBHOOK_URL" \ -H 'Content-Type: application/json' \ -d "{\"text\":\"SSH爆破告警：IP ${ip} 登录失败 ${count} 次\"}" done fi

写完之后加到 crontab 里，每天凌晨跑一次：

0 1 * * * /usr/local/bin/check_ssh_failed.sh

这套方案简单、透明、不依赖任何商业产品，而且每次执行都是在读日志，不会给系统带来太多额外负担。等它跑顺了，再考虑引入更完整的日志平台。

7. 排查登录日志的这三年，我踩过的一些坑

方法论讲得再多，都不如实际踩坑记忆深刻。最后分享几个我很常见的低级错误，希望你看完能避开。

7.1 日志文件明明存在，却怎么也搜不到记录

有一次我在一台 Ubuntu 服务器上排查登录日志，tail /var/log/auth.log有内容，但grep某个IP却一条都搜不到。后来才发现，那台服务器的 rsyslog 配置里把auth设备单独重定向到了另一个文件，不在默认的 auth.log 里。

具体可以这样查：

grep "^auth" /etc/rsyslog.conf /etc/rsyslog.d/*.conf 2>/dev/null

看到的是真实的落盘路径，比猜靠谱得多。类似的还有 systemd 机器上的journalctl和 rsyslog 各写一份，内容不一定完全一致，别把两边当成同一个文件看待。

7.2 lastb 显示“No such file or directory”不代表没有失败记录

lastb依赖/var/log/btmp。很多新装的系统根本不会自动创建这个文件，导致lastb直接报错。这不意味着没有失败记录，只是没有 btmp 文件而已，auth.log里照样满满当当。

解决办法很简单：

touch /var/log/btmp chown root:utmp /var/log/btmp chmod 660 /var/log/btmp

只要别用last和lastb同时把 btmp 和 wtmp 搞混，后面排查会顺畅很多。

7.3 别把“端口探测”当成“SSH暴力破解”

有时你会看到日志里出现连接记录，然后几秒内又断开，没有任何认证过程。这往往是别人在扫描端口，而不是在猜密码。判断标准很简单：一条连认证都没开始的连接，谈不上“登录异常”，只能算“端口被扫了”。收集这类信息不是没用，但别把它们混进登录失败的告警里，否则告警噪音会大到让你忽略真正的风险。

7.4 云平台的管控入口也要盯

有一次我在一台云服务器上查不到任何异常登录，但用户命令历史里出现了一条不该存在的操作。最后排查发现，攻击者是通过云平台的控制台 VNC 登录进去的，根本不走 SSH，所以系统认证日志里没记录。也就是说，排查“异常登录”不能只看系统日志，还要看云平台的管理操作记录。尤其是重装系统、重置密码、VNC登录、挂载云盘这些关键动作，都要纳入你的审查范围。

我自己现在的习惯是：重要服务器每周末打包一次认证日志，存到对象存储；日常的失败登录用 cron 脚本统计；真正的“成功登录且行为异常”事件，人工复核。这套流程坚持下来，再碰到“一图看懂一次异常登录服务器有没有记录”的问题，就不会再慌，因为你已经知道记录在哪里、怎么查、怎么让记录真正保护自己。