SSH账号登录失败的常见原因有哪些？

Question

SSH账号登录失败的常见原因包括：1）用户名或密码错误（含大小写、空格误输）；2）SSH服务未运行（`systemctl status sshd` 可验证）；3）防火墙或SELinux拦截（如iptables/ufw屏蔽22端口，或SELinux限制sshd_context）；4）用户被禁用或Shell配置异常（如`/etc/passwd`中Shell设为`/sbin/nologin`）；5）`/etc/ssh/sshd_config` 中禁用了密码认证（`PasswordAuthentication no`）或限制了允许用户（`AllowUsers`/`DenyUsers`）；6）公钥认证失败（`~/.ssh/authorized_keys` 权限过宽、属主错误或密钥格式不规范）；7）PAM策略或账户过期（`chage -l username` 查看）。排查建议：结合客户端`ssh -v`输出与服务端`journalctl -u sshd -f`日志交叉分析，快速定位根因。

Answer 1

```html

一、现象层：客户端可见的登录失败表现

用户执行 ssh user@host 后，常见反馈包括：Permission denied (publickey)、Connection refused、No route to host、Connection timed out 或直接卡在密码提示后无响应。这些表层现象是诊断的起点，但不可直接等同于根因。

二、协议层：SSH连接建立与认证流程解析

SSH协议分三阶段：TCP三次握手 → SSH版本协商（banner交换）→ 密钥交换与认证（密码/PAM/公钥）。任一环节中断即导致失败。例如，若服务端未响应TCP SYN-ACK，则问题必在网络或sshd进程层面；若已进入认证阶段却报错 Authentication failed，则需聚焦用户凭证、PAM策略或sshd_config策略配置。

三、服务层：SSH守护进程状态与依赖检查

• 验证服务运行：systemctl status sshd（注意：RHEL/CentOS 8+ 使用 sshd，Ubuntu 20.04+ 默认为 ssh）
• 检查监听端口：ss -tlnp | grep :22 或 netstat -tuln | grep :22
• 确认配置语法：sshd -t（返回空表示语法正确）
• 重启生效：systemctl restart sshd && systemctl enable sshd

四、安全策略层：防火墙、SELinux与网络策略拦截

组件	检查命令	典型修复
iptables/nftables	iptables -L INPUT -n | grep 22	iptables -I INPUT -p tcp --dport 22 -j ACCEPT
ufw	ufw status verbose	ufw allow OpenSSH 或 ufw allow 22
SELinux	sestatus; ls -Z /usr/sbin/sshd	setsebool -P sshd_can_network_connect on；若上下文异常，执行 restorecon -vF /usr/sbin/sshd

五、系统账户层：用户状态、Shell与生命周期控制

关键检查项：

1. id username 验证用户是否存在且UID/GID有效
2. grep "^username:" /etc/passwd 确认Shell非 /sbin/nologin 或 /bin/false（除非明确禁用交互登录）
3. chage -l username 查看账户是否过期、密码是否过期、最小/最大天数限制
4. getent passwd username 排查LDAP/NIS等外部源同步异常

六、SSH配置层：sshd_config核心策略深度剖析

以下配置项常被忽略却极具破坏性：

# /etc/ssh/sshd_config 示例片段
PasswordAuthentication no          # 密码认证全局关闭 → 公钥必须可用
PubkeyAuthentication yes
AllowUsers admin@192.168.1.* john   # 仅允许指定用户+IP白名单
DenyUsers guest
PermitRootLogin no
UsePAM yes

⚠️ 修改后务必执行 sshd -t && systemctl reload sshd，避免配置错误锁死远程会话。

七、认证载体层：公钥体系权限与格式合规性

公钥认证失败的“隐形杀手”：

• ~/.ssh/authorized_keys：权限必须 ≤600，属主必须为该用户（chown user:user ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys）
• ~/.ssh 目录：权限必须 ≤700（chmod 700 ~/.ssh）
• 密钥格式：OpenSSH格式（ssh-rsa AAAA...）不兼容旧版RSA密钥；Ed25519密钥需OpenSSH 6.5+支持

八、认证引擎层：PAM模块与策略链路追踪

PAM（Pluggable Authentication Modules）是Linux认证中枢。排查路径：

1. 查看PAM配置：cat /etc/pam.d/sshd
2. 检查是否加载了 pam_access.so（控制/etc/security/access.conf）、pam_time.so（时间策略）、pam_faillock.so（防暴力锁定）
3. 测试PAM行为：ssh -o PubkeyAuthentication=no user@host 强制走密码路径，隔离公钥干扰

九、日志协同分析法：客户端与服务端日志交叉定位

graph LR
  A[客户端 ssh -vvv user@host] -->|输出详细协商过程| B(识别失败阶段：kex, auth, connection)
  C[服务端 journalctl -u sshd -f] -->|实时日志流| D(匹配timestamp + PID + message)
  B --> E{比对关键线索}
  D --> E
  E --> F[例：'Failed password for user from X.X.X.X port Y' → 密码错误或PAM拒绝]
  E --> G[例：'User user not allowed because account is locked' → PAM或/etc/shadow锁定]
  E --> H[例：'Connection closed by authenticating user' → authorized_keys权限/格式问题]

十、高阶防御视角：自动化诊断脚本与生产级加固建议

面向5年以上经验工程师，推荐构建如下能力：

• 编写Bash诊断脚本，集成 sshd -T（dump当前生效配置）、ausearch -m avc -ts recent（SELinux审计）、faillog -u username（登录失败计数）
• 生产环境应启用 LogLevel VERBOSE 并轮转日志（/etc/logrotate.d/sshd）
• 禁用密码认证后，强制使用证书签名的SSH CA（TrustedUserCAKeys），替代分散管理authorized_keys
• 结合auditd监控 /etc/ssh/sshd_config 和 /etc/passwd 文件变更，实现安全基线告警

```