虚拟机SSH登录失败，多数情况集中在四个环节：网络是否可达、SSH服务是否在跑、认证配置是否对、防火墙与安全组是否放行。 按“从外到内”的顺序排查，先看报错形态，再逐层验证，基本不会走弯路。
报错信息先分类，别一上来就改配置
SSH连不上不是一种病,是十几种病共用一个症状，先看客户端吐出的那句英文，它已经告诉你该往哪个方向查。
| 客户端报错 | 大概率原因 | 优先检查位置 |
|---|---|---|
| Connection refused | 22端口没人监听、SSH服务没启动、防火墙直接拒绝 | 服务端进程、监听端口 |
| Connection timed out | 网络不通、安全组拦截、IP写错、路由缺失 | 网络层、云平台安全组 |
| Permission denied | 用户名错、密码错、密钥不匹配、权限过宽 | 认证配置、文件权限 |
| No route to host | 网段不通、虚拟网络模式不对、网关缺失 | 虚拟网络设置、路由表 |
| Host key verification failed | 服务端重装或IP复用，指纹变了 | 本地 known_hosts 文件 |
行业共识认为,把报错归类这一步省掉，后面的排查效率会掉一大截，因为拒绝和超时的处理路径几乎不重叠。
虚拟机SSH连接被拒绝怎么解决？按服务、端口、防火墙三层查
这类报错最“诚实”：包到了机器，但没程序接，问题基本都在服务端自己身上。
先确认SSH服务活着
登录虚拟机控制台或本地终端,依次执行：
systemctl status sshd（Debian/Ubuntu 上是ssh）ss -tlnp | grep :22看有没有进程监听22端口ps aux | grep sshd确认守护进程存在
如果提示服务不存在,说明系统压根没装：
- Debian系：
apt update && apt install openssh-server - RHEL系：
yum install openssh-server或dnf install openssh-server
装完立刻 systemctl enable --now sshd，开机自启和本次启动一起解决。相当一部分“新装系统连不上”，就是最小化安装没带SSH服务端。
再看监听地址和端口
打开 /etc/ssh/sshd_config，重点看四行：
Port 22：端口被改过，客户端必须加-pListenAddress：绑定了0.0.1时，外部永远连不上PermitRootLogin：多数云镜像默认prohibit-password或noPasswordAuthentication：关掉后只能用密钥
改完必须 systemctl restart sshd。只改配置不重启，等于没改，这是最高频的低级失误。
最后查防火墙
- Ubuntu：
ufw status，放行用ufw allow 22/tcp - CentOS/RHEL：
firewall-cmd --list-all，放行用firewall-cmd --add-port=22/tcp --permanent && firewall-cmd --reload - 老系统：
iptables -L -n看INPUT链有没有DROP
本机验证一步到位：在虚拟机里执行 ssh 用户名@127.0.0.1，本机能登进去，说明服务和认证都没问题，锅在网络或防火墙；本机都登不上，别折腾网络了，回头看服务。
Windows虚拟机连不上Linux服务器怎么办？方向搞反排查全白费
很多人卡在这一步：Windows那台是客户端，Linux那台才是服务端，搞混方向，查一整天也是原地转圈。
第一步确认链路通不通
在Windows的PowerShell里跑：
ping 192.168.x.x看基础连通性Test-NetConnection -ComputerName 192.168.x.x -Port 22直接测端口
第二条命令返回 TcpTestSucceeded : True，说明网络和端口都通，问题在认证层；返回False，继续往下查网络。
Windows 10以上自带OpenSSH客户端，命令行直接 ssh 用户名@IP 即可，不必额外装工具。
第二步看虚拟网络模式
VMware和VirtualBox的三种模式,决定了“谁能连到谁”：
- 桥接模式：虚拟机和宿主机在同一网段，其他机器也能访问，最省心
- NAT模式：虚拟机可以出网，外部主动连它需要做端口映射，宿主机直连虚拟网卡IP通常可行
- 仅主机模式：只有宿主机能访问，外部设备一律连不上
VMware在“编辑虚拟网络编辑器”里看NAT设置和端口转发；VirtualBox在“设置网络高级端口转发”里配。NAT模式下宿主机连不上，八成是没做22端口的转发规则。
第三步确认虚拟机自己拿到的是哪个IP
在Linux里执行 ip addr，别用记忆里的旧IP，虚拟机重启、DHCP续租、克隆之后IP变了是常事，Windows侧用 ipconfig 看VMnet8或VirtualBox Host-Only网卡的网段，两边对不上就是网络层的问题。
本地虚拟机和云主机SSH登录有什么区别？排查顺序正好反过来
同样是连不上,本地环境和云上的排查起点完全不同。
排查顺序差异
- 本地虚拟机：先查虚拟网络模式，再查服务，最后查系统防火墙，因为网络层最容易配错。
- 云主机：先查安全组和公网IP，再查服务，最后查系统防火墙，因为云平台的安全组在系统外层，优先级更高。
云上几个高频坑
- 安全组只放行了默认22端口,但你改过sshd端口，入方向规则没跟着改
- 按量付费实例关机再开机,公网IP变了，客户端还连着旧地址
- 实例只有私网IP,没绑弹性公网IP，从公网当然连不上
- 跨地域或跨VPC访问,对等连接建了但路由表没配，表现就是一直超时
- 重装系统或更换密钥对之后,本地
known_hosts里的旧指纹触发告警
遇到这些情况,最快的办法是走云厂商控制台的VNC远程登录或救援模式，进去改 sshd_config、放行端口，不用等SSH恢复。控制台是最后的入口，别把它忘了。
认证类失败：密钥和权限比密码更容易出错
Permission denied 说明网络和服务都通了，纯粹是身份没过，按这个清单对：
- 用户名是否写对,Ubuntu镜像默认用户是
ubuntu，CentOS是centos或root，云厂商定制镜像可能是ec2-user、admin - 权限是否过宽。
chmod 700 ~/.ssh、chmod 600 ~/.ssh/authorized_keys、chmod 600 ~/.ssh/id_rsa，家目录保持755，设成777会被sshd直接拒绝 - 公钥是否真的写进去了,用
ssh-keygen -y -f id_rsa从私钥推出公钥，和authorized_keys里的内容逐字符对比 - SELinux是否在拦。
restorecon -R -v ~/.ssh修复上下文 - 服务端
PubkeyAuthentication yes是否开启
定位靠日志最准：客户端加 -vvv，服务端看 /var/log/secure 或 /var/log/auth.log，握手卡在哪一步，日志里写得明明白白。
免费工具够用，不必迷信付费软件
ping、telnet、nc、traceroute、mtr 这些系统自带命令，能覆盖九成排查场景，Windows上用 Test-NetConnection，跨平台客户端用开源的PuTTY或Windows Terminal，都不花钱，真要看协议细节，服务端抓包 tcpdump -i any port 22 -nn，看SYN有没有回、握手停在哪一轮，比换工具更有用。
虚拟机SSH登录失败的排查,本质是沿着“网络可达端口监听认证通过”这条链逐段验证，报错信息就是路标。先分类报错，再按环境选对起点，绝大多数问题在一个小时内都能定位到具体那一层。
关于虚拟机SSH登录失败的常见问题
虚拟机SSH提示Connection refused，重启服务后还是不行怎么办？
先确认重启的是不是正确的服务名：Debian/Ubuntu是 ssh，RHEL系是 sshd，名字错了等于没重启，然后用 ss -tlnp | grep ssh 看实际监听端口，配置里改过 Port 的话，22端口本来就不会有进程，最后检查 ListenAddress 有没有被限制成回环地址。
改了SSH端口之后连不上，原来22端口还能用吗？
不能。sshd_config 里 Port 改成新端口并重启后，旧端口就停止监听了，客户端必须带 -p 新端口，或者写进 ~/.ssh/config 用 Host 别名固定下来，改端口时建议同时保留两行 Port，验证新端口能通后再删旧的，避免把自己关在门外。
云服务器安全组已经放行了，SSH还是超时是什么原因？
安全组只是第一道门,依次确认：实例是否绑定了公网IP或弹性公网IP；系统内部防火墙是否放行；sshd是否监听在 0.0.0 而不是仅回环；跨VPC或跨地域访问时路由表和对等连接是否生效，据云服务商官方文档，安全组规则修改后立即生效，但网络路由类配置的收敛需要一定时间，排查时留出间隔再测。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/773483.html
