☰

从 5.3 客户端到 7.4 服务器的 ssh 连接问题

tag-icon • tag-icon centos ssh
从 5.3 客户端到 7.4 服务器的 ssh 连接问题

我们有这样的设置：

  • centos 6 上的客户端 openssh 5.3
  • centos 7 上的 nginxplus 流代理（将自定义 ssh 端口代理到 gitlab 服务器端口 22）
  • 运行 openssh 7.4 的 gitlab 服务器

我们无法从客户端通过 ssh 连接到服务器。我们可以从其他地方连接到ssh服务器。我们可以连接到自定义 tcp 端口，在运行 ssh 客户端命令时，我们会在该端口上看到 tcp 连接。但没有数据被代理到 gitlab 服务器，可能是因为客户端不提供数据。

我们还尝试启动与客户端主机的 ssh 会话，并将端口转发到代理/gitlab 服务器，以便我们可以从客户端节点 IP 进行连接，但使用较新的客户端。这确实有效，因此我们认为这不是防火墙或类似拒绝主机的问题。我们更新了客户端节点上的 ssh 主机密钥，但这也没有效果。

连接时，我们在 tcpdump 中看到它并没有开始协商 ssh 协议。我们认为这可能与客户端版本有关，或者可能我们缺少配置设置，但我不知道是什么。

[root@clienthost ~]#  ssh -i ~/.ssh/id_rsa [email protected] -p $CUSTOMPORT -vv
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /root/.ssh/config
debug1: Applying options for gitlab.test.fqdn
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to gitlab.test.fqdn [a.b.c.d] port $CUSTOMPORT.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1

据我了解，这主要与旧的 rsa 1 协议有关，对于 rsa 2 来说并不重要。 id_rsa 文件的权限是0400 顺便说一句，它也不适用于除 root 之外的其他用户。

ssh客户端配置：

Host gitlab.test.fqdn
  HostName gitlab.test.fqdn
  User git
  IdentityFile /root/.ssh/id_rsa
  Port $CUSTOMPORT

在 id_rsa 文件属性的注释后进行编辑

还修复了 file 命令将 id_rsa 报告为 ASCII 文本文件的问题，现在它报告 pem rsa 私钥文件

有人对我遗漏的内容或可能出错的内容有任何想法吗？

答案1

如果您运行nc -v gitlab.test.fqdn $CUSTOMPORT或telnet gitlab.test.fqdn $CUSTOMPORT，并且代理以与 SSH 直接兼容的方式工作，您应该立即获取 SSH 服务器版本字符串。

该字符串应如下所示：

SSH-2.0-<something...>

如果代理被意外错误配置为期望 HTTP 协议，连接将成功，但不会有初始响应。在 HTTP 中，客户端应该先发言，而 SSH 协议则要求服务器端先发言。

（支持 HTTP 代理的客户端可以然后使用 HTTPCONNECT请求连接到指定目的地的指定端口，但这将允许客户端选择代理连接的目的地，这显然不是您想要的。）

答案2

我们在 nginx 中启用了 ssl_preread，这显然会阻止服务器优先协议和版本公告。关闭此功能后，服务器会首先发送协议和版本，一切都会按预期进行。

telcoM 的回答对此有很大帮助，所以谢谢！但我想发布具体的配置更改作为解决方案。

相关内容