OPENSSL、OPENSSH编译升级指南[前篇]

前言：

关键字：SSHD、OPENSSL、OPENSSH、编译升级、CENTOS7；

为什么有本篇博文？主要是博主在工作遇到需要升级SSHD服务！SSHD服务，大家都应该很了解这个服务了，也就不多言了！不过，话说其实博主自己的服务器是很少升级这类东西的，主要感觉是没什么必要。一是因为博主都会做一些基本的安全防护，例如：公私钥认证登录、禁用密码登录等；这基本已经足够阻挡99%入侵可能了；二是，假惹真有什么有关SSHD的严重漏洞，基本上也会在网络上疯传，博主也会知道并进行修复；三是，博主的服务重要性不太高，而且也没什么人真的会盯上[当然那些在网上批量扫扫扫的，还是会盯上博主]；

不过呢，真正的生产环境，却是比博主的这种玩玩性质的没法比了；所以，基于现在流行的这个所谓"网络安全"，对漏洞修复的这个要求，真的是非常严格；无论如何，关于及时修复漏洞的这个事，博主是很支持的！可是啊，国内的这个"网络安全"，真的给玩坏了，厂商基本都跑去开发扫扫扫，解决方案？这种东西，不存在的！当然，确实也存在不了，毕竟每台服务器的环境是不一样的。于是嘛，打漏洞补丁或漏洞修复这个事，基本就只能看运维人员了；可惜，真没见过一个让博主觉得稳健的。见过一些修复方案，真的是能运行就行，从不考虑管理，也不考虑效率，甚至还有错的……

还是说回SSHD服务升级的这个事吧，其实博主工作中是有这么一个SSHD服务的升级方案的，看过这个方案，结论是，这个方案就是典型的能用就行……从博主的角度看到这个所谓的升级方案，博主的感觉真的不好[那种感觉就是，服务器真的是给人玩坏的]……

于是……博主决定自己搜资料搞，不搜不知道，原来以为这么一个基本的东西，应该很简单就能搜到解决方案吧[指的是好的解决方案，不是那种能用就行的]，结果……真没找到好的……好吧，既然网上没有，博主自己定义并从官方查资料搞……

方案是什么？1、要将相关服务升级至最新版本，那只能编译安装了[官方软件仓库不可能有的]；2、由于编译安装是无法使用"yum"或"apt"等这种命令管理的，所以本次的编译安装一定要做到可管理，即具有可卸载性，卸载后系统能还原至原始状态；3、尽量保证系统环境的完整性，将SSHD服务的升级影响降到最低；

好吧，这次废话说得太多了，以下这篇博文的相关操作，就是按以上这个目标去实现的；

[2022.03.27]后篇有新内容，不再使用修改"sshd.service"的方法，改用"chkconfig"命令相关方法，对系统环境影响更小；

一、环境相关

测试的操作系统为初装的CENTOS7[嗯~大家用得多嘛！]，注意：下面说的是整个方案实现的流程，这只是一个示例，给大家以作参考，对于"DEBINA"类的LINUX，实现方式是相似的；

• 操作系统：CENTOS 7

• OPENSSL版本：openssl-1.1.1m

• OPENSSH版本：openssh-8.9p1

• 测试日期：2022年03月16日

特别提示：如果你在实验过程中，直接复制本博客任意博文中的配置/代码，"空格"字符的前面将可能产生不可见的字符"M-BM-"，从而造成文件不可用，这是字符编码的问题~若必需使用复制粘贴方式，请务必手动替换掉配置项中的所有空格！！！或尝试使用以下命令过滤掉所有"M-BM-"字符~

二、快速跳转

《OPENSSL、OPENSSH编译升级指南[后篇]》

三、编译环境准备

要更新SSHD服务至最新状态，需要使用最新的"OPENSSL"与"OPENSSH"源码，由于必须对源码进行编译，所以首先必须先准备一个可用的编译环境；注意，编译环境的安装不是正常使用SSHD服务的必要条件，而只是生成一个最新的SSHD服务相关的可执行文件的一个必要过程；例如，对于需要升级多台硬件架构与操作系统环境相同的服务器，你只需要在某一台服务上进行正确的编译，然后，拿着已成功编译的代码/软件，至其它服务器上"make install"即可，那些"其它服务器"，并不需要安装编译环境！！！一个更具效率的做法，你甚至可以直接复制"make install"后的程序文件至"其它服务器"相同路径下即可；

以下为"OPENSSL"与"OPENSSH"的编译环境准备：

实际上博主的测试环境并不是最原始的CENTOS7初装环境，这是博主自己的PVE中快速创建的一个已经定义好的CENTOS7测试环境，这个环境博主默认安装了一些工具用于方便平时的调试，所以可能已经安装了某些依赖而博主不清楚；所以如果博主以上提供的依赖解决方案不能满足你的功能定义需求，请自行搜索解决编译环境的问题；

四、OPENSSL编译安装

现在，先对"OPENSSL"源码进行编译，并进行安装；原因是"OPENSSH"的正确编译依赖于"OPENSSL"的动态链接库；

启用最新的OPENSSL的动态链接库；注意：这些"动态链接库"是"OPENSSH"编译及"SSHD服务"正常运行所必须的；此步操作是整个升级方案中，唯一可能与原系统环境产生冲突的操作[原系统环境中某些服务可能依赖不同版本的库]！！！请注意目标服务器上运行的应用是否已经依赖了不同版本的OPENSSL库；

五、OPENSSH编译安装

在成功编译并安装"OPENSSL"后，进行"OPENSSH"的编译与安装；

六、修改"sshd_config"与"sshd.service"配置

由于在"OPENSSH"的编译参数中未定义"--sysconfdir="，所以有关更新后的SSHD服务的有关配置的相关文件在安装目录下，即"/opt/software/openssh-8.9p1/etc"下，有兴趣的读者可自行对比"/opt/software/openssh-8.9p1/etc/"与"/etc/ssh/"目录；由于"sshd_config"文件是新编译生成的，所以默认配置并不完整，所以需要补充配置；以下为一个基础示例，实际的"sshd_config"应如何配置，应该参照实际服务上的"/etc/ssh/sshd_config"中的定义；

修改"sshd.service"文件；CENTOS7上默认的"sshd.service"服务并不能正常运行自编译安装的"OPENSSH"服务，需要进行以下修改：

VIM\NANO修改"sshd.service"文件很麻烦？你可以用以下方式偷个懒：

完成以上操作后，使用"systemctl"命令重启一下"SSHD"服务应该已经可以正常运行了！！！执行以下命令操作：

七、使用更新后的相关命令

无论是"OPENSSL"还是"OPENSSH"，使用自定义安装路径，相关的可执行文件是没办法直接使用的[这是由于系统环境变量"PATH"的定义原因，但你依然可以使用旧版本的命令]，一般网络教程都会说更新"PATH"这个环境变量，说实话，博主不喜欢这个方案，实际上，LINUX已经预留了一个专用的目录去解决这样的问题，使用"ls /usr/local/sbin"命令去查询一下这个目录吧，你会发现这是一个空目录，但这个目录却又已经默认的定义在"$PATH"环境变量中[而且还是首位]，实际上，我们只需要为相关的可执行文件生成一个软链接至此目录即可……

为什么不使用修改"$PATH"的方式去实现？原因是，"$PATH"变量是有顺序的，而且随着此类自定义更新的不断出现，如果使用修改"$PATH"的方式，"$PATH"变量会变得越来越大，也就变得越来越难管理；另外，博主也不希望过多的对系统的默认环境进行变更；

实际上，这一步并不是必须的，我们的主要目的是升级SSHD服务，也就是说，只要SSHD服务能正确的使用上更新后的"sshd"可执行文件即可，至上一步，实际上这个目的已经达到了，而我们现在只是使用不了相关的更新后的配套命令而已。也就是说，不执行本步操作的前提下，我只能使用旧版本的"ssh"、"scp"等命令[还没有卸载]；

关于本步骤的操作，请自行依据自身的需要，选择是否使用；

八、卸载与还原

即是方案的目标是可管理，那卸载功能是必不可少的，另外，卸载新版的SSHD服务后，系统应该能还原至原始状态[即更新前的状态]；那回想一下本次的SSHD服务的更新做了什么吧？1、执行了"make install"安装了"OPENSSL"与"OPENSSH"，而且均安装在"/opt/software/"目录下；2、刷新了动态连接库的缓存（/etc/ld.so.conf.d/openssl-1.1.1m.conf）；3、修改了系统上的"/usr/lib/systemd/system/sshd.service"文件；4、在"/usr/local/sbin"目录下生成了链接文件[如果有操作]；

也就是说，假若我们需要还原至原始状态，那么只需要对上面修改作一个逆向操作即可；则卸载与还原的操作如下：

这里有一些问题，在整个教程中，实际上的操作并没有这么少，为什么卸载还原的操作比较简单？你或许有以下疑问：

1、编译环境的安装部分：为什么没有这部分还原的说明？正如博文前面提及，编译环境的准备并不是必需的；也就是说，假若我们手上有一份已经编译好的"OPENSSL"及"OPENSSH"，我们在目标环境上升级SSHD服务，完全可以不安装编译环境；

2、"sshd_config"部分：为什么不需要还原"sshd_confg"？原因是，我们根本没有使用操作系统上的"/etc/ssh/sshd_confg"，我们使用的是"/opt/software/openssh-8.9p1/etc/sshd_config"；

3、为什么删除新的SSHD服务的相关文件后SSHD服务还能正常运行？这有一个前提，我们并没有删除有关原有系统上的，任何的关于原SSHD服务的相关文件；

九、影响与优化

这个升级方案实际上并不完美，实际上还是变更了系统的原有环境，产生这个情况的操作主要在"动态链接库"的新增操作中，虽然使用了一个相对简单可控的方案去新增"动态链接库"，但假若新增加的"动态链接符"实际上已存在于操作系统上，即系统中存在了同名的动态连接库，而这些同名的"动态链接库"已经被系统中的其它应用所调用，那么，这个新增"动态链接符"的操作则可能会影响原有应用的正常运行[虽然这个可能性很小]！博主是尝试过去解决这一个缺点的，多次调整过编译选项，答案是博主没有解决成功，这是目前博主可以实现的，最能可控的一个升级方案！注，对于初始的操作系统环境，不会有这个可能性，默认是不存在这些"动态链接库"。

这篇博文只是介绍了升级OPENSSL与OPENSSH的一整个流程，并不是博主真正的升级方案，毕竟在大批量升级的前提下，这样去敲命令并不现实，这样写的原因是为了让读者更清晰的去了解整个升级流程中每个步骤具体到底做了什么。真正批量升级的实施中，一定是使用脚本去完成，实际上博主是已经写好安装与卸载的脚本的，这部分内容博主是计划在"后篇"写的，但由于这篇博文所花的时间，博主不确定会不会有后篇了；实际上大家可以自行参照流程，写一个自己的安装与卸载脚本。

结、

又一篇工作量远超计划的博文记录，原来以为很简单便能写完，没想到要写清楚一些问题，还是非常的花时间，重点是，实际上博主还没有写完，还有后篇呢，这个坑，博主不知道会不会填了，就这样吧~