最终方案，这种事情都要想好如果失败了怎么办，因为失败是不可避免的

ssh 升级干啥，我宁可弄 fail2ban ，宁可弄白名单，我都不自己去升那个 openssh-serfer

@julyclyde 这就是 centos 的原因。几大流行发行版，只有 centos 各种组件太旧，网上各种教程教人自己编译安装。其他的都是 apt ，pacman 升级，不可能遇到这种问题的。

留个 telnet 后路再动手

1 。先备份 2 。升级前先准备 telnet 作为备用

deb rpm 等二进制软件包默认不可移植，即不能跨发行版跨版本(深层原因什么都有，你自己提的 glibc 版本是一个潜在可能性)，强行移植可能能用但无可用性保证，后果自负。那些非发行版提供的软件包为了可移植是做了特殊设计的。
正规流程是只是用发行版软件源提供的包且直接使用在线源(或者私有镜像源)安装。玩不明白这套的还是老实用容器吧。

@Remember #50 教编译安装就乖乖编译安装？打个 rpm 包有多难。说到底还是人的问题。

升级好像会重置 sshd_config ，如果有使用自定义端口的话，可以尝试使用默认的 22 端口连接看看。

docker 的含金量还在增加！

上个月干过类似搞坏 ssh 的事情，在产品的构建服务器上测试一个编译链接的想法，把服务器上的 openssl 的加解密动态库的 soname 给重命名了，这个服务器只有这一个版本。重命名完所有 ssh session 手动关掉，然后准备重连，连不上去了，瞬间想到 ssh 是依赖 openssl 的。真一瞬间冷汗下来了。
然后找到公司 IT 确认这台机器是物理机，申请了权限去了机房 tty 进环境，把动态库重命名回来，把环境又救回来了。

还有一次 yum 升级 kernel 后重启时引导失败，又让 IT 把环境重装，还好环境上啥服务和数据都没有。

现在公司环境凡是涉及到基础软件的升级更新和修改，一律不动手，能跑就别动。