id登录连接服务器失败，核心原因集中在账号认证错误、网络不通、服务端配置异常和安全策略拦截这四个层面，按顺序排查就能解决绝大多数问题。
id登录连接服务器失败原因：先从账号本身排查
服务器登录失败时，超过半数的案例其实出在账号层面，而不是服务器真的“拒绝”了你，这类问题最典型的表现是：密码输入正确但提示认证失败,或者密钥文件路径对不上。
账号密码与密钥文件的常见坑
- 密码中包含了特殊字符，、，在部分终端工具里被转义解析,导致实际发送的密码和真实密码不一致。
- 复制粘贴密码时，不小心带入了空格或者换行符，肉眼看不出来,但系统判定为错误密码。
- 使用密钥登录时，私钥文件的权限设置不对，OpenSSH有严格的安全要求，私钥文件权限必须是
600，属主必须是当前用户,权限过宽会直接被拒绝加载。 - 密钥格式不兼容，比如用
ssh-keygen -t rsa生成的OpenSSH格式密钥，和PuTTY使用的.ppk格式不通用,需要转换。
账号被锁定或过期
服务端配置了账号锁定策略，连续输错几次密码后，该id会被临时锁定，锁定期间无论密码多正确都无法登录，还有一种情况是账号设置了有效期，到了截止日期自动失效，用chage -l 用户名可以直接查看账号的过期时间。
排查账号问题的具体操作
先用本地管理工具尝试登录，如果能进，再用出问题的id试，如果本地能进但远程不行，基本锁定是远程认证环节出了偏差，此时可以检查服务端的认证日志，常见路径是/var/log/secure或/var/log/auth.log，日志里会明确记录“Authentication failure”还是“User not allowed”。
id登录不了服务器怎么解决：网络链路要逐段测
账号没问题但连接还是失败，紧接着要查的就是网络通路，这里的核心思路是分段测试,定位断点在哪一段。
Ping不通不等于连不上
很多用户习惯先用ping测网络，发现不通就判定服务器宕机，但实际上很多云厂商的安全组默认禁ping，或者服务器开了防火墙丢弃ICMP协议。ping通说明网络可达，ping不通不代表TCP端口不通，更可靠的做法是用telnet ip 22或nc -zv ip 22来测试目标端口是否开放。
端口不对与地址错误
id登录连接服务器时，默认走22端口（SSH）或3389端口（Windows远程桌面），如果服务端修改了监听端口，客户端还是用默认端口去连，就会报“Connection refused”或“连接超时”,连接时报错类型有讲究：
| 报错信息 | 可能原因 |
|---|---|
| Connection refused | 端口未监听或服务未启动 |
| Connection timed out | 网络不可达或防火墙丢包 |
| No route to host | 路由不通或主机宕机 |
本地网络环境干扰
公司网络或校园网经常有出口防火墙限制，只放行80和443端口，其他端口一律拦截，此时换个网络环境（比如手机开热点）测试，如果连接正常，那就是本地网络策略的问题,和服务器无关。
SSH登录服务器失败排查：服务端状态是关键
账号和网络都没问题，就需要把目光转向服务器本身，服务端的问题通常是SSH服务没启动、配置文件语法错误、或者监听了错误的IP地址。
确认SSH服务运行状态
通过云厂商的网页版VNC（管理终端）登录服务器，执行systemctl status sshd查看服务状态，如果显示active (running)，说明服务正常，如果显示failed或inactive，执行systemctl restart sshd尝试重启，重启无效时，检查/etc/ssh/sshd_config配置文件的语法，用sshd -t命令校验,语法错误会导致服务无法启动。
监听地址配置错误
sshd_config里的ListenAddress参数指定了服务监听哪个IP，如果这里写了一个内网IP，外部客户端通过公网IP连接时必然失败，这种情况在云服务器上比较容易出问题内网IP和公网IP的绑定关系容易搞混，检查该配置项，确认监听的是0.0.0（所有地址）或正确的公网网卡地址。
登录服务本身的配置陷阱
PermitRootLogin被设置为no，禁止root用户直接登录，如果用的id是root，会提示“Permission denied”。AllowUsers或DenyUsers配置了白名单/黑名单,未在名单内的用户即使密码正确也连不上。PasswordAuthentication被设为no，意味着只允许密钥登录，密码登录直接拒绝，行业共识认为，出于安全考虑关闭密码登录是推荐做法，但很多用户改完配置忘了这茬,导致自己也被挡在门外。
云服务器连接失败排查：安全组与防火墙策略
使用简米云、酷番云等云服务器时，还有一个单独需要关注的层面安全组规则，这是云环境特有的网络访问控制层,本地服务器没有这个概念。
安全组规则必须放行对应端口
登录云厂商控制台，找到实例所属的安全组，检查入方向规则，如果只放行了80和443，没有放行22（SSH）或3389（RDP），外部连接请求会在
云平台层面就被丢弃，根本到不了服务器操作系统，此时的表现通常是“连接超时”,因为请求被默默丢弃而不是被拒绝。
安全组修改后的生效时间
多数云厂商的安全组规则是即时生效的，但也有少部分场景存在1-2分钟的规则缓存延迟，改完规则后稍等片刻再重试，没必要反复修改同一规则,那样反而容易造成规则冲突。
操作系统防火墙与安全组双重叠加
云服务器上常常同时存在两层防护：云平台的安全组和操作系统自带的防火墙（iptables/firewalld），排查时要两者都看，曾有案例是安全组放行了22端口，但服务器内部firewalld默认zone没有放行ssh服务，导致最终连接失败，这类问题用firewall-cmd --list-all查看当前放行列表,确认ssh服务在列。
id登录连接服务器失败常见报错场景分析
不同报错对应的原因各不相同,掌握几个典型场景能快速缩小排查范围。
密码正确但反复提示认证失败
业内有经验的运维工程师普遍认为，这类问题多数是PAM模块配置出了问题，PAM是Linux的认证框架，/etc/pam.d/sshd文件里的配置如果被修改过，可能导致密码验证环节异常，检查该文件是否有异常的pam规则,必要时与同版本系统的默认配置做对比。
输入密码后卡住不动
密码验证通过后卡在登录界面，常见原因是DNS反向解析超时，sshd默认会尝试反向解析客户端的IP域名，如果DNS配置指向一个不可达的地址，整个登录过程会被拖住几十秒甚至更久，解决办法是在sshd_config里设置UseDNS no,然后重启sshd服务。
连接被立刻断开
连接成功后瞬间断开，没有任何错误提示，这通常是服务端预设的shell或环境变量出了问题，比如用户的默认shell被改成了一个不存在的程序，或者是/etc/motd、/etc/profile里有脚本执行报错导致会话退出。
登录连接失败的进阶排查思路
常规手段查不出问题时,可以尝试以下几条路径。
查看系统登录日志定位根因
日志是最直接的证据，SSH的登录尝试会记录在/var/log/secure或/var/log/auth.log中，用tail -f实时查看日志，然后在客户端发起一次登录操作，观察日志输出，日志中会出现具体错误码，比如Connection closed by authenticating user、Failed password for invalid user、User root from x.x.x.x not allowed because not listed in AllowUsers。
使用Verbose模式获取更多细节
SSH客户端支持-v参数，执行ssh -v 用户名@服务器IP，客户端会打印详细的握手过程，输出中标注debug1的行会显示每一个协商步骤，如果看到send_pubkey_test后服务端没有响应，而本地配置了密钥认证，问题大概率在服务端对公钥文件的识别上。
检查系统资源是否耗尽
服务器文件系统满了（df -h查看使用率100%）或者inode耗尽，会导致sshd无法创建临时会话文件，连接被异常终止，这类情况下，登录时会提示Cannot create temporary file或者直接连接断开,清理磁盘空间后问题自动消失。
id登录连接服务器失败怎么排查：实际回滚方案
问题解决后，为了防止再次发生,建议做一套完整的连接配置备份。
- 修改sshd_config前先备份：
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak_$(date +%F) - 修改配置后先校验语法：
sshd -t，返回无输出即表示语法正确 - 重启服务前确认当前会话不受影响：ssh服务重启不会断开已建立的连接，可以放心操作
- 记录正确的连接命令格式：
ssh -p 端口号 用户名@服务器IP，端口号默认22可省略
客户端工具重置连接
如果用的是Xshell、FinalShell等工具，连接失败后检查会话属性中的认证方法，有些工具默认优先使用“Password”认证，有些默认“Public Key”，两种方式混用时，工具可能先尝试密钥认证，失败后直接中止连接而不回退到密码认证，在工具设置里手动指定只使用密码认证,再重试。
id登录连接服务器失败问题解答环节
换个网络环境就能登录，但办公室不行，怎么回事？
办公室网络大概率做了端口限制，只允许特定端口出网，用手机热点测试能连上即可确认此原因，联系公司IT部门放行对应端口,或者申请使用跳板机。
控制台显示服务器正常运行，但id登录连接服务器失败，怎么定位？
先用网页版管理终端（VNC）登录服务器，在服务器本机执行ssh localhost测试，如果本机登录成功，说明sshd服务本身没问题，问题出在网络链路或安全策略，如果本机也登录失败,检查sshd配置和系统日志。
修改了sshd_config后重启服务失败，id完全无法登录了，如何恢复？
通过云厂商的VNC控制台进入服务器，找到配置文件的备份文件，执行cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config恢复默认配置，再执行systemctl start sshd启动服务，确认无问题后再逐步修改配置，每次修改后都要用sshd -t做语法校验。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/674603.html
