首先确认目标机器上运行的本地防火墙类型(如 iptables、nftables、ufw、firewalld)。检查规则是否允许来自你IP或网段的 端口22(或自定义的 SSH 端口)入站。还要关注是否有 fail2ban、csf 等动态阻断工具在生效。
常用检查命令包括:
sudo iptables -L -n -v
sudo nft list ruleset
sudo ufw status verbose
sudo firewall-cmd --list-all
若看到拒绝或 DROP 规则,需按业务策略调整规则顺序或新增允许规则。对生产环境建议先添加允许规则并测试,再移除可疑 DROP 规则,避免误封导致业务中断。
云平台通常在实例外层有网络访问控制(例如 AWS Security Group、Azure NSG、GCP Firewall)。确认这些规则允许来自你的客户端公网 IP 和所用端口的入站流量。注意安全组可能按子网或实例关联,且存在优先级或方向设置。
AWS: aws ec2 describe-security-groups --group-ids
Azure: az network nsg rule list --nsg-name
GCP: gcloud compute firewall-rules list --filter="name~'ssh|22'"
若你通过负载均衡或 NAT 网关访问,检查负载均衡器与后端实例之间的安全策略与端口映射。若使用弹性 IP 或临时公网 IP,确认规则中已包含对应 IP。
排查是否本地网络(公司防火墙、家庭路由器)或 ISP 对出站 端口22 做限制,有些网络出于安全会屏蔽出站 SSH。还需判断是否存在中间网络设备对某些区域(如新加坡)路由不通或丢包严重。
本地测试可用:
telnet <目标IP> 22 或 nc -vz <目标IP> 22
traceroute -T -p 22 <目标IP>(Linux) 或 tracert <目标IP>(Windows)
若 telnet/nc 连不上但能 ping 通目标,说明端口被阻断。
若怀疑 ISP 限制,可尝试用不同网络(手机热点或 VPN)测试;若手机热点可连通,则确定为本地网络/ISP 限制,需联系网络管理员或运营商解决。
确认 SSH 服务(通常是 sshd)已启动并监听期望的端口/地址,尤其要检查是否仅监听 127.0.0.1 或仅在私网地址上监听,导致公网无法访问。同时确认 sshd 配置(/etc/ssh/sshd_config)没有误配如更改 ListenAddress、Port、或使用 Match 限制。
查看监听:sudo ss -ltnp | grep sshd 或 sudo netstat -ltnp | grep :22
检查服务状态:sudo systemctl status sshd
查看配置:sudo grep -E '^(Port|ListenAddress|PermitRootLogin)' /etc/ssh/sshd_config
若发现 sshd 监听在非 0.0.0.0 或仅在私有IP,应修改 ListenAddress 或删除限制并重启 sshd。若改端口,需要同步更新云安全组和本地防火墙规则。
采用分层排查:先从网络层(连通性和路由)到传输层(端口是否开放)再到应用层(sshd 响应与认证)。收集证据(tcpdump、ssh -vvv、系统日志)用于判断是在网络丢弃、被防火墙拦截、还是服务拒绝。
客户端排查:ssh -vvv -p
端口扫描:nmap -Pn -p
服务器抓包(在目标机上):sudo tcpdump -n -i any port 22 -w /tmp/ssh.pcap(观察是否到达)
查看日志:sudo journalctl -u sshd 或 sudo tail -n 200 /var/log/auth.log
使用抓包请注意合规与隐私;若抓不到任何报文,说明流量在网络中被丢弃或未到达目标主机,此时应继续检查云防火墙或运营商路径。若能看到 SYN 到达但无响应,可能是本地防火墙或 sshd 未正确响应。