
首先用基础连通性测试区分问题类别。执行 ping、traceroute/tracert 或 mtr 从客户端到目标IP,观察是否有丢包或跳点超时,若链路在第三方交换节点卡住通常是网络问题;若能到达但 ssh TCP 连接被拒绝或挂起,则更可能是服务端/防火墙或sshd配置问题。
使用 ssh -vvv user@ip 查看握手详细流程,若显示“Connection refused”多为服务未监听或防火墙阻断,若在“kex_exchange_identification”阶段卡住可能是连接被中间设备重置或并发限制。查看端口开放:nmap -p 22 ip。
在服务端查看 /var/log/auth.log 或 journalctl -u ssh,客户端则保留 ssh -vvv 输出,网络侧保存 traceroute/mtr 结果以便与机房提供商沟通。
定位时重点关注 连通性、端口开放 与 握手日志 三项信息。
先确认 sshd 是否在监听:ss -tnlp | grep sshd 或 systemctl status sshd。若服务未运行,重启并观察错误:sudo systemctl restart sshd && sudo journalctl -xe -u sshd。检查 /etc/ssh/sshd_config 的配置项,如 Port、PermitRootLogin、AllowUsers/AllowGroups 以及 MaxStartups(并发连接限制)。
若是密钥或密码认证失败,检查权限(~/.ssh 目录应为 700,私钥文件 600),并核对公钥是否写入服务器的 ~/.ssh/authorized_keys。可临时开启 LogLevel DEBUG 在 sshd 中以获得更详细的认证日志。
1) 修复权限:chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys;2) 若配置有误,回滚或修正 /etc/ssh/sshd_config,再重启服务;3) 验证防火墙放行指定端口。
务必检查 sshd 状态、配置文件 与 用户权限。
在服务端查看本地防火墙(如 iptables、nftables、ufw):sudo iptables -L -n -v、sudo ufw status verbose 或 sudo nft list ruleset。若云提供商有安全组/ACL,登录控制台核对入站规则是否允许管理IP或0.0.0.0/0的TCP端口(默认22或自定义端口)。
若日志显示连接被重置或短时间大量连接被拒,可排查是否触发机房或提供商的安全策略(例如连接阈值、IP黑名单)。可联系机房提供商查看边缘防火墙日志或临时放宽策略。
在确认安全可控的前提下,临时放行管理IP段,或更换 SSH 端口并在安全组放通新端口;对于经常性断连,可考虑配置 JumpHost/跳板机 或 VPN 隧道把管理流量绕过公共链路。
重点检查 安全组、本地防火墙 与 机房边缘策略 三处规则。
首先用 mtr 或 iperf3 测试链路质量,定位是否存在丢包或带宽瓶颈。若发现特定跳点丢包,尝试更换出口、调整路由或与机房/运营商沟通。MTU 问题可通过抓包(tcpdump)或调整客户端/服务端的 MTU(如 ifconfig eth0 mtu 1400)进行验证。
在客户端/服务端设置保持活跃和重连机制可改善体验:在 ssh 客户端配置 ServerAliveInterval 60、ServerAliveCountMax 3;在服务器可调整 TCPKeepAlive、内核的 net.ipv4.tcp_retries2 等。
对于高延迟或不稳定链路,使用 autossh 建立持久隧道或通过 mosh 替代交互式会话以获得更好的抗丢包体验;必要时走 TCP 代理或 WireGuard/OpenVPN 隧道。
重点关注 丢包定位、MTU 调整 与 重连策略。
建立监控与告警体系是长期防护的关键。对 SSH 可用性 建立主动探测(如每分钟的端口监测、登录尝试监控),并把网络质量指标(丢包、延迟)纳入监控板。自动化故障恢复脚本(如故障自动重启 sshd、切换备机或自动触发运营商告警)能缩短故障时间。
使用配置管理工具(Ansible/Chef/Puppet)统一管理 sshd 配置与防火墙规则,定期核查并保留变更记录;定期审计登录记录与异常尝试以排除被滥用风险。
建议部署多可用区/多机房的管理出口、使用跳板机池、配置 BGP 多线或 SD-WAN 以实现链路冗余;对关键业务做流量限速和 QoS 策略,防止管理链路被业务流量挤占。
保持与机房/带宽提供商的SLA沟通与日志协作,定期演练应急预案。