SSH本地端口映射建立成功，但扫描时却连接报错怎么办？

SSH服务映射与扫描是系统管理和安全审计的关键环节,用于发现资产、评估暴露面，但此过程常遇各类报错，影响效率，本文旨在系统梳理常见的SSH扫描报错及其解决方案，从网络层到应用层，帮助读者快速定位并解决问题。

网络连接层面问题

这是最基础的障碍,表现为客户端无法与服务器建立TCP连接。

典型报错： Connection timed out, No route to host, Connection refused

• Connection timed out (连接超时):

  • 可能原因: 防火墙（服务器端、客户端或中间网络设备）拦截了22端口；服务器IP地址或域名填写错误；服务器本身未开机或网络不可达。
  • 排查思路:
    1. 使用 ping <目标IP> 测试基础网络连通性。
    2. 使用 telnet <目标IP> 22 或 nc -zv <目标IP> 22 测试端口是否可达，若不通，则重点检查防火墙规则（如服务器的 ufw, firewalld）和路由路径。

• Connection refused (连接被拒绝):

  • 可能原因: 目标服务器上的SSH服务（sshd）未启动；或服务监听了非标准端口。
  • 排查思路:
    1. 登录目标服务器,使用 systemctl status sshd (或 sshd.service) 检查服务状态。
    2. 若服务未运行,则执行 systemctl start sshd 启动服务，并设置开机自启 systemctl enable sshd。
    3. 使用 netstat -tulnp | grep sshd 或 ss -tulnp | grep sshd 确认服务监听的端口是否为预期的22端口。

身份验证与权限问题

网络连接成功,但在认证阶段失败。

典型报错： Permission denied (publickey,password).

• 可能原因:

  1. 凭据错误: 用户名或密码不正确。
  2. 密钥问题: 使用了错误的私钥文件；公钥未正确添加到服务器对应用户的 ~/.ssh/authorized_keys 文件中；authorized_keys 文件或其上层目录（~/.ssh、）的权限过于宽松（sshd服务有严格的安全要求）。
  3. 服务配置限制: 服务器 /etc/ssh/sshd_config 配置文件中，禁用了密码认证（PasswordAuthentication no）或公钥认证（PubkeyAuthentication no）。

• 排查思路:

  

  1. 手动尝试SSH登录,确保凭据无误。
  2. 检查服务器上 ~/.ssh/authorized_keys 文件内容，确保客户端公钥已正确添加。
  3. 确保服务器端文件权限正确：chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys。
  4. 检查 sshd_config，确认认证方式已启用，修改后需重启 sshd 服务。

协议与算法兼容性问题

客户端和服务器的SSH协议版本或支持的加密算法不匹配。

典型报错： Protocol major versions differ, Unable to negotiate with <host> port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1, no matching cipher found. Their offer: aes128-cbc

• 可能原因:

  1. 协议版本过旧: 服务器仍在使用不安全的SSHv1协议，而现代客户端仅支持SSHv2。
  2. 算法集不兼容: 服务器或客户端为了安全，移除了对方支持的某些密钥交换（KEX）、加密或消息认证码（MAC）算法。

• 排查思路:

  1. 修改服务器 /etc/ssh/sshd_config，确保包含 Protocol 2。
  2. 在服务器 sshd_config 中，通过 KexAlgorithms, Ciphers, MACs 指令，添加或保留一些兼容性较好的算法。
  3. 临时方案：在客户端SSH命令中通过 -o 选项指定对方支持的算法，ssh -o KexAlgorithms=diffie-hellman-group1-sha1 user@host，但这仅为应急措施，长远看应升级服务器配置。

主机密钥验证问题

客户端发现服务器的主机密钥与本地记录的不符。

典型报错： Host key verification failed., WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

• 可能原因:

  1. 服务器重装了操作系统或重新生成了SSH主机密钥。
  2. 该IP地址被分配给了另一台新的服务器。
  3. （严重情况）遭遇中间人攻击。

• 排查思路:

  

  1. 确认服务器身份变更的合理性,如果是因重装等原因，可以安全地更新本地缓存。
  2. 执行 ssh-keygen -R <目标主机名或IP>，从本地的 ~/.ssh/known_hosts 文件中移除旧的密钥记录。
  3. 再次尝试连接,SSH客户端会提示接受新的主机密钥，确认后即可建立连接，切勿盲目忽略此警告。

---

为了更直观地对比,下表小编总结了上述问题的排查要点：

错误类型	典型报错信息	可能原因	核心排查思路
网络连接	Connection timed out	防火墙拦截、IP错误、服务宕机	ping, telnet/nc 测试连通性与端口可达性
身份验证	Permission denied	密码/密钥错误、服务端配置限制	检查凭据、authorized_keys文件及权限、sshd_config
协议兼容	no matching key exchange	SSH版本、加密算法集不兼容	更新服务端配置，或客户端临时指定兼容算法
主机密钥	Host key verification failed	服务器密钥变更、IP重用	确认变更原因，用 ssh-keygen -R 清理旧记录

---

相关问答FAQs

Q1: 在使用Nmap等工具扫描SSH端口时，结果常显示“ssh-open”或“ssh-closed”，但有时端口明明是开放的，Nmap却报告为“filtered”，这是什么原因？

A: “filtered”状态意味着Nmap无法确定端口是开放还是关闭，因为网络设备（如防火墙、ACL）丢弃了探测包，没有返回任何响应（如RST或ICMP错误），与“closed”状态（目标主机主动返回RST包，明确表示端口关闭）不同，“filtered”表明探测请求被某种策略阻止了，要解决此问题，需要检查从扫描源到目标服务整条路径上的防火墙规则和安全组策略，确保它们允许来自扫描源的流量到达目标22端口。

Q2: 当我手动SSH连接一台新服务器时，提示“Are you sure you want to continue connecting (yes/no/[fingerprint])?”，这个提示和扫描报错中的“Host key verification failed”有什么关系？

A: 这两者都与SSH主机密钥验证机制紧密相关，但处于不同阶段，首次连接时的“Are you sure…”提示，是因为你的本地 known_hosts 文件中还没有这台服务器的公钥记录，SSH客户端在让你确认并信任这个新的“身份”，一旦你输入“yes”，客户端就会保存服务器的公钥，而“Host key verification failed”错误则发生在你已经连接过一次之后：当你再次连接时，客户端发现服务器发来的公钥与本地保存的记录不匹配，它怀疑服务器的身份可能已被冒充（IP被劫持或服务器被重装），因此为了安全而拒绝连接，并报出此错误，简而言之，前者是“初次见面，请验证身份”，后者是“再次见面，您的身份变了，有风险！”。