因为要修复漏洞，所以得升级openssh，但从9.6开始，默认编译出来的openssh，无法兼容之前的sftp客户端了，大概的错误信息就是算法协商不一致。

        解决办法其实也简单，就2步：

        1. 编译的时候，需要打开依赖openssl的开关。至于为什么要在9.6及之后的版本默认关闭openssl依赖，我也没细究了，能解决问题就已经快哭出来了，😄

        2. 修改/etc/ssh/sshd_config配置文件，增加如下配置:

HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa

        喜欢折腾的心让我想知道为什么这个问题和是否自带openssl有关系，于是开始了下面的探索之旅。

先来看一个安装openssh时自带openssl和没带openssl的版本信息对比 ：

自带openssl：

不带openssl：

尝试一下，使用不带openssl的版本安装，并修改上面第二步提到的sshd_config的配置，然后重启sshd，则会看到如下错误：

 画线的地方提示ssh-rsa是Bad key types，说明sshd程序无法识别该算法。

接下来看openssh的源码， 先看rpm包的打包描述文件openss.spec，通过对比版本记录，自9.6开始，增加了是否编译openssl的参数，如下图：

在<=9.5的版本，是会强制编译openssl。而在>=9.6的版本，则是通过without_openssl参数控制，without_openssl的定义如下： 

假如我们的编译环境是Fedora/Centos7，那么编出来的版本默认不携带openssl。

通过在Centos7和龙蜥上打包时，可以看到控制台执行的命令也有所不同。

Centos7:

Anolis(龙蜥):

从上面的对比也可以看到，执行./configure命令时，Centos7会携带—without-openssl参数。

根据报错信息，我们再细挖一点，找到ssh-rsa.c源码，发现在源码的开头定义了#ifdef WITH_OPENSSL标志，指定的范围直到代码结尾，具体如下图：

 

上述代码进行了简化， 至此，证据应该是差不多了，就到折腾到这里吧。