linda

Ubuntu22.10 Debian12 之后的新版本sshd改成socket形式，netstat -nap查看端口对应的进程是init

光修改/etc/ssh/sshd_config中的“Port=xxx"，再systemctl restart sshd/ssh 还不行，还要修改/lib/systemd/system/ssh.socket中的“ListenStream=xxx”

systemctl daemon-reload
systemctl restart ssh
netstat -tulpn


还原为之前的设置
systemctl disable --now ssh.socket
systemctl daemon-reload
systemctl enable --now ssh.service
systemctl restart ssh


sshd -t   
Missing privilege separation directory: /run/sshd

mkdir /run/sshd

systemctl -l --no-pager status ssh.service


参考：
https://askubuntu.com/questions/1439461/ssh-default-port-not-changing-ubuntu-22-10
https://askubuntu.com/questions/1479500/how-to-change-the-ssh-port-on-ubuntu-23-04

=========

sshd-session 是在 2024 年 7 月发布的 OpenSSH 9.8 版本（具体在 2024 年 5 月底合并到开发主分支）中首次引入的。 [1, 2]
在此之前的版本中，当客户端发起连接时，主监听进程 sshd 会直接通过 fork() 派生出子 sshd 进程来处理该用户的连接和后续会话。 [1, 3]
## 为什么要引入 sshd-session？
为了提升安全硬化（Security Hardening）和减少攻击面。这是 OpenSSH 团队的一项重大架构重构： [1, 4]

*
* 二进制文件拆分：OpenSSH 9.8 将原来庞大、单一的 sshd 拆分为一个精简的监听守护进程 sshd，以及一个专门处理单个会话的 sshd-session 进程。
* 职责分离：主进程 sshd 现在只负责验证配置、加载主机密钥、监听端口（如 22 端口）以及控制最大连接数。一旦有新的网络连接进入，它会立即通过 fork + exec 启动一个完全独立且隔离的 sshd-session 进程去处理该会话。
* 地址空间隔离：这样做使核心监听代码与复杂的会话处理代码拥有完全相异的地址空间，能更有效地阻断类似内存破坏、权限提升等漏洞的利用路径。 [1, 2, 5, 6]
*

------------------------------
## 系统进程和日志的变化
随着这个组件的引入，系统运维和日志分析也会受到直接影响：
## 1. 进程树表现

*
* 旧版本（OpenSSH 9.7 及更早）：

root      1234  /usr/sbin/sshd -D
root      5678   \_ sshd: username [priv]   <-- 依然是 sshd
username  5680       \_ sshd: username@pts/0

* 新版本（OpenSSH 9.8 及以后）：

root      1234  sshd: /usr/sbin/sshd -D [listener]
root      5678   \_ sshd-session: username [priv]   <-- 变成了 sshd-session
username  5680       \_ sshd-session: username@pts/0

[1, 5, 7]
*

## 2. 日志与安全工具的变化
由于进程名字变了，你在 Linux 系统的安全日志（如 /var/log/secure 或 /var/log/auth.log）中，可能会看到日志标签从 sshd[...] 变成了 sshd-session[...]。 [6, 8]

注意：这也导致了早期的 Fail2ban 或 SSHGuard 等日志分析防墙工具因无法匹配新的标签而失效。如果你将系统升级到了较新的系统（例如 Debian 13 Trixie、RHEL 9.8、Alpine 3.21 等），你需要同步更新防护软件的过滤规则（将搜索 sshd 改为 sshd-session）。 [1, 5, 7, 9]


/etc/fail2ban/filter.d/sshd.local
[DEFAULT]
_daemon = sshd(?:-session|-auth)?
------------------------------
## 后续发展（OpenSSH 10.0 及以后）
OpenSSH 的拆分并没有止步于此。在 2025 年 4 月发布的 OpenSSH 10.0 中，官方对安全级别进一步升级，将 sshd-session 中负责“用户登录认证”的代码再次剥离，进一步分化出了一个名为 sshd-auth 的极简网络进程。这意味着目前最新的架构已经变成了 sshd (监听) ➔ sshd-auth (前置认证) ➔ sshd-session (认证成功后的会话控制) 三层联动结构。 [1, 2, 5, 6, 10, 11]

==============
另外 rsyslogd也需要编辑/etc/rsyslog.conf，注释掉多余的内容

#$FileOwner syslog
#$FileGroup adm
#$FileCreateMode 0640
#$DirCreateMode 0755
#$Umask 0022
#$PrivDropToUser syslog
#$PrivDropToGroup syslog

[ 本帖最后由 linda 于 2026-8-4 18:41 编辑 ]

linda

如何验证你的 9.x 是否安全？

获取 Debian 软件包的完整版本号（包含修订号）。请运行：
# dpkg -l openssh-server

# /usr/sbin/sshd -V
OpenSSH_9.6p1 Ubuntu-3ubuntu13.18, OpenSSL 3.0.13 30 Jan 2024

使用以下命令查看 Ubuntu 官方修复日志
# apt changelog openssh-server

对应的官方在线网页
https://ubuntu.pkgs.org/24.04/ubuntu-updates-main-amd64/ssh_9.6p1-3ubuntu13.18_all.deb.html


运行以下命令检查 Ubuntu 的安全源，看 openssh-server 是否还有更新：
# apt update
# apt list --upgradable openssh-server

结果判定：如果输入后没有任何提示，或者执行 sudo apt install openssh-server 提示 openssh-server is already the newest version，则说明在 Ubuntu 24.04 系统的官方支持下，你已经拿到了最安全的最新补丁。


本机 apt upgrade 日志 有没有sshd的内容？
# zgrep -i "upgrade openssh-server" /var/log/dpkg.log*
/var/log/dpkg.log.1:2026-07-13 22:00:23 upgrade openssh-server:amd64 1:9.6p1-3ubuntu13.16 1:9.6p1-3ubuntu13.18
/var/log/dpkg.log.4.gz:2026-04-29 21:00:23 upgrade openssh-server:amd64 1:9.6p1-3ubuntu13.15 1:9.6p1-3ubuntu13.16
/var/log/dpkg.log.5.gz:2026-03-09 09:51:54 upgrade openssh-server:amd64 1:9.6p1-3ubuntu13 1:9.6p1-3ubuntu13.14
/var/log/dpkg.log.5.gz:2026-03-12 23:00:33 upgrade openssh-server:amd64 1:9.6p1-3ubuntu13.14 1:9.6p1-3ubuntu13.15


zgrep -h "Upgrade:.*openssh" /var/log/apt/history.log*
Upgrade: cifs-utils:amd64 (2:7.0-2ubuntu0.4, 2:7.0-2ubuntu0.5), openssh-client:amd64 (1:9.6p1-3ubuntu13.16, 1:9.6p1-3ubuntu13.18), openssh-server:amd64 (1:9.6p1-3ubuntu13.16, 1:9.6p1-3ubuntu13.18), openssh-sftp-server:amd64 (1:9.6p1-3ubuntu13.16, 1:9.6p1-3ubuntu13.18)
...

官方有没有patched之后 sshd的 hash值？
官方有提供对应的 Hash 值（校验和）。由于不同硬件架构（例如 Intel 的 amd64 还是 ARM 的 arm64）编译出来的二进制文件 sshd 大小和 Hash 完全不同，官方并不是直接贴出 sshd 这一个文件的 Hash，而是将该版本中所有文件的完整 Hash 列表打包进了安全签名文件中。为了绝对可靠地进行完整性验证，您可以直接在本地系统上调用这些官方发布的 Hash 数据进行对比。
请使用以下两种方法：
方法一：自动验证（最推荐，简单准确）
Ubuntu 内置了一个名叫 debsums 的工具，专门用来将本地关键二进制文件（如 /usr/sbin/sshd）的 MD5/SHA 值与官方源发布的初始哈希进行一一比对。
安装工具：
apt install debsums
一键校验 SSH 服务的所有文件：
debsums openssh-server
结果判定：如果每一行后面都显示 OK（例如 /usr/sbin/sshd ... OK），说明你机器上的 sshd 的 Hash 值与官方释出的最新 Patched 版本完全一致，没有被篡改，也没有损坏。如果显示 FAILED，则说明文件被动过。

如果你想检查全系统，且只看那些真正被篡改过的可执行文件（排除配置文件和正常文件），可以使用：
debsums -c -s

CentOS 检查系统中所有已安装的 RPM 软件包：
rpm -Va

方法二：提取本地 Hash 手动核对如果你想要拿到一个具体的字符串去应付安全审计，可以查看 Ubuntu 存在本地的官方 Hash 记录（这些是在执行 apt upgrade 时通过 GPG 签名链安全下载下来的官方元数据）。
执行以下命令，直接提取官方为你这个版本（3ubuntu13.18）记录的预设 MD5 值：
grep "usr/sbin/sshd" /var/lib/dpkg/info/openssh-server.md5sums
你会得到类似这样的官方参考 Hash 输出：f613975c93646d28e9a6f89644358de5（一串16进制字符）   usr/sbin/sshd
然后，计算你本机上真实存在的那个 sshd 文件的 MD5 值：
md5sum /usr/sbin/sshd
核对结果：对比这两个命令输出的 32 位字符串，如果完全一致，即代表你本机的软件与官方发布的最新补丁包完全吻合。
============
使用 apt update && sudo apt upgrade 更新 Ubuntu 系统时，sshd (OpenSSH) 仍然停留在 9.x 版本而非最新的 10.x 版本，这是因为 Ubuntu 采用了“固定版本”和“安全补丁反向移植 (Backporting)”的发布策略，优先保障系统的极端稳定性。
以下是导致这一现象的底层原因以及如果您必须使用 10.x 该如何处理：
核心原因分析稳定性优先与版本锁定（Version Pinning）Ubuntu（尤其是 LTS 长期支持版本）在发布的那一刻，官方软件仓库中绝大多数核心基础软件（如 OpenSSH、Linux 内核、glibc 等）的大版本号就已经冻结。
例如，Ubuntu 24.04 LTS 默认自带的是 OpenSSH 9.6。在整个系统的生命周期内，apt upgrade 只会为其推送修复 Bug 的小版本更新，而不会跨越到新的大版本（如 10.x），以防止新特性引入未知的兼容性问题或导致现有的配置文件失效。
安全补丁反向移植（Backporting）如果最新的 OpenSSH 10.x 修复了某个严重的安全漏洞（CVE），Ubuntu 的安全团队不会通过升级整个软件到 10.x 来解决。相反，他们会把 10.x 中的漏洞修复代码（Patch）提取出来，“反向移植”并应用到当前系统锁定的 9.x 版本中。这意味着虽然你的系统显示版本是 9.x，但它已经具备了 10.x 中相应的安全性。复杂的软件依赖树sshd 作为系统的最核心远程管理工具，依赖于特定版本的系统加密库（如 openssl）和身份验证模块（如 PAM）。直接升级到 10.x 可能会破坏这些底层依赖关系，甚至可能导致你无法通过 SSH 登录服务器。

多商业公司使用的自动化漏洞扫描工具（如 Nessus、Vulnerability Scanner 等）往往非常死板。它们在扫描时只看大版本号（发现您是 9.6p1，而官方最新是 10.x 就会报警），从而忽略了后面的 3ubuntu13.18 补丁后缀。如果您的安全合规部门因为扫描报告向您施压，您可以直接向他们提供上面的官方安全补丁链条（说明补丁版本已递增至 .18），这在业内被称为 “安全误报（False Positive）”


参考：
https://www.trustcomputing.com.cn/bbs/viewthread.php?tid=1106
yum、apt-get、zypper安装程序

[ 本帖最后由 linda 于 2026-8-17 11:56 编辑 ]

[ 本帖最后由 linda 于 2026-8-17 16:44 编辑 ]