SSH密钥认证本身不依赖系统时间，但TOTP、Kerberos、证书认证等时间敏感组件引入后，时间偏差超限（如TOTP超30秒、Kerberos超5分钟）会导致认证失败；纯公钥登录失败时应优先排查权限、配置及密钥完整性。
SSH 密钥认证本身不依赖系统时间，但若使用了基于时间的二次认证（如 TOTP、Kerberos 或某些 PAM 模块集成），或服务器启用了严格的时间敏感策略（如某些 FIDO2/WebAuthn 后端、或自定义的登录审计脚本），时间偏差过大可能间接导致认证失败。不过，**标准 OpenSSH 的公钥认证流程（RSA/Ed25519/ECDSA）完全不校验客户端或服务端时间**——它基于数学签名验证，与系统时钟无关。
先确认是否真和时间有关
很多用户误将“Permission denied (publickey)”归因于时间不同步，其实 SSH 服务端日志（/var/log/auth.log 或 /var/log/secure）中从不会出现“time skew”“clock drift”等提示。若怀疑时间问题，请先排除更常见的原因：
- 客户端私钥权限不是 600
- 服务端 ~/.ssh/authorized_keys 权限不是 600，或 ~/.ssh 目录不是 700
- sshd_config 中 PubkeyAuthentication yes 被注释或设为 no
- 公钥内容被手动编辑损坏（含不可见字符、换行、多余空格）
- 客户端未正确加载密钥（例如 ssh-agent 未启动，或未用 -i 指定）
哪些场景下时间确实会影响 SSH 登录？
只有当 SSH 认证链中引入了外部时间敏感组件时，时间偏差才可能成为瓶颈：
-
PAM + Google Authenticator（TOTP）：若配置了
auth [success=done default=ignore] pam_google_authenticator.so，且未加nullok或enforce，则客户端和服务端时间差超过 30 秒（默认窗口）会导致 TOTP 验证失败，最终表现为“Authentication failed” -
Kerberos 认证集成：OpenSSH 可通过
GSSAPIAuthentication yes启用 Kerberos。Kerberos 协议要求客户端和服务端时间偏差 ≤ 5 分钟（默认），否则票据（TGT）被拒绝 - 自定义 PAM 脚本或审计模块：某些企业环境会写脚本检查登录时间是否在白名单窗口内（如仅允许 9:00–18:00），这类逻辑依赖系统时间
- 证书认证（CA-signed SSH certificates）：若使用 OpenSSH 证书，其有效期字段（Valid after / Valid before）由服务端验证，时间严重偏差可能导致证书被判定为“尚未生效”或“已过期”
如何检查并修正时间同步状态
即使时间不影响纯密钥登录，保持时间同步仍是安全运维基本要求。排查步骤如下：
- 查看当前时间与 RTC 硬件时钟是否一致：
timedatectl status
重点关注 System clock synchronized: yes 和 NTP service: active - 检查 NTP 同步源是否可达：
timedatectl timesync-status（显示最近一次同步延迟）ntpq -p或chronyc sources -v（取决于使用 systemd-timesyncd / ntpd / chrony） - 强制立即同步（临时修复）：
sudo timedatectl set-ntp false && sudo timedatectl set-ntp true
或对 chrony：sudo chronyc makestep - 云服务器注意：部分厂商（如阿里云、腾讯云）提供内网 NTP 服务（如
ntp.aliyun.com），建议优先配置，避免公网 NTP 延迟或丢包
快速验证时间是否为根因
如果已启用 TOTP 或 Kerberos，可做最小化验证：
- 在服务端执行：
date -R和客户端执行相同命令，对比输出（注意时区）。偏差超过 30 秒即需同步 - 临时禁用 TOTP（注释 /etc/pam.d/sshd 中对应行），再试密钥登录。若成功，则时间是间接原因
- 对 Kerberos 场景，运行：
kinit username，看是否报错 Cannot contact any KDC for realm 或 Clock skew too great
