连接SSH服务器被拒绝访问,通常不是密码错,而是TCP连接在到达sshd前就被拒绝,最常见是sshd未运行、端口未监听、防火墙或云安全组REJECT、端口改错、监听地址限制、fail2ban拦截。 如果看到“Connection refused”,优先查端口监听和拒绝规则;Connection timed out”,优先查网络链路和DROP策略。
为什么连接ssh服务器被拒绝访问:先分清拒绝、超时和认证失败
Linux服务器ssh拒绝连接和超时有什么区别
很多人把SSH报错都叫“连不上”,但服务端给的反应完全不同。Connection refused说明TCP层收到明确拒绝,Connection timed out说明数据包被丢弃或路由不通,Permission denied说明已经连上sshd,只是认证没过。
| 报错文字 | 含义 | 典型原因 | 排查入口 |
|---|---|---|---|
| Connection refused | TCP收到RST | sshd没启动、端口未监听、防火墙REJECT、安全组拒绝 | nc -vz IP 22、ss -tlnp |
| Connection timed out | 数据包无响应 | 网络不通、防火墙DROP、路由错误、安全组未放行 | ping、mtr、安全组 |
| Permission denied | 认证失败 | 密码错、密钥错、用户被禁、权限目录不对 | ssh -vvv、journalctl -u sshd |
| Connection reset by peer | 连接被重置 | fail2ban、防护软件、并发限制、协议不匹配 | fail2ban-client status sshd |
| No route to host | 没有路由 | IP错误、路由表、ARP、上游网络限制 | ip route、traceroute |
从报错文字判断故障层级
- 拒绝:对方明确说“不”,通常不是密码问题,而是端口、监听地址、防火墙或安全组。
- 超时:对方没回话,优先看云安全组、系统防火墙DROP规则、路由和运营商链路。
- 认证失败:SSH服务已通,看
/var/log/secure或/var/log/auth.log,检查用户、密钥、权限。 - 重置:连接被中途掐断,常见于fail2ban、云锁、安全狗、堡垒机策略。

行业共识认为,SSH排障要先把TCP连通性和认证问题拆开,否则会在密码和密钥上绕很久,实际服务端根本没监听22端口。
云服务器SSH端口22被拒绝访问怎么办:本地、网络、服务端三段排查
先在本机做三项验证
不要一上来就改服务端,先在本地确认目标端口是否可达:
ping 服务器IP:只能说明ICMP通,不代表22端口通。nc -vz 服务器IP 22:出现succeeded,说明TCP端口可达;出现refused,说明被拒绝。ssh -vvv user@服务器IP:看卡在哪一步,是连接阶段、密钥交换,还是认证阶段。telnet 服务器IP 22:如果没有nc,可以用telnet看TCP层。mtr 服务器IP:如果超时,用mtr看丢包发生在哪一跳。
如果nc直接返回refused,别再看密码,服务端端口没开,或者中间设备明确拒绝。
北京云服务器SSH连接被拒绝时先看安全组
云服务器和物理机最大的区别,是控制台里有一层安全组或网络ACL,北京地域、华北地域还是其他地域,逻辑都一样:入方向没放行22,外部就被拒绝或超时。
- 入方向规则:协议TCP,端口22,源IP写你的公网出口IP。
- 临时测试可写
0.0.0/0,但测完要收回,避免全网扫描。 - 检查弹性公网IP是否绑定,服务器是否有公网IP。
- 检查内网IP是否变化,本地hosts或DNS是否还解析旧IP。
- 检查网络ACL、子网ACL、云防火墙是否额外拦截。
- 少数网络环境可能限制22端口,可临时换2222等高端口测试。
公司内网连接云服务器SSH被拒绝的常见场景
公司网络里,SSH被拒绝往往不是服务器坏了,而是出口策略变了。
- 公司出口IP变化,安全组只放行旧IP。
- 公司防火墙禁止出站22,换手机热点就能连。
- 通过堡垒机或跳板机连接,
ProxyJump配置错误。 - 本地DNS解析到旧内网IP,实际连错机器。
- 本地杀毒软件、终端防护拦截出站22。
- 多网卡环境,路由优先级导致走了错误网卡。

低价VPS SSH连接被拒绝访问是否与厂商限制有关
低价VPS的“被拒绝”经常和网络模式有关,不一定是系统问题。
- 共享IPv4或NAT模式,公网端口不是22,控制面板会给你一个映射端口。
- 服务商默认封锁22、25等端口,需要工单申请。
- 面板防火墙没放行,系统内防火墙也放行也没用。
- IP被黑洞或封禁时,可能表现为超时,也可能表现为拒绝。
- 没绑定公网IP的机器,只能走内网、跳板机或VNC控制台。
价格低本身不会导致SSH拒绝,但低价方案常用NAT、共享IP和集中防护,排查顺序要变。
sshd配置与系统防护导致的拒绝
端口、监听地址和用户白名单
登录云控制台VNC或通过其他方式进系统后,先查sshd:
systemctl status sshd:看服务是否active。ss -tlnp | grep sshd:看实际监听IP和端口。grep -E '^(Port|ListenAddress|PermitRootLogin|AllowUsers|DenyUsers)' /etc/ssh/sshd_config:看配置。sshd -t:检查配置语法。journalctl -u sshd -n 100:看最近日志。
如果看到0.0.1:22,说明只监听本机,外部连接必然拒绝,要把ListenAddress改成0.0.0,或注释掉默认监听,改端口后,云安全组和系统防火墙都要同步放行。
fail2ban、hosts.deny与SELinux
fail2ban-client status sshd:看是否封了你的IP,解封命令:fail2ban-client set sshd unbanip 你的IP。/etc/hosts.deny:如果存在sshd: ALL,会被tcp_wrappers拦截。getenforce:SELinux enforcing时,非标准SSH端口可能被拒绝。- 非标准端口需放行SELinux:
semanage port -a -t ssh_port_t -p tcp 2222。 - 云锁、安全狗、堡垒机、WAF也会拦截高频连接。
据国家互联网应急中心公开信息,弱口令和暴力破解一直是互联网主机常见风险,业内专家指出,暴露在公网的22端口更容易遇到扫描和爆破,因此很多环境会主动限制来源IP。

实战修复流程:按顺序执行
- 本地执行
nc -vz 目标IP 22,refused就查服务端和安全组;timeout就查网络和DROP规则。 - 登录云控制台,确认安全组入方向放行TCP 22,源IP限制为你的公网IP。
- 进系统执行
systemctl status sshd,确保服务运行。 - 执行
ss -tlnp | grep :22,确认监听0.0.0:22或[::]:22。 - 检查系统防火墙:
ufw status、firewall-cmd --list-all、iptables -L -n、nft list ruleset。 - 放行命令示例:
ufw allow 22/tcp;firewall-cmd --add-port=22/tcp --permanent && firewall-cmd --reload;iptables -I INPUT -p tcp --dport 22 -j ACCEPT。 - 检查
fail2ban,解封自己的IP。 - 修改
/etc/ssh/sshd_config后,先保留一个已登录会话,再执行sshd -t和systemctl reload sshd。 - 如果改端口,安全组、系统防火墙、SELinux、fail2ban都要同步改。
- 仍不通时,用VNC登录,抓包
tcpdump -i any port 22,看请求有没有到达服务器。
连接SSH被拒绝访问,先看TCP层是否可达,再看sshd和认证。 把拒绝、超时、认证失败分开,排查速度会快很多。
Q&A:为什么连接ssh服务器被拒绝访问
为什么连接ssh服务器被拒绝访问但ping得通?
ping通只说明ICMP可达,不代表TCP 22监听,sshd没运行、监听在127.0.0.1、防火墙REJECT、云安全组只放行ICMP,都会出现ping通但SSH拒绝。
为什么连接ssh服务器被拒绝访问在换网络后恢复?
原网络出口IP可能被安全组拒绝,或公司防火墙拦截出站22,或运营商NAT限制,换手机热点、换宽带后恢复,基本能定位到源IP或中间网络策略。
为什么连接ssh服务器被拒绝访问时telnet 22端口也失败?
telnet失败说明TCP层没有建立,需要检查sshd是否监听、云安全组是否放行、系统防火墙是否REJECT、端口是否被改、监听地址是否限制为本机,若服务器没有公网IP,只能通过内网、跳板机或控制台VNC进入。
图片来源于AI模型,如侵权请联系管理员。作者:酷小编,如若转载,请注明出处:https://www.kufanyun.com/ask/873745.html


评论列表(3条)
这篇文章写得非常好,内容丰富,观点清晰,让我受益匪浅。特别是关于服务器的部分,分析得很到位,给了我很多新的启发和思考。感谢作者的精心创作和分享,期待看到更多这样高质量的内容!
这篇文章写得非常好,内容丰富,观点清晰,让我受益匪浅。特别是关于服务器的部分,分析得很到位,给了我很多新的启发和思考。感谢作者的精心创作和分享,期待看到更多这样高质量的内容!
这篇文章写得非常好,内容丰富,观点清晰,让我受益匪浅。特别是关于服务器的部分,分析得很到位,给了我很多新的启发和思考。感谢作者的精心创作和分享,期待看到更多这样高质量的内容!