当进行 SSH 连接时抛出 kex_exchange_identification: Connection closed by remote host,如果你使用了代理工具,那基本上为代理的问题。

可能出现该错误的原因:网络中断、不稳定等,端口连接失败(本地或代理的防火墙)

最小复现:选择一个无法连接的节点,或在连接途中切换网络环境(或节点)

方案

  1. 不使用代理。如果是和 Github 进行交互可以选择 Https 方式进行。

    git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.git
  2. 在 "Https" 端口上使用 SSH

通过 443 端口连接 SSH

前提:SSH 服务需要支持该端口,如 Github

大多数规则(或防火墙)都不会对 443 端口进行限制(基本上你能访问 Https 站点即代表 443 是放行的)

当然,在配置之前可以先测试 443 的连通性(注意:支持 443 端口的域名为 ssh.github.comgithub.com

ssh -T -p 443 git@ssh.github.com

若如下输出,则表明连接成功

Hi username! You've successfully authenticated, but GitHub does not provide shell access.

覆盖 SSH 的默认行为

确保刚才的测试指令可以连通 443 端口

编辑 ~/.ssh/config(win:用户目录/.ssh),即可无感切换端口连接 SSH

for Linux:若无该配置文件,保存时会自动创建

vim ~/.ssh/config

ssh.github.com 该域名同样也支持默认端口 22

Host github.com
    Hostname ssh.github.com
    Port 443
    User git

测试

注意这里使用的是原来的域名 github.com,对使用来说无感知

$ ssh -T git@github.com
# Hi USERNAME! You've successfully authenticated, but GitHub does not
# provide shell access.

不同端口的连接(开启 TUN 模式,可在代理软件中查看相关连接)

至此教程结束

相关知识

SSH known_hosts

当使用 SSH 连接新的服务时(如 ssh.github.com),SSH 会展示目标服务的公钥指纹用于验证服务。当输入 yes 后,服务器公钥将会被保存至 ~/.ssh/known_hosts 中用于后续连接时的公钥验证

# The authenticity of host '[ssh.github.com]:443 ([140.82.112.36]:443)' can't be established.
# ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
# This host key is known by the following other names/addresses:
#     ~/.ssh/known_hosts:32: github.com
# Are you sure you want to continue connecting (yes/no/[fingerprint])?

Github 提供的 SSH 密钥指纹,可添加至 known_hosts 文件中,避免在连接时手动验证(验证也仅在第一次)

终端代理 与 TUN 模式

通过 export http_proxy=http://127.0.0.1:7890 all_proxy=socks5://127.0.0.1:7890 可在终端设置 代理的环境变量

需要注意的是,一些命令如 SSH、PING 等由于自身实现,或传输层限制等无法使用终端代理,此时可以打开代理工具的 TUN 模式来解决。

TUN 模式相当于给系统安装虚拟网卡,可以捕获所有类型的流量,即便代理只支持 TCP 或 UDP 的流量,如 ICMP 层的 PING。该模式是无感的,可以快速的接管不支持 系统代理 的应用

总结

如果你之前一直使用代理来连接 SSH,只是偶尔出现该情况,那建议更换代理服务,或暂时关闭代理直接连接。

链接

Using SSH over the HTTPS port