分类 服务器 下的文章

近日有安全提示:OpenSSH XMSS Key 解析整数溢出漏洞。

XMSS中使用的签名方案是有状态的,这意味着密钥随时间而变化,此过程需要考虑以前保存的“状态”(如果有)。负责处理XMSS保存的“状态”的函数会由于整数溢出漏洞而导致内存破坏。任何可以解析私有XMSS密钥的OpenSSH函数都容易受到攻击。

披露时间:2019-10-09 00:00:00 CVE编号:CVE-2019-16905

修复方案

升级OpenSSH至8.1及以上版本

需确认机器已安装的软件包中不存在低版本openssh组件,如可通过执行命令:rpm -qa | grep openssh查看组件版本。

准备工作

安装编译所需依赖软件包:

yum install -y wget gcc pam-devel libselinux-devel zlib-devel openssl-devel

下载 OpenSSH 安装包上传至服务器或 wget 直接下载

cd /usr/local/src
wget -O openssh.tar.gz https://mirrors.aliyun.com/pub/OpenBSD/OpenSSH/portable/openssh-9.3p1.tar.gz

备份配置文件 一般卸载的时候都会把配置文件以sshd_config.rpmsave的方式另存一份,但是/etc/pam.d/sshd这个配置文件并没有另存,所以建议都备份一下。

cp /etc/ssh/sshd_config sshd_config.backup
cp /etc/pam.d/sshd sshd.backup

删除低版本OpenSSH的的rpm包

rpm -e --nodeps `rpm -qa | grep openssh`

安装openssh

解压

tar -zxvf openssh.tar.gz
cd openssh-9.3p1

编译配置

./configure --prefix=/usr --sysconfdir=/etc/ssh --with-md5-passwords --with-pam --with-zlib --with-tcp-wrappers --with-ssl-dir=/usr/local/ssl --without-hardening

编译安装

make && make install

配置

调整文件权限

chmod 600 /etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_ecdsa_key /etc/ssh/ssh_host_ed25519_key

复制配置文件

cp -a contrib/redhat/sshd.init /etc/init.d/sshd
chmod u+x /etc/init.d/sshd

还原配置文件

mv ../sshd.backup /etc/pam.d/sshd
mv ../sshd_config.backup /etc/ssh/sshd_config

添加添加自启服务ssh到开机启动项

chkconfig --add sshd
chkconfig sshd on

重启服务

systemctl restart sshd

验证结果

查看下安装结果:

ssh -V

运行结果

OpenSSH_9.3p1, OpenSSL 1.1.1k  FIPS 25 Mar 2021

到此,升级基本完成。安全起见不要关闭SSH窗口,新增一个SSH连接,看看能否正常登录。如果不能登录,可以根据 sshd 的日志进行配置调整。

清理源代码

rm -rf /usr/local/src/openssh*

参考链接:https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/INSTALL
本文基于《CentOS 8 升级 OpenSSH 8.4》进行修改后发布,感谢原作者的分享。

使用wget下载文件时,报了一个错误,浏览器打开检查证书,发现证书没过期。联想起前段时间Let's Encrypt更换了根证书,那应该就是这个问题了。

报错信息:

# wget https://dl.ll00.cn/v2ray-linux-64.zip
--2021-11-03 11:55:26--  https://dl.ll00.cn/v2ray-linux-64.zip
Resolving dl.ll00.cn (dl.ll00.cn)... 59.83.218.168, 116.178.66.14, 59.80.39.21, ...
Connecting to dl.ll00.cn (dl.ll00.cn)|59.83.218.168|:443... connected.
ERROR: cannot verify dl.ll00.cn's certificate, issued by ‘/C=US/O=Let's Encrypt/CN=R3’:
  Issued certificate has expired.
To connect to dl.ll00.cn insecurely, use `--no-check-certificate'.

解决办法:
Linux上更新或安装下的根证书就行

yum install -y ca-certificates

使用宝塔很长时间,很早就发现宝塔安装的FTP不能使用被动模式。也尝试过解决,之前以为是端口不通,但开放端口后,发现还是不行。由于时间问题,也没再深入去解决,毕竟还可以用主动模式。

最近开始使用起vscode,然后安装了sftp同步插件,但发现同步文件非常慢,每次修改完文件都要十多秒才能把文件上传上去,效率太慢了。
于是打开调试模式,排查问题,最后发现这个插件不能指定使用主动模式,只能被动模式失败后才切换到主动模式,所以每次同步文件都要十多秒。
关键日志:

命令:    PASV
响应:    227 Entering Passive Mode (172,18,13,228,154,214)

客户端发出PASV被动模式命令,服务器返回了一个VPC内网IP,客户端尝试连接这个内网IP,但因为不是同一个内网,所以是连接不上的,指导超时才切换成主动模式。

服务器有两个IP,一个VPC内网IP,一个外网IP,pure-ftpd优先获取到了内网IP告知客户端将其作为被动模式IP,所以导致了被动模式不能使用的问题。
这种情况,我们只需要在配置文件里指定被动模式IP即可解决。编辑pure-ftpd的配置,搜索ForcePassiveIP,取消注释这行配置,修改IP为你的服务器外网IP。

这里假设你的服务器IP为8.8.8.8
ForcePassiveIP 8.8.8.8

保存,重启服务器,over

如果还是不行,那么要看看防火墙和安全组有没有放行被动模式的端口,宝塔安装的pure-ftpd软件的被动模式端口默认是3900040000,所以要先在防火墙和服务器安全组里放通这个端口范围。

服务器安全组是指阿里云或腾讯云的服务器,其它云服务器厂商基本都有

自己使用的服务器,为了方便远程修改同步文件,特地去安装 ftp 服务器有点浪费。linux 服务器自带 sftp 功能,也能满足文件上传下载的功能,所以,整起!

安装宝塔面板后,系统里面已经有www用户了,但是是没有设置密码的,所以我们先设置下密码

sudo passwd www

然后输入两次密码即可完成密码设置

Changing password for user www.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

编辑openssh配置文件

vim /etc/ssh/sshd_config

找到下面这行配置

Subsystem sftp /usr/libexec/openssh/sftp-server

然后注释掉它

#Subsystem sftp /usr/libexec/openssh/sftp-server

接着在配置文件最后面新增以下配置

Subsystem sftp internal-sftp

Match User www
    ChrootDirectory /www/wwwroot
    X11Forwarding no
    AllowTcpForwarding no
    PermitTTY no
    ForceCommand internal-sftp

保存配置文件,然后重启openssh服务

service sshd restart

大功告成

线上的环境,客户突然反馈不能使用,经过测试,发现了下文中的报错信息。从报错信息中,大概可以看出,Redis快照保存失败,导致无法正常使用。

以下是报错返回的报错信息

MISCONF Redis is configured to save RDB snapshots, but it is currently not able to persist on disk. Commands that may modify the data set are disabled, because this instance is configured to report errors during writes if RDB snapshotting fails (stop-writes-on-bgsave-error option). Please check the Redis logs for details about the RDB error.

想到有两个可能,权限问题,或磁盘满了。但服务器一直都在正常运行的,只是突然就这样,近期也没有对服务器进行变更。所以先看看磁盘吧。

查看服务器磁盘剩余空间,发现磁盘已满!

# df -hl
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        900M     0  900M   0% /dev
tmpfs           915M     0  915M   0% /dev/shm
tmpfs           915M  8.5M  907M   1% /run
tmpfs           915M     0  915M   0% /sys/fs/cgroup
/dev/vda1        40G   40G   20K 100% /
tmpfs           183M     0  183M   0% /run/user/0

删除部分无用文件,清理出31G空间,短时间内应该是不会再爆满了。

再测试业务功能,已恢复正常,也不用重启redis~