SSH 服务在 Linux 服务器里属于最底层的基础设施，只要机器开了远程管理，几乎都离不开它。Ubuntu 20.04 自带的 OpenSSH 版本通常停留在 8.2p1 左右，这个版本在当年的环境里够用，但放到现在，漏洞扫描和等保检查经常会对旧版本报出中高危风险，比如 CVE-2021-41617、CVE-2023-25136 这类远程问题，还包括一些针对 scp、sftp 协议的缺陷。很多朋友拿到扫描报告第一反应是"要不要升级"，我的建议是：不仅需要升级，而且最好在一开始部署系统时就纳入运维规范里。这篇文章基于我在多个生产环境里的实际操作，整理 Ubuntu 20.04 上升级 OpenSSH 的完整方案，包括 apt 源升级和源码编译升级两条路线，以及过程中踩过的坑和排查思路。无论你是刚接手服务器的新人，还是已经在生产环境吃过亏的运维，按照这里的步骤操作，基本能平稳落地。
1. 升级前的准备与版本确认
1.1 为什么 Ubuntu 20.04 自带的 OpenSSH 需要升级
很多人觉得系统自带的 SSH 只要能用就不需要动，这个想法在常规功能上是成立的，但从安全和兼容性角度看，问题不少。Ubuntu 20.04 的默认仓库里，openssh-server 版本长期停留在 8.2p1，上游 OpenSSH 已经更新到了 9.3、9.6 甚至更高，中间跨越的版本里修复了大量安全问题。
比如我们经常在扫描报告里看到的 OpenSSH 用户名枚举漏洞，在特定版本组合下存在被利用的可能。还有一些第三方软件或安全设备只支持更新版本的 SSH 协议特性，比如新的公钥算法、更强的密钥交换算法，如果服务端版本太旧，功能就匹配不上。另外，Ubuntu 20.04 已经进入维护周期的后期阶段，默认仓库里的软件包更新频率会越来越低，与其被动等待，不如主动把 SSH 升级到一个自己可控的版本。
从实际运维角度看，升级 OpenSSH 还有一个隐性好处：新版本对新的加密算法支持更好，比如 sntrup761x25519-sha512 密钥交换算法，在部分弱网环境下握手的成功率比旧算法高，对延迟敏感的内部系统改善挺明显。
1.2 检查当前版本和系统环境
升级之前，第一件事是摸清当前状态。登录服务器后，执行以下命令查看现有版本和系统信息：
# 查看系统版本 lsb_release -a # 查看 OpenSSH 客户端版本 ssh -V # 查看 OpenSSH 服务端版本 sshd -V # 查看系统架构，编译时要用 uname -m在我常用的几台机器上，输出一般是这样的：
$ ssh -V OpenSSH_8.2p1 Ubuntu-4ubuntu0.11, OpenSSL 1.1.1f 31 Mar 2020注意这里的信息包含两部分：OpenSSH 版本（8.2p1）和 OpenSSL 版本（1.1.1f）。升级 OpenSSH 时，如果系统里已经有新版 OpenSSL，编译时默认会优先链接系统 OpenSSL，版本兼容性通常没问题，但如果手动指定了旧版本 OpenSSL 路径，可能反而会引发证书库不匹配的问题，后面会细说。
除此之外，还要确认服务器上是否有其他依赖 SSH 的软件，比如 fail2ban、sssd 这类，升级后再测试它们的行为是否符合预期。至少要知道服务器的防火墙规则和当前 SSH 端口，避免升级过程中无法访问机器。
1.3 升级方式选型：apt 源升级与源码编译升级
Ubuntu 20.04 上升级 OpenSSH，本质上只有两条路：用官方源或第三方源通过 apt 升级，或者从官网下载源码自行编译安装。两条路各有优缺点，选型要结合环境来判断。
apt 升级的优势是省事、依赖自动解决、卸载和版本回退方便，但问题在于 Ubuntu 20.04 默认源里的 OpenSSH 在生命周期内不会有大版本跳升，除非你自己添加第三方源（比如 Ubuntu 的 backports 或者某些安全源），否则 apt upgrade 并不会给你带来 9.x 的新版。添加第三方源有风险，源提供的二进制不一定经过充分测试，可能和系统库不兼容，所以我个人对第三方源持保留态度。
源码编译的优势是完全掌控版本，可以编译指定版本（比如 9.6p1 或 9.8p1），也可以对编译参数进行定制，缺点也很明显：需要处理依赖、服务文件、升级后的覆盖关系，回滚相对麻烦。如果你有等保合规要求，或者内部安全基线对 SSH 版本有明确下线标准，源码编译几乎是唯一方案。
如果你只是想消除扫描报告里的低危告警，且不排斥测试第三方源的可靠性，可以先尝试向源列表中添加 backports，然后执行apt install openssh-server看能不能拉到新版。如果拉不到，再回到源码编译这条路。我的建议是把源码编译作为主导方案，虽然操作步骤多，但整个流程可理解、可掌控，也更符合生产环境的严谨性。
2. 使用 apt 源直接升级 OpenSSH 的完整步骤
2.1 备份关键配置文件
升级之前，先把现有的 SSH 配置完整备份下来。常见的坑是升级安装包时 deb 包会自动替换或迁移配置，如果你在旧配置里定制过端口、认证方式、AllowUsers 等，升级后这些配置可能丢失或被覆盖。
# 备份服务端配置 sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F) sudo cp -a /etc/ssh/ssh_config /etc/ssh/ssh_config.bak.$(date +%F) # 备份主机密钥（重要，别偷懒） sudo cp -a /etc/ssh/ssh_host_* /etc/ssh/backup_host_keys_$(date +%F)/主机密钥必须备份。如果不备份，升级后系统可能重新生成新的主机密钥，客户端首次连接时因为密钥指纹变了而直接拒绝连接，造成"升级后所有人连不上"的假象，实际上只是密钥校验失败。把旧的密钥文件复制回去，就能维持指纹一致。
在修改任何系统级配置之前，顺手开启一个临时会话（比如 screen 或 tmux），或者在另一个终端保持着 root 登录的会话，避免在 SSH 服务重启的瞬间断连后没有退路。这一步看似多余，实际救过我很多次。
2.2 更新软件源并升级 openssh-server
如果确定走 apt 源路线，先更新源缓存，然后直接安装 openssh-server：
# 刷新软件源 sudo apt update # 安装或升级 OpenSSH 服务端 sudo apt install --only-upgrade openssh-server openssh-client -y如果源里本来有新版，apt 会自动拉取并升级；如果源里还是 8.2p1，那输出里会出现类似openssh-server is already the newest version的提示，说明默认源里没有可选新版。此时可以尝试启用 Ubuntu 的 backports 源，把focal-backports添加进/etc/apt/sources.list（或者/etc/apt/sources.list.d/ubuntu.sources），然后再次执行apt update和apt install openssh-server。
这里要提醒一句：尽量不要混合使用不同发行版的 deb 包，比如把 Debian 的 OpenSSH 包直接强行安装到 Ubuntu 上，依赖冲突能把整个 sshd 搞挂。如果 backports 源也没法拉新版，我建议直接切换到源码编译路线。
升级完成后，执行：
# 查看新的版本 sshd -V # 重启服务 sudo systemctl restart sshd # 查看服务状态 sudo systemctl status sshd确认服务处于 active (running) 状态。如果服务起不来，立刻用备份的配置排查，或者回滚到原有版本，后面有专门的排查章节。
2.3 验证升级后 SSH 功能是否正常
服务启动只是第一步，我见过好多次服务运行正常但功能异常的情况。验证要覆盖这几个方面：
- 能正常连接：在另一台机器上执行
ssh 目标IP -p 端口，用密码或密钥登录都试一遍。 - SFTP 正常：用
sftp 目标IP连一下，能列出目录就算基本正常。 - 端口监听正确：
ss -lntp | grep sshd查看监听地址和端口是否符合预期。 - 登录日志正常：
journalctl -u sshd -f或者tail -f /var/log/auth.log查看是否有异常报错。
我最常忽略的是 SFTP 功能，升级后 ifconfig 一看服务活着，ssh 登录也正常，但 scp 或 sftp 报 subsystem request failed。这类问题通常是因为 sftp-server 路径不对，旧版本的 sftp-server 在/usr/lib/openssh/sftp-server，新版本可能在/usr/lib/openssh/sftp-server或/usr/libexec/sftp-server，可以在sshd_config里显式指定正确路径。路径不对时，升级后服务能启，下载文件就报错。
3. 源码编译升级 OpenSSH 的完整步骤
3.1 安装编译依赖并准备备用连接
源码编译是生产环境里最可控的方式，操作前先在服务器上准备好编译工具链和依赖库。OpenSSH 编译通常需要这些包：
sudo apt update sudo apt install -y build-essential zlib1g-dev libssl-dev libpam0g-dev libselinux1-dev gcc make wget关键依赖是 zlib 和 openssl 的开发头文件。编译时，OpenSSH 的 configure 脚本会检查这些库是否存在，如果缺失，编译会在 configure 阶段直接中断，并提示缺少某个库。
准备备用连接是老生常谈但必须强调。源码编译安装会覆盖系统原来的sshd、ssh、scp、sftp等二进制文件，如果编译过程中服务被重启或启不来，你的远程会话就断了。至少确保以下几种场景之一成立：
- 当前是在服务器本地终端（物理控制台或带外管理）操作。
- 已经开启了第二个 SSH 会话，且两个会话不在同一个进程树上。
- 做好了 vn 或者临时开了一个 telnet 服务（但我不推荐 telnet，明文传输风险大）。
生产环境建议结合带外管理工具操作，或者选择凌晨低峰时段操作，给自己留足回滚时间。
3.2 下载 OpenSSH 源码并编译安装
到 OpenSSH 官网下载站点，找一个稳定的版本。写这篇文章时我常用的版本是 9.8p1 和 9.6p1，官方已经移除了对旧版本的存在性保证，但你可以选择适合的稳定版。下载并解压：
cd /usr/local/src sudo wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.8p1.tar.gz sudo tar -zxvf openssh-9.8p1.tar.gz cd openssh-9.8p1如果是内网环境无法直接下载，可以提前下载 tar 包传到服务器上。解压后先看一下 README 和 INSTALL，确认版本要求的依赖和特殊说明。
接下来是配置和编译。我通常这样配置：
sudo ./configure --prefix=/usr/local --sysconfdir=/etc/ssh \ --with-ssl-dir=/usr/lib/ssl \ --with-md5-passwords \ --with-pam --with-zlib参数含义说明一下。--prefix=/usr/local指定安装目录，如果不指定默认也是/usr/local，但我故意写出来是为了明确安装位置。--sysconfdir=/etc/ssh让配置文件继续使用/etc/ssh/sshd_config，这样旧配置和密钥还能沿用。--with-pam启用 PAM 模块支持，避免升级后密码认证出问题。--with-md5-passwords是为了兼容部分老系统的密码哈希格式，如果你确定所有用户都使用 sha256/sha512 密码哈希，可以不加这个参数。
然后执行编译和安装：
sudo make sudo make install编译过程会根据机器性能耗时几分钟到十几分钟不等，期间不要强行中断，避免生成不完整的二进制。make install执行完，检查一下安装的新版是否生效：
/usr/local/bin/ssh -V /usr/local/sbin/sshd -V如果输出的是 9.8p1 之类的版本号，说明编译安装成功。但这里有个坑：系统里可能同时存在/usr/bin/ssh和/usr/local/bin/ssh，shell 里执行ssh时默认找的是/usr/bin/ssh。要查看which ssh指向哪里，必要时把/usr/local/bin放在 PATH 前面，或者直接将新版软链接到/usr/bin下。
3.3 替换旧版二进制与密钥处理
源码编译安装后的新版 OpenSSH 默认装在/usr/local目录下，但系统原有的 OpenSSH 还在/usr/bin和/usr/sbin下，新老版本共存的结果就是sshd服务可能根本不加载新版。
我采用的稳妥替换方案是：
# 先停止旧服务 sudo systemctl stop sshd # 备份旧版二进制 sudo mv /usr/sbin/sshd /usr/sbin/sshd.old.bak sudo mv /usr/bin/ssh /usr/bin/ssh.old.bak sudo mv /usr/bin/scp /usr/bin/scp.old.bak sudo mv /usr/bin/sftp /usr/bin/sftp.old.bak # 建立新版本软链接 sudo ln -s /usr/local/sbin/sshd /usr/sbin/sshd sudo ln -s /usr/local/bin/ssh /usr/bin/ssh sudo ln -s /usr/local/bin/scp /usr/bin/scp sudo ln -s /usr/local/bin/sftp /usr/bin/sftp # 重新生成主机密钥（如果之前没备份） sudo ssh-keygen -A注意密钥生成顺序：如果之前备份过/etc/ssh/ssh_host_*，就不要执行ssh-keygen -A，直接用备份的密钥文件覆盖回去即可。不备份也行，新生成密钥会让客户端的 known_hosts 指纹变化，受影响的是所有运维同学的免密连接和脚本。
我遇到过一种情况：不使用软链接，而是直接把编译出来的sshd文件复制到/usr/sbin/sshd，虽然能用，但后续make uninstall或升级新版时麻烦。用软链接方式更清晰，方便以后切换版本。
重启服务前，先用新版本检查配置文件是否正确：
sudo /usr/local/sbin/sshd -t如果没有任何输出，说明配置文件语法正确。如果报错，对照错误信息修复sshd_config。最常见的报错是Bad SSH2 cipher spec或某个选项在新版本中已废弃，需要注释掉或替换。
检查通过后启动服务：
sudo systemctl start sshd sudo systemctl status sshd看到 active (running) 状态后，不要急着断开当前会话，先新开一个终端测试连接。确认新会话能正常登录、sudo 无异常，再决定是否关闭旧会话。升级 SSH 最怕的就是旧会话一断，新会话又起不来。
3.4 systemd 服务文件与开机自启
Ubuntu 20.04 的 SSH 服务通过 systemd 管理。默认情况下，/lib/systemd/system/ssh.service里定义的启动命令是/usr/sbin/sshd，如果/usr/sbin/sshd已经软链接到/usr/local/sbin/sshd，那 systemd 启动的就是新版。
有时systemctl restart sshd后发现服务起不来，用systemctl status sshd又看不出具体原因，这时需要查看 systemd 服务文件里具体执行了什么命令：
systemctl cat ssh如果看到类似ExecStart=/usr/sbin/sshd -D $SSHD_OPTS，说明它启动的是软链接后的路径，没问题的。如果发现 service 文件指向了/usr/sbin/sshd且软链接生效，但服务还是起不来，多半是二进制路径问题或者权限问题。可以手动在前台执行一次：
sudo /usr/sbin/sshd -D看它输出的错误信息是什么。
开机自启这块不用额外操作，只要原来的systemctl enable sshd还在，替换的二进制路径不变，开机就会自动启动新版。如果你不想改动 systemd 文件，也可以直接改/etc/default/ssh里的参数，但一般不需要。
有个细节：Ubuntu 20.04 上如果安装了openssh-server，系统里可能存在ssh.socket服务（socket 激活模式）。如果ssh.socket处于启用状态，systemctl restart sshd之后服务可能没有真正监听端口，而是由 socket 激活。这个现象很折磨人，排查办法是：
sudo systemctl status ssh.socket sudo systemctl stop ssh.socket sudo systemctl disable ssh.socket sudo systemctl restart sshd把 socket 服务禁掉，让 sshd 自己独立监听端口，避免服务名冲突。
4. 升级过程中的常见问题与排查技巧
4.1 升级后无法通过 SSH 登录
升级后最容易遇到的问题就是"所有机器都连不上，只有控制台还能操作"。遇到这种情况，先别慌，按以下顺序排查：
第一步，看服务状态：
sudo systemctl status sshd如果服务是停止状态，直接看日志：
sudo tail -100 /var/log/auth.log sudo journalctl -u sshd --no-pager -n 100常见的日志错误有这几种：
Permission denied (publickey,password)：认证方式配置有问题，检查sshd_config里PasswordAuthentication、PubkeyAuthentication、PermitRootLogin是否按预期配置了。Connection closed by authenticating user：一般是 PAM 模块或 SSH 主机密钥权限问题，检查/etc/ssh/ssh_host_*文件的权限是否为 600，属主是否为 root。/var/empty/sshd must be owned by root and not group or world-writable：这个基本上是源码编译升级后最常见的问题，新版 sshd 默认使用了--with-privsep-path=/var/empty，而该目录权限不对。修复方法：sudo mkdir -p /var/empty/sshd && sudo chmod 755 /var/empty/sshd && sudo chown root:root /var/empty/sshd。
第二步，检查配置文件是否被覆盖或语法不兼容。新版本对某些老选项更加严格，推荐用sudo sshd -T来测试实际生效的配置值，而不是只看表面配置。比如：
sudo /usr/local/sbin/sshd -T | grep -E 'permitrootlogin|passwordauthentication'可以快速确认当前生效的认证策略。
第三步，检查防火墙和 hosts.allow/deny。
sudo ufw status sudo iptables -L -n | grep 22如果规则里放行了 22 端口，但服务器上还启用了 fail2ban，可能是 fail2ban 的规则拦截了你的 IP，检查一下 fail2ban 日志。
4.2 连接被拒绝或端口未监听
有时服务显示 active，但实际端口没有监听。排查命令：
sudo ss -lntp | grep ssh如果没有任何输出，说明 sshd 根本没起来。再仔细看一次日志：
sudo journalctl -u sshd --no-pager -n 50日志里如果有sshd: no hostkeys available或sshd: hostkeys not found，说明/etc/ssh/ssh_host_*密钥缺失了，用sudo ssh-keygen -A重新生成即可。注意这个命令会在/etc/ssh/下生成全部默认密钥类型（rsa、ecdsa、ed25519 等）。
如果是fatal: Cannot bind any address，说明端口被占用，通常是系统自带的 sshd 还在运行，或者 ssh.socket 还占着 22 端口。解决思路是把旧服务停掉，禁用 socket 激活：
sudo systemctl stop ssh sudo systemctl stop ssh.socket sudo systemctl disable ssh.socket sudo systemctl start ssh如果端口被其他进程占用，用sudo lsof -i :22查清进程后再处理。
4.3 版本显示未更新
这种情况发生在源码编译后。执行ssh -V显示的还是 8.2p1，但/usr/local/bin/ssh -V显示 9.8p1。原因很简单，shell 的 PATH 顺序问题。执行以下命令检查：
which ssh which sshd echo $PATH如果/usr/local/bin排在/usr/bin前面，则ssh会找到新版。如果排在后面，就会先找到旧版。处理办法有几个：
- 修改用户级 PATH，在
~/.bashrc里把/usr/local/bin提到前面：export PATH=/usr/local/bin:/usr/local/sbin:$PATH。 - 或者像之前一样，直接做软链接覆盖
/usr/bin/ssh。
我建议用软链接方式，因为很多系统服务和脚本会显式调用/usr/bin/ssh，只改 PATH 对 shell 生效，但对 cron 任务和 systemd 服务里的绝对路径不生效。
这里还有一个隐蔽的坑：升级后scp命令如果还在用旧版，传输文件时可能因为协议不兼容而出错。新旧scp默认使用的 SCP 协议有差异，建议 scp、sftp、ssh 三个命令的软链接一起更新。
4.4 升级中断导致服务不可用的应急恢复
升级过程中如果网络中断、编译报错或者服务起不来，最核心的应急手段是回滚。回滚步骤：
# 如果旧版二进制被改名为 .old.bak sudo mv /usr/sbin/sshd.old.bak /usr/sbin/sshd sudo mv /usr/bin/ssh.old.bak /usr/bin/ssh sudo mv /usr/bin/scp.old.bak /usr/bin/scp sudo mv /usr/bin/sftp.old.bak /usr/bin/sftp # 恢复配置备份 sudo cp /etc/ssh/sshd_config.bak.$(date +%F) /etc/ssh/sshd_config # 重启服务 sudo systemctl restart sshd如果服务根本没启动成功，但旧版二进制已经被覆盖，可以先用系统包管理器重装：
sudo apt install --reinstall openssh-server这个命令会从源里拉回旧版（如果没有更新源的话），重新安装并恢复默认配置。注意这不会自动恢复你原来的定制配置，需要手动把备份的配置覆盖回去。
还有一条救援路径：Ubuntu 20.04 如果配置了自动安全更新，或者你有根密码，可以通过单用户模式启动系统，在进入系统后修复 SSH 服务。但单用户模式操作需要物理或控制台访问，远程环境很少具备这个条件，所以再次强调：升级前一定要开一个备用会话，或者确保有带外管理通道。
5. 升级后的安全加固与日常维护
5.1 sshd_config 安全加固建议
版本升级完成后，顺手做一轮 SSH 安全加固很有必要。安全基线要求各不相同，但我通常建议至少覆盖以下几项：
sudo vim /etc/ssh/sshd_config参考配置（按需调整）：
# 修改监听端口（如非必须可不改，但要改就改彻底） Port 22 # 禁止 root 密码登录，但允许 root 密钥登录 PermitRootLogin prohibit-password # 启用密钥登录 PubkeyAuthentication yes # 禁用密码登录，适合密钥统一管理的场景 PasswordAuthentication no # 允许的认证方式，密钥优先 AuthenticationMethods publickey # 限制可登录的用户 AllowUsers devadm deploy # 空闲超时自动断开，避免僵尸会话 ClientAliveInterval 300 ClientAliveCountMax 2 # 最大认证尝试次数 MaxAuthTries 3 # 协议版本 Protocol 2注意PermitRootLogin prohibit-password和PasswordAuthentication no的组合非常关键，既能防暴力破解，又不影响 root 密钥登录。如果你需要密码登录，可以把PasswordAuthentication改成 yes，但生产环境我会建议直接用密钥 + fail2ban 组合。
修改配置后，先执行配置检查：
sudo /usr/local/sbin/sshd -t确认无语法错误后重启服务。重启之前，别忘了在另一个终端保持会话，防止配置错误导致断连。
5.2 验证配置与日常维护
升级和加固完成后，有必要做一轮完整的验证和记录。我习惯做这几件事：
一是连接测试。从一台干净客户端机器上执行：
ssh -v 目标IP -p 端口观察输出里的debug1: Authentications that can continue和最终的Entering interactive session，确认认证流程正常。
二是检查已知主机指纹变化。如果升级前备份过密钥，指纹不会变；如果没备份，客户端首次连接会提示 unknown host key，这个属于正常现象，但要记得更新内部文档里的指纹记录。
三是做一次登录失败的模拟。故意输错密码几次，观察 fail2ban 是否正常封禁 IP，确认安全流程依然有效。
日常维护阶段，定期关注 OpenSSH 官方安全通告，如果有新版发布，评估后按同样的流程升级。这里建议把升级时间放在业务低峰期，避免影响正在进行的连接。
另外，把版本信息和配置文件变更记录整理到内部运维文档里，方便后续接手的人理解当前状态。我在一次生产事故中就是因为文档里没记录端口号，新同事怎么都连不上机器，最后才发现有人把端口改了。这块花不了多少时间，但能规避很多问题。
6. 升级后的兼容性测试记录
6.1 与客户端工具的兼容性
OpenSSH 服务端升级后，客户端兼容性是最容易被忽略的地方。企业内部可能会有各种老旧的客户端工具，比如老的 Windows 自带 SSH、某些网络设备内置的 SSH 客户端、自动化脚本里用的 paramiko 老版本。新版 OpenSSH 默认禁用了部分不安全的算法，比如 ssh-rsa 签名方案、diffie-hellman-group14-sha1 等，会导致旧客户端连不上。
对付这类兼容性问题，一个思路是在新服务端的sshd_config里显式启用旧的算法，但这会让安全加固的效果打折，不建议长期使用。更稳妥的方案是推动客户端升级，或者在使用旧客户端的场景里改用密钥登录、提前更新客户端算法库。
我在实际项目中遇到过 Windows Server 2012 内置 SSH 客户端无法连接新版 OpenSSH 服务端的情况，最终是通过给 Windows 端安装较新的 OpenSSH for Windows 包解决的，服务端不需要为了老客户端做太多妥协。这个思路可以记下来：服务端安全配置优先，客户端兼容问题靠升级客户端解决。
6.2 sftp 子系统的兼容性检查
源码编译升级后，sftp 子系统路径偶尔会出现问题。检查 sftp 是否正常，可以直接在客户端执行：
sftp 用户名@目标IP如果连接后能正常进入 sftp 交互界面，说明子系统配置没问题。如果报错subsystem request failed on channel 0，需要检查sshd_config里的 Subsystem 项是否指向了实际存在的 sftp-server 路径：
Subsystem sftp /usr/lib/openssh/sftp-server如果你的新版编译安装了新的 sftp-server，路径可能变成/usr/local/libexec/sftp-server。上网查一下你安装的版本路径，修改配置后重启 sshd 再测试。
另一个检查点是目录权限。新版 sftp 默认采用更强的 chroot 时，对目录属主和权限要求更严格，如果用户无法上传下载文件，检查目标目录是否为用户可写、路径是否过于开放。
7. 升级过程中值得记录的三个小技巧
第一个技巧：升级前用sshd -T生成当前运行配置的完整备份。这条命令会把实际生效的配置展开输出，比直接看 sshd_config 更可靠，因为里面包含了默认值。执行sudo sshd -T > /tmp/sshd_config_effective_before.txt，升级后同样执行一次，还能对比配置变化，排查问题非常方便。
第二个技巧：源码编译安装后，把 configure 参数和版本号用一个 txt 文件记录在/etc/ssh/目录下。比如/etc/ssh/upgrade_info.txt，里面写上版本号、下载地址、编译参数、升级日期。下次别人接手时看到这个文件，就能快速了解当前环境的版本来源，不用再通过 history 去猜。
第三个技巧：重启 SSH 服务时，不要用systemctl restart sshd一条命令直接干完，先执行配置检查，再执行ssh -t 本机IP自连测试一次。能自连成功，再重启服务。虽然多了一步，但能避免多数配置错误导致的远程中断。
写在最后
升级 OpenSSH 这件事，属于那种"没出事觉得没必要，出事了才知道重要性"的基础运维操作。Ubuntu 20.04 系统默认的 8.2p1 版本并不算太老，但从安全审计、兼容性和统一管理角度，主动升级到 9.x 版本是合理的。整个过程里，备份要彻底、现场要留退路、验证要覆盖全面，这三点比任何单条命令都重要。按照上面的流程走一遍，无论是 apt 源升级还是源码编译，你都能做到心里有底，手上有数。
