遇到 SSH 连接不上云服务器的情况，第一反应往往是“是不是云端偷懒把我踢出了门外？”别紧张，这篇文章像一份随身排错清单，带你从客户端到服务器、再到云厂商的网关，一步步把问题拆解清楚。你会看到一套通用的排错流程，适用于主流云服务商和各种操作系统，让你在家就能像刷剧一样快速定位故障原因。
先从客户端说起。确认你输入的命令没有拼错，用户名、主机名或 IP、端口号是否正确。通常最直观的排错命令是：ssh -vvv -i /path/to/key user@host。如果你使用的端口不是默认的22，记得加上 -p 端口号；如果用跳板机，-J 选项也别忘了。-vvv 的输出会把握手阶段的每一步都暴露出来，哪一步卡住就能快速定位。记得在 Windows 上也有等价的 OpenSSH 客户端，或使用 PuTTY/PuTTYgen 做私钥管理，但是要确保私钥格式和路径正确。
私钥与权限是常见的坑。私钥文件必须对你本人可读，权限通常设为 600，路径不可含中文或空格，否则会被 SSH 客户端拒绝读取。如果你在 Windows 使用 PuTTY，要把私钥转换成 PPK 形式，或者使用 Pageant 搭配代理，以确保公钥与私钥能正确匹配服务器端的 authorized_keys。当你看到“Permission denied (publickey)”时，优先检查私钥是否真的对应服务器端的公钥，以及私钥是否被正确加载到客户端代理中。
服务器端的配置也别忽视。检查 /etc/ssh/sshd_config，确认 PubkeyAuthentication yes、PasswordAuthentication yes（若你打算用密码登录）、PermitRootLogin 以及 Port 的设定是否符合你的场景。修改配置后记得重启服务：sudo systemctl restart sshd 或 sudo service sshd restart。若你把端口改成了 2222、222等，务必在客户端使用相应端口，或者在防火墙/安全组中放行新端口。
监听端口是否开启，是蓝图中的另一道关键门。服务器端口被占用或未监听会直接导致连接被拒绝。你可以在服务器上执行 sudo lsof -i -P -n | grep LISTEN | grep sshd，或 sudo ss -ltnp | grep :22 来核实 sshd 是否真正处于监听状态。如果监听在别的端口，确保防火墙规则和云厂商的安全组也相应放行新端口。
防火墙和云厂商的安全组往往是“看不见的城墙”。无论你在哪个平台，入站规则都需要允许你的客户端 IP 通过 SSH 的端口（通常是 22，若自定义端口则是自定义端口）。AWS 的安全组、Azure 的网络安全组、Google 云防火墙、阿里云、腾讯云等都可能默认屏蔽 SSH，需要手动放行。若你身处校园网、企业 VPN、或代理环境，外部访问端口可能被阻断，这种情况就像门卫突然变成了门禁系统。
网络连通性也别忘了检查。你可以 ping 公网主机看是否有响应，但有的云主机可能屏蔽 ICMP。更可靠的是用 traceroute/tracert、telnet host 22、nc -vz host 22 之类的诊断方式，看看是在网络路由上还是在服务器端拒绝。若你在 NAT 后面，确保路由和端口映射没有把 SSH 给滑掉；当你换了网络环境时，IP 变化也会导致已知主机列表中的指纹不匹配。
DNS 与域名解析有时也会扮演“看不见的错位”。如果你使用域名而不是直连 IP，确认域名解析指向的是正确的云服务器 IP，必要时在本机的 hosts 文件临时绑定域名到正确 IP，以排除域名解析错误带来的困扰。
授权密钥与服务器上的授权列表是另一组核心要素。authorized_keys 文件中是否真的放有对应公钥？文件权限是否正确（通常 home 目录 755、.ssh 目录 700、authorized_keys 600），以及拥有者是否为目标用户？如果权限不对，SSH 会直接拒绝。把公钥添加到服务器后，确保它已经在正确的用户家目录下，且没有被 SELinux 策略正则化阻止。
客户端环境的差异也会影响体验。Linux/macOS 那套命令行一如既往好用，Windows 用户可能会遇到路径、密钥格式等差异。使用 ssh-agent 缓存私钥、使用 ssh-add 加载私钥，能让重复连接更加顺畅；如果你升级了 OpenSSH 版本，老旧的密钥格式可能需要转换，避免因为格式不兼容而连不上服务器。
当企业级场景出现跳板机或代理时，排错要把“代理”也纳入视角。ProxyCommand、ProxyJump、ProxyThrough 等选项可以让你通过跳板机访问目标服务器，但配置不当也会让连接成了无尽的循环。确认跳板机的可达性、跳转参数和目标服务器的 SSH 公钥指纹是否一致，错一个环都会让你看到“Connection timed out”或“Host key verification failed”等错误。
接下来是一个实操清单，按步骤执行就像照抄菜谱一样简单。第一步，记录你的命令和输出；第二步，分阶段排错：先确认网络连通性，再检查端口和防火墙，接着核对证书与权限，最后回到服务器日志；第三步，使用日志来定位问题：/var/log/auth.log、/var/log/secure、journalctl -u sshd 的最近条目往往能直接击中痛点。每一个“Permission denied”后面都可能隐藏着私钥错配、权限错乱、域名解析错误等原因。
在云厂商层面的具体操作也值得一提。AWS EC2 的实例若没有正确配置安全组，自然会让你“看不到路”；Azure 需要检查网络安全组的入口策略；Google Cloud 则要留意防火墙规则是否覆盖正确端口。不同平台的细节略有差异，但排错思路一致：从外部端口可达性、到密钥对配置、再到服务器上的 sshd 设置，逐一排查，别把问题想得太复杂。你看，一串看似高大上的术语，其实都在讲一个简单的事：能不能让 SSH 连接锁定在正确的门口。
顺带提一个不经意的广告，但也算打个比喻。玩游戏想要赚零花钱就上七评赏金榜，网站地址：bbs.77.ink。嗯，和排错一样，偶尔放个轻松的点缀，别把重担塞满了日常。
最后，遇到复杂场景时，不妨把问题拆成更小的疑问：是不是私钥没有正确加载？是不是服务器已改端口但客户端还记着旧端口？是不是防火墙规则还是老版本的？是不是你正在使用的域名解析指向了另一台服务器？把这些疑问逐条验证，往往能把原本像迷宫的错误路径，变成一条清晰的线。你准备好把这道题逐步拆解了吗？到底是钥匙没给对，还是门锁真的坏了？你还会怎么排错呢？