木-Star如果你跟我一样在服务器上折腾过几年，CentOS 7 大概是绕不开的一个名字。2014年发布，到现在官方维护周期也已经到了尾声，可你去任何一家还在跑传统业务的公司看看，生产环境里数量最多的往往还是它——稳定、熟人多、资料全，团队接手也快。而只要碰过 CentOS 7，SSH 就是每天打开次数最多的运维入口之一：登录系统、传文件、改配置、排查网络故障，样样都绕不开它。这篇文章围绕 CentOS 7 上的 SSH 相关操作展开，从安装配置、密钥免密、安全加固，到 VSCode 远程开发衔接和常见故障排查，整理成一份可以直接参考的实操记录。适合正在维护 CentOS 7 服务器的运维、开发，以及刚接触 Linux 想少踩坑的新手。
1. 从零准备：CentOS 7 安装后的基础环境整理
1.1 安装镜像选择与安装阶段的几个细节
谈到 CentOS 7，网上搜索量最大的就是“centos7镜像下载”和“虚拟机安装centos7”。实际上安装这个系统难度不算高，但版本选择容易让人犹豫：官方 DVD、Minimal、Everything 三种镜像差别很大。Minimal 体积小，只有最基础的环境，装完以后连网卡、编辑器都要自己配，适合熟悉命令行的人；Everything 包含几乎所有组件，适合离线环境或需要预装大量软件的场景；DVD 是折中选项，日常学习和服务器部署都够用。
我偏爱在某些内网测试环境里用 Minimal 镜像起步，因为组件越少，后续出安全问题的面就越小。安装阶段有几个容易忽略的细节：硬盘分区建议手动分区，/boot 给 1G 左右，/ 和 /home 根据业务拆分，SWAP 在物理机内存偏小的情况下宁多勿少；网络配置不要直接依赖安装界面的“自动获取”，等系统起来后马上固定 IP，否则 DHCP 分配的地址一变，SSH 就找不到机器了。
还有一个在 VMware 里装系统的经验：默认网卡连接方式如果是 NAT 模式，宿主机和虚拟机之间能通，但局域网其他机器不一定能访问到虚拟机。如果之后想在自己电脑上通过 SSH 连虚拟机做实验，建议尽量把网卡模式切成桥接，或至少搞清楚当前网段，避免后面排查了半天，发现是网络模式的问题。
1.2 装完系统后的第一轮网络与源配置
CentOS 7 的网络配置文件放在 /etc/sysconfig/network-scripts/ 下，文件名通常是 ifcfg-ens33 或 ifcfg-eth0，由安装时的网卡名称决定。配置静态 IP 时可以直接编辑文件，也可以使用 nmtui 这个文本图形界面，对新手更友好。我习惯直接用 vim 改文件，关键参数是这几行：
bash复制TYPE=Ethernet
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.1.100
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
DNS1=8.8.8.8
改完以后执行 systemctl restart network 让配置生效。这里的坑在于很多人忘了把 ONBOOT 改成 yes，导致系统重启后网卡没有自动启动，远程连接自然就断了。CentOS 7 的 NetworkManager 服务默认情况下会自动接管网卡，如果改了配置文件不生效，可以先执行 nmcli con reload，再执行 nmcli con up "你的连接名"。
系统源也是新装机器比较重要的点。CentOS 7 停止维护后，官方默认源里的地址已经无法正常更新，建议第一时间把 yum 源切换到还维护中的镜像站。具体操作是把 /etc/yum.repos.d/CentOS-Base.repo 里的 mirrorlist 禁用，替换为可用镜像地址，再执行 yum clean all && yum makecache。这一步做好以后，后面安装 openssh-server、vim、net-tools 等工具就不会遇到“Could not resolve host”的情况。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. SSH 服务端立起来：安装、配置与生效流程
2.1 确认与安装 OpenSSH 服务
CentOS 7 在 Minimal 安装方式下默认不一定带 sshd 服务，因为最小化安装经常把网络管理工具和一些服务端组件一起砍掉。第一步先检测：
bash复制rpm -qa | grep openssh
systemctl status sshd
如果命令报错或者服务不存在，直接安装 OpenSSH：
bash复制yum install -y openssh-server openssh-clients
systemctl enable sshd --now
安装完成后，用 ss -lntp | grep 22 查看服务是否监听在 22 端口。这个习惯比直接 ping 更靠谱：ping 通只能说明网络层可达，不能说明 SSH 服务一定活着。很多新手判断“连不上”就到防火墙瞎放行，其实问题往往出在 sshd 根本没有启动，或者启动后因为配置语法错误退出了。
CentOS 7 自带的防火墙是 firewalld，默认情况下 SSH 端口是放行的，但如果你装系统时没有启用防火墙，或者后来做过规则清理，就得手动加一条：
bash复制firewall-cmd --permanent --add-service=ssh
firewall-cmd --reload
这里我要强调一个观点：哪怕是在内网测试环境，我也不建议直接把 firewalld 停掉来做“简化”。防火墙最大的作用不是防外部黑客，而是防止你手滑把一个还没配好的服务暴露到整个网段。保持最小放行原则，后面排查问题也会少很多变量。
2.2 sshd_config 里的安全基线长什么样
sshd 的主配置文件是 /etc/ssh/sshd_config。刚装好的系统里这个文件默认大部分参数都被注释，走的是 OpenSSH 编译时的默认策略，这对生产环境来说通常不够严格。我一般会改动这几个地方：
bash复制Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
MaxAuthTries 3
AllowGroups wheel
其中 Port 2222 并不是必须，但公网服务器改掉默认 22 端口，能减少大量来自扫描脚本的恶意尝试。PermitRootLogin no 是安全基线里比较重要的点，禁止 root 直接远程登录，日常操作先登录普通用户再 sudo -i 提权，可以避免很多因授权粒度不清引发的问题。PasswordAuthentication no 则表示禁止密码登录，只允许密钥登录，适合已经完全切换到密钥认证的机器。
如果业务还处在过渡阶段，可以先保留 PasswordAuthentication yes，等所有用户都生成了密钥并验证能登录之后，再关闭密码方式，不要一上来就全上最严配置。
2.3 改完配置怎么让它真正生效
修改 sshd_config 后不要直接重启服务，先做语法校验，这是许多人容易忽略的一步步骤。语法错误会导致 sshd 启动失败，而你已经断开了当前 SSH 连接，后果就是连不上机器，只能去物理控制台处理。
bash复制sshd -t
如果没有任何输出，说明配置文件语法没问题，再执行：
bash复制systemctl reload sshd
注意这里用 reload 而不是 restart。reload 会重新读取配置文件但不会中断现有连接，对正在跑业务的人更友好；restart 会先停掉服务再启动，一旦新配置有问题，当前连接也会被瞬间切断。日常调整端口、认证方式这类改动，我都建议优先 reload。
在 CentOS 7 上还有一个与 SSH 相关但常被忽略的东西：SELinux。系统默认 Enforcing 模式下，如果你把 SSH 端口从 22 改成 2222，SELinux 有可能拦截新端口的监听，导致启动成功但外网连不进来。这时候需要执行：
bash复制yum install -y policycoreutils-python
semanage port -a -t ssh_port_t -p tcp 2222
有些人为了让 SSH 端口马上生效，直接把 SELinux 设成 disabled，我不推荐这样。SELinux 的报错都能在 /var/log/messages 或 ausearch -m AVC 里看到，花几分钟学会放行端口，比关掉整个安全机制划算得多。
3. SSH 免密登录配置：密钥生成与批量分发
3.1 密钥对生成背后的逻辑
密码登录的方式很简单，但每次连接都要输入一遍密码，而且密码一旦设置得不够复杂，暴力破解只是时间问题。SSH 密钥认证的原理可以理解成一把钥匙配一把锁：公钥是锁，放在服务器上；私钥是钥匙，放在自己电脑上。服务器看到客户端出示的私钥能和自己保存的公钥对上，就允许登录。别人即使复制了公钥也没有用，因为公钥只能验证、不能反推私钥。
生成密钥对的方法：
bash复制ssh-keygen -t ed25519 -C "your_email@example.com" -f ~/.ssh/id_ed25519
为什么要用 ed25519 而不是传统的 RSA？因为它基于椭圆曲线算法，密钥短、生成速度快、安全性更高，OpenSSH 6.5 以上版本都支持。CentOS 7 自带的 OpenSSH 版本通常较老，如果客户端或服务端有兼容性问题，退一步可以生成 RSA 4096：
bash复制ssh-keygen -t rsa -b 4096 -C "your_email@example.com" -f ~/.ssh/id_rsa
生成过程中会要求设置 passphrase，也就是私钥口令。直接回车可以不设置，但不设置私钥文件一旦泄露就等于把钥匙给了别人，所以在个人电脑上我还是建议加一层 passphrase。配合 ssh-agent 使用时只需要输入一次，不用每次都敲。
3.2 用 ssh-copy-id 完成首次公钥分发
公钥生成以后，下一步是把公钥放到服务器上。手动操作的话，需要登录服务器，把公钥内容追加到 ~/.ssh/authorized_keys 文件里，同时设置好目录和文件的权限：
bash复制mkdir -p ~/.ssh
chmod 700 ~/.ssh
vi ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
这一步的权限特别关键：如果 .ssh 目录或 authorized_keys 文件的权限过于宽松，OpenSSH 为了安全会拒绝加载这个公钥，表现出来就是你明明把公钥贴上去了，免密登录还是不生效。
更省事的方式是使用 ssh-copy-id，它会自动帮你完成目录创建、公钥追加和权限设置：
bash复制ssh-copy-id -i ~/.ssh/id_ed25519.pub user@192.168.1.100
如果 SSH 端口不是默认 22，需要加 -p 参数：
bash复制ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 user@192.168.1.100
执行时会要求输入一次密码，这是唯一一次需要密码的机会。完成后直接执行 ssh -p 2222 user@192.168.1.100 验证，能免密登录说明配置正常。
3.3 批量登录场景的密钥分发思路
很多热词里都有“ssh批量登录”，真实运维中确实存在一批机器需要批量推送密钥的场景。最简单粗暴的做法是写一个 shell 循环：
bash复制for host in 192.168.1.101 192.168.1.102 192.168.1.103; do
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@${host}
done
但这个办法要求每台机器密码一致或者你能交互式输入密码，否则循环会卡在密码提示上。更好的做法是用 ansible 的 authorized_key 模块，将本地公钥统一推送到目标机器：
bash复制ansible all -m authorized_key -a "user=root key='{{ lookup('file', '/root/.ssh/id_ed25519.pub') }}'" -k
批量场景下，我建议先挑一两台机器验证，再放开全量执行。不要写一个脚本一次性向 100 台机器推送，一旦公钥内容写错，后续排查会非常痛苦。密钥推送完成后，还可以通过脚本统一检查免密状态：
bash复制for host in $(cat hosts.txt); do
ssh -o BatchMode=yes -o ConnectTimeout=5 -p 2222 root@${host} echo "${host} OK" || echo "${host} FAIL"
done
这里的 BatchMode=yes 很重要，它会让 SSH 在无法免密时直接失败，而不是停下来等待密码输入，避免脚本被某个主机卡住。
4. 安全加固：限制 root 与 wheel 组成员登录的完整操作
4.1 为什么要限制 root 直接远程登录
很多刚从 Windows 转过来的人，习惯了 Administrator 直接登录，觉得每次用普通用户再 sudo 很麻烦。但 root 是 Linux 系统的最高权限账号，如果它可以直接从远程密码登录，攻击者只需要爆破 root 密码就能获得整台服务器的控制权。相比之下，普通用户即使被爆破，权限也有限，攻击者还得继续提权，入侵成本高了不少。
在 CentOS 7 中，禁止 root 远程登录只需要把 sshd_config 里的参数改成：
bash复制PermitRootLogin no
但直接改这个参数前，必须先确认自己有一个可以 sudo 的普通用户。我见过不少案例是管理员先用 root 登录，改完 PermitRootLogin no 后当前连接因其他原因断开，之后想再登录才发现没有可用用户，只能去机房接显示器进系统恢复。所以顺序很重要：先建用户、加入 wheel 组、测试 sudo，再改 SSH 配置。
创建普通用户并加入 wheel 组的命令：
bash复制useradd ops
passwd ops
usermod -aG wheel ops
然后切换到该用户测试 sudo whoami，能输出 root 说明提权没问题。测试通过后再修改 sshd 配置，并在另一个终端里保持一个已登录的 root 会话作为安全后路。
4.2 实现“只允许 wheel 组登录”的两种方式
网上经常问“设置只有 wheel 组的用户可以 ssh 远程登录”，这个需求在 CentOS 7 里实现起来有两种写法。第一种是直接在 sshd_config 里加一行：
bash复制AllowGroups wheel
第二种使用 Match Group 语句，灵活度更高，可以在同一个文件里对不同组应用不同策略：
bash复制Match Group wheel
PasswordAuthentication yes
第一种适用于整机只允许 wheel 组登录；第二种适合需要临时放行某个组、但又想保留其他安全选项的情况。需要注意，AllowGroups 的匹配依据是用户的主要组，而不是附加组。如果用户 ops 以 ops 为主组，同时被追加到 wheel 组，AllowGroups wheel 依然会生效，因为 OpenSSH 在匹配成员时会检查附加组。实际验证方法也很简单：登录失败后看 /var/log/secure 里的记录，里面会明确写出拒绝原因。
与 root 限制一样，加完 AllowGroups wheel 后要立刻用另一个终端验证。我之前给一台测试服务器加这条规则后，马上被自己挡在外面，原因是我测试用的用户虽然加入了 wheel 组，但主组是 users，当时以为 AllowGroups 只认主组，就先把用户主组改了，结果旧连接退出后新连接全部失败。后来才明白匹配逻辑跟主组还是附加组没关系，纯属调试时的多余动作。
4.3 防止把自己锁在门外的应急机制
远程改 SSH 配置，最怕的就是改坏了还断了当前连接。这里分享几个常用的保险手段。第一，改配置前先备份：
bash复制cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
第二，利用 SSH 连接不会因为 reload 而断开的特点，保持当前终端不关，另开一个新终端测试。新终端能登录成功，说明改动没问题；万一新终端登不上，旧终端还在，可以马上回滚配置。
第三，还可以设置一个定时恢复脚本兜底。比如在修改 sshd_config 前执行：
bash复制(sleep 300 && cp /etc/ssh/sshd_config.bak.$(date +%F) /etc/ssh/sshd_config && systemctl reload sshd) &
这个命令会在 5 分钟之后自动恢复配置。如果这 5 分钟内你的修改验证通过，就手动 kill 掉这个后台任务，防止它在未来某个时间点突然把配置恢复回去。看起来有点小题大做，但在没有物理控制台可用的云端服务器上，这种做法确实能在关键时刻救命。
4.4 端口、防爆破与 fail2ban 的配合
除了限制用户和认证方式，修改默认端口也是减少被扫描的有效手段。改了端口之后，还要同步更新 SELinux 放行规则和 firewalld 放行规则，否则外部依然无法访问：
bash复制firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --reload
如果服务器放在公网，且暂时无法关闭密码登录，可以考虑安装 fail2ban 监控登录失败记录，超过阈值就临时封禁 IP：
bash复制yum install -y epel-release
yum install -y fail2ban
配置 /etc/fail2ban/jail.local，监控 sshd 的日志路径。CentOS 7 的 sshd 日志默认写在 /var/log/secure，不是 Ubuntu 的 /var/log/auth.log，这个差异经常让跨平台管理员栽跟头。fail2ban 生效后，能在一定程度上抑制暴力破解，但你仍然别把密码登录当成长期方案，尽量尽早切到密钥认证。
5. 从命令行到远程开发工作流：VSCode 与文件传输
5.1 VSCode Remote-SSH 连接 CentOS 7 的配置方式
热词里“vscode连接ssh远程服务器”出现频率很高，说明现在大量开发场景都从本地开发转移到了远程服务器开发。VSCode 的 Remote-SSH 插件本质上是把本地的编辑界面连接到远程机器，在远程执行代码、安装插件、调试程序，体验和本地几乎一致。
先在本机安装“Remote - SSH”扩展，然后打开命令面板输入 “Remote-SSH: Connect to Host”，选择新建 SSH Host，填写类似 user@192.168.1.100 -p 2222 的地址。为了长期使用，建议把服务器信息写进本地 ~/.ssh/config 文件：
text复制Host dev-server
HostName 192.168.1.100
User ops
Port 2222
IdentityFile ~/.ssh/id_ed25519
配置好后，VSCode 左侧会出现一个远程资源管理器，点开就能看到这台服务器。首次连接成功后需要等待 VSCode Server 在远程安装，这个过程依赖目标机器能访问外网或内网镜像。如果服务器处于完全离线环境，可以先把 vscode-server 的压缩包手动传到 /root/.vscode-server/bin/ 对应目录下，否则插件一直转圈却连不上，多半是服务端没装好。
远程打开源码目录后，需要把 Python、Go、GitLens 这类插件装到“SSH: dev-server”这个远程环境里，而不是本地。很多新手在这里困惑，因为插件列表里明明已经安装了 GitLens，但远程 VSCode 还是感知不到，原因就是他没有切换到远程扩展面板重新安装。
5.2 scp、rsync 与 sftp 文件传输实操
文件传输是 SSH 最常用的附加能力。命令行环境下，scp 是最容易上手的工具：
bash复制scp -P 2222 ./app.tar.gz ops@192.168.1.100:/tmp/
注意 scp 指定端口是大写 -P，而 ssh 和 ssh-copy-id 是小写 -p，这个大小写差别坑过很多跨平台的人。从远程下载文件则是把顺序倒过来：
bash复制scp -P 2222 ops@192.168.1.100:/var/log/nginx/access.log ./
rsync 比 scp 更强的地方在于增量同步，只传输变化的文件，适合反复同步目录。基本用法：
bash复制rsync -avzP -e "ssh -p 2222" ./dist/ ops@192.168.1.100:/var/www/html/
参数里 -a 表示归档模式，保留权限和时间戳；-z 表示压缩传输；-P 会显示进度条并支持断点续传。如果是首次执行，目标目录已经有大文件，加上 --delete 可以删除源目录中已经不存在的文件，但使用这个参数前一定要确认目标目录没有额外内容，否则容易被删爆。
Windows 用户如果不习惯命令行，可以用 WinSCP 或 Bitvise SSH Client 这类图形客户端。Bitvise 同时提供 SFTP 文件和终端窗口，操作体验比较接近商业 FTP 工具，许多医疗、政务内网项目里的管理员都用它做日常文件维护。本质上它走的还是 SSH 协议，跟命令行的配置逻辑一样。
5.3 配合 GitLab/Gerrit 管理代码密钥
团队开发中经常会在 CentOS 7 服务器上安装 GitLab 或 Gerrit 作为代码仓库。代码仓库的 SSH 访问同样需要密钥认证，但不是把公钥放在服务器用户目录下，而是要把公钥配置到代码仓库平台的“SSH Keys”里。比如 GitLab 的设置页面有 SSH Keys 入口，把本机的 ~/.ssh/id_ed25519.pub 内容完整粘贴进去，保存后就能通过 git clone git@gitlab.example.com:group/project.git 拉代码。
如果是同一台机器需要同时使用多个代码平台或不同账号的密钥，建议在 ~/.ssh/config 里指定不同的 IdentityFile：
text复制Host gitlab.company.com
User git
Port 2222
IdentityFile ~/.ssh/id_ed25519_gitlab
这在配 Gerrit 时尤其常见，因为 Gerrit 要求推代码时使用独立生成的密钥，不能直接复制通用公钥。配置完代码平台后，可以用 ssh -T git@gitlab.company.com 测试连通性，看到欢迎信息就代表认证成功。
6. 踩坑记录：SSH 常见连接问题排查
6.1 连接失败类问题定位思路
SSH 连接失败的表现千奇百怪，但归纳起来基本两大类：超时和拒绝。“Connection timed out”说明请求发出去了，但没有任何响应，问题大概率出在网络路径、防火墙或对方主机关机；而“Connection refused”说明对方的网络栈已经收到请求并返回了拒绝，通常意味着端口没有监听，或者监听的 IP 不是你想连的那个。
排查超时问题时，先看本机到目标主机的路由通不通：
bash复制ping 192.168.1.100
telnet 192.168.1.100 2222
如果 ping 通但 telnet 连不上，大概率是服务器防火墙拦截了端口。再看服务器端：
bash复制systemctl status sshd
ss -lntp | grep 2222
firewall-cmd --list-all
这套组合拳打完，80% 的“连不上”问题都能定位。如果 sshd 显示 active 但 ss 里没有监听端口，检查 SELinux 是否拦截了新端口：ausearch -m AVC -ts recent 能看最近被拒的事件。
6.2 Host key verification failed 与 known_hosts
服务器重装系统或从虚拟机模板克隆后，经常出现“Host key verification failed”的报错。原因很简单：客户端的 ~/.ssh/known_hosts 里已经保存了这台服务器“旧”的主机指纹，现在服务器的公钥变了，客户端认为可能存在中间人攻击，于是拒绝连接。
还有一种常见原因：公司有多台虚拟机共享同一个 IP，老机器销毁后 IP 被分配给新机器，新机器返回的 Host Key 自然不同。此时需要在客户端删除旧指纹：
bash复制ssh-keygen -R 192.168.1.100
-R 会把 known_hosts 中该主机的旧记录移除，下次连接时会重新提示确认新指纹。如果是一台全新机器，连接时出现的指纹提示要仔细核对系统安装完成后控制台显示的指纹，而不是盲目点 yes。不过大多数内网环境里，大家图方便都是直接输入 yes，只要不是公网服务器，风险也可以接受。
6.3 登录特别慢、密码反复不对的排查
SSH 登录需要等待很久才提示输入密码，这个现象我在 CentOS 7 上经常遇到。主要原因有两个：sshd 默认开启了 DNS 反向解析，客户端 IP 无法正确反解时，服务器会反复等待超时；另外 GSSAPIAuthentication 在部分环境下也会增加延迟。解决方案是在 sshd_config 末尾添加：
bash复制UseDNS no
GSSAPIAuthentication no
然后 reload。很多网上的教程直接把 GSSAPIAuth 全部关掉，但在需要使用 Kerberos 认证的公司内部网络里，这会带来额外问题，建议先加 UseDNS no 观察效果。
“密码反复不对”的情况，先看是否大小写锁定，再确认目标服务器是否修改过认证方式。如果你已经执行过密钥认证相关配置，却把 PasswordAuthentication 顺手设成了 no，那么输入密码时系统会直接拒绝。检查 /var/log/secure：
bash复制tail -50 /var/log/secure
日志里能看到 “Failed password” 和 “Connection closed by authenticating user” 这类记录，能明确指出是哪一步被拒绝。连接目标如果是指 GitHub 这类云端代码托管平台，且 22 端口一直 connection refused，通常不是服务器问题，而是网络出口对 22 端口做了限制。这种时候用 HTTPS 方式克隆仓库往往是更省事的应急方案。
6.4 高频问题速查表
| 现象 | 常见原因 | 快速处理 |
|---|---|---|
| Connection timed out | 网络不通、防火墙丢弃包 | ping、telnet 分层排查 |
| Connection refused | sshd 未启动、端口错误、监听地址不对 | systemctl status sshd、ss -lntp |
| Permission denied | 密钥不匹配、密码错误、认证方式被禁 | 查看 /var/log/secure |
| Host key verification failed | 服务器重装或 IP 复用 | ssh-keygen -R IP |
| 登录慢 | DNS 反解、GSSAPI 认证 | sshd_config 加 UseDNS no |
| 免密登录不生效 | authorized_keys 权限不对或路径不对 | chmod 600 / 700 并检查用户目录 |
这张表基本覆盖了我日常运维中遇到的大部分 SSH 问题。每一条背后都对应真实的场景，处理时不要一上来就重启服务，先看日志再做判断，能省下不少无意义的等待。
最后分享一个我个人坚持到现在的小习惯：每次修改 sshd_config 之前，先备份带日期的文件，然后在另一个终端保留一个已经通过密钥登录的会话，把“改配置、sshd -t 校验、systemctl reload sshd、新终端验证”这四步完整走一遍，确认没有问题后再退出备用会话。这套流程看起来保守，但它确实帮我在多台服务器的维护中避免了至少三次灾难性的远程失联。CentOS 7 虽然进入了维护尾声，但现有环境里的存量机器还会持续运行很长时间，把 SSH 日常操作吃透，后续无论迁移到什么系统，底层逻辑都是想通的。