前言
作为一名运维人员/程序员，SSH 连接失败几乎是每次接触新服务器都会遇到的"第一关"。这次我在全新安装的 Debian 13 Trixie 虚拟机上，碰到了一个非常典型的"Ping 通但 SSH 死活连不上"的问题。由于 Debian 13 默认搭载的是 OpenSSH 10.0p2，这是一个非常新且安全策略极其严格的版本，导致很多基于旧版 OpenSSH 的排查经验失效。
本文将完整记录从最初的 Destination host unreachable 报错，到最终成功登录的全过程。这不是一份简单的命令集合，而是一套面向新手的、可复用的分层排查方法论，帮你在碰到 SSH 问题时不再盲目试错。
一、故障初现：从"网络不可达"开始
刚开始我在 Windows 宿主机上尝试 SSH 连接，结果连最基础的 Ping 都不通。
C:\Windows\System32>ping 10.172.100.33 Reply from 10.172.100.125: Destination host unreachable.
这个报错非常关键，它不是普通的"请求超时"，而是由本机网关直接返回的"目标主机不可达" 。这意味着数据包根本没有机会到达服务器，问题出在二层/三层网络链路层。
1.1 排查虚拟网络与 ARP 缓存
由于目标机是虚拟机，我首先怀疑是虚拟网络适配器状态异常。
-
操作步骤：
- 打开 Windows "网络连接"，找到对应的
VMware Network Adapter VMnet8（NAT 模式）或VMnet1（仅主机模式）。 - 右键选择"禁用"，等待 5 秒后重新"启用"，强制刷新 Windows 网络栈。
- 以管理员身份打开 CMD，执行
arp -d *清除所有僵死的 ARP 缓存条目。 - 再次 Ping 目标 IP。
- 打开 Windows "网络连接"，找到对应的
经过这一步操作，Ping 立即恢复正常。这说明之前的故障根源是 Windows 宿主机的虚拟网卡 ARP 表学习失败，导致找不到虚拟机的 MAC 地址。
二、进入深水区：Ping 通了但 SSH 连不上
网络层通了，本以为 SSH 连接会水到渠成，结果输入命令后直接卡住或被拒绝。这时候问题从"网络层"转移到了"应用层"。
2.1 第一阶段排查：端口连通性
在深入 SSH 协议细节之前，必须先确认最基础的 TCP 22 端口是否开放。
-
在 Windows PowerShell 中执行端口测试：
Test-NetConnection 10.172.100.33 -Port 22 -
结果分析：
- 如果
TcpTestSucceeded为False：说明防火墙拦截了 22 端口，或者 SSH 服务根本没启动。 - 如果为
True：说明端口是通的，问题出在 SSH 认证握手环节。
- 如果
我当时的测试结果显示 TCP 端口是连通的，这说明问题出在更高阶的 SSH 协议协商上。
三、终极调试：使用 ssh -v 输出详细日志
普通的 SSH 命令只会返回简单的"Permission denied"，根本看不出是哪一步出了问题。此时必须使用 Verbose 模式 开启详细调试。
ssh -v user@10.172.100.33
3.2 关键日志分析
在输出的大量日志中，我捕捉到了几个关键节点：
- 连接成功 ：
debug1: Connection established.------ 网络没问题。 - 版本匹配 ：
Remote protocol version 2.0, remote software version OpenSSH_10.0p2 Debian-7+deb13u4------ 确认服务端是最新的 OpenSSH 10.0。 - 算法协商成功 ：
kex: algorithm: curve25519-sha256------ 密钥交换和加密算法握手成功。 - 认证阶段卡住 ：
debug1: Authentications that can continue: publickey,password------ 服务器明确告诉客户端，它支持"公钥"和"密码"两种认证方式。 - 最关键的一行 ：
Enter passphrase for key 'C:\Users\Administrator/.ssh/id_rsa':
哦！原来问题出在这里。Windows 客户端本地有一个旧的 id_rsa 私钥，SSH 客户端默认会优先尝试公钥认证，它正在提示我输入这个本地私钥的解密密码（Passphrase），而不是服务器的登录密码。
我之前一直误以为这是在输服务器密码，导致反复输入错误。
四、强制跳过公钥，直接使用密码登录
既然服务器明确支持 password 认证，我可以强制 SSH 客户端跳过烦人的公钥尝试，直接走密码认证通道。
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no root@10.172.100.33
执行这条命令后，终端不再提示输入私钥 passphrase，而是直接正常显示了：
root@10.172.100.33's password:
然而，输入密码后依然返回了 Permission denied。
这说明最后一道关卡来了------Debian 13 的默认安全策略。
五、修改 Debian 13 SSH 配置，放行 Root 密码登录
Debian 13 作为前沿发行版，默认安全策略非常激进。它不仅默认锁定了 Root 账户，还在 SSH 配置中禁止了 Root 用户通过密码远程登录。
5.1 进入虚拟机控制台修改配置
由于无法 SSH，我直接在 VMware 虚拟机的本地终端中操作：
-
编辑 SSH 主配置文件：
sudo nano /etc/ssh/sshd_config -
找到并修改两个关键参数：
- 将
PermitRootLogin从prohibit-password改为yes。 - 将
PasswordAuthentication从注释状态或no改为yes。
- 将
-
特别注意覆盖配置 ： 很多人改了主配置文件还是不生效，这是因为 Debian 13 引入了
/etc/ssh/sshd_config.d/目录。云镜像或系统默认的片段文件（如50-cloud-init.conf）会覆盖主配置。必须进去检查，确保没有文件强行禁用密码登录。
5.2 Nano 保存退出（新手必看）
很多新手卡在了编辑器操作这一步，这里明确步骤：
- 改完内容后，按
Ctrl + O（字母 O）。 - 按 回车键 确认文件名，完成保存。
- 按
Ctrl + X退出 Nano。
5.3 重启 SSH 服务
` # 先检查配置语法是否正确，防止重启后服务挂掉 sudo sshd -t
语法无误后，重启服务
sudo systemctl restart ssh `
六、最终验证，连接成功
回到 Windows CMD，再次执行之前的强制密码登录命令：
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no root@10.172.100.33
输入正确的 Root 密码后，屏幕上终于出现了久违的命令提示符：
` Linux debian 6.11.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.11.2-1 (2025-11-13) x86_64
The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/...
root@debian:~# `
至此，整个调试过程圆满结束。
七、总结与最佳实践
这次排查过程让我深刻体会到，SSH 连接失败不是一个单一问题，而是一个分层的故障树。从下往上排查的思路非常重要：
- 物理层/链路层：Ping 不通，排查虚拟网卡、ARP 缓存、交换机。
- 网络层：Ping 通但端口不通，排查安全组、防火墙、服务是否启动。
- 传输层/应用层 ：端口通但认证失败，使用
ssh -v看日志，区分是算法协商失败还是密码/密钥权限问题。
对于 Debian 13 + OpenSSH 10.0 的新环境，强烈建议新手不要上来就折腾密钥，先用本文的方法强制开启密码登录，先把通道打通，后续再慢慢配置密钥免密登录，这样可以极大降低首次登录的调试门槛。