1. 为什么必须用 SSH 密钥替代密码登录 CentOS这不是“可选项”而是生产环境的生存底线你刚在 VMware Workstation Pro 里装好 CentOS 7 Minimal配好 NAT 网络ifconfig看到 IP 是192.168.122.101接着打开 VS Code装上 Remote-SSH 插件输入ssh user192.168.122.101—— 回车输密码连上了。看起来很顺别急这恰恰是你系统安全链条上第一个正在松动的螺丝。我见过太多人在虚拟机里搭测试环境时图省事全程用密码登录结果某天想把服务迁到云服务器或者被同事临时接入调试一不留神就暴露了 root 密码更常见的是VS Code 的 Remote-SSH 频繁重连时反复弹密码框一烦之下干脆把密码写进配置文件——这等于把家门钥匙焊死在门框上。而真正致命的是暴力破解 SSH 密码的脚本每分钟能尝试上千个组合只要你的用户名是root或admin哪怕密码设成Pssw0rd2024!也扛不过 48 小时。CentOS 默认的sshd服务监听 22 端口它不挑食来者不拒但你得替它把关。密钥登录的本质是把“你知道什么”密码升级为“你拥有什么”私钥文件。ssh-keygen生成的是一对数学上强绑定的密钥公钥可以随便贴在服务器.ssh/authorized_keys里谁都能看但私钥一旦泄露整个身份就崩塌。所以实操中我们永远只在本地保存私钥且必须加密保护服务器端只存公钥连密码都不需要。当你执行ssh usercentos-host时客户端用私钥解密服务器发来的随机挑战成功即放行——整个过程没有明文密码在网络上传输也没有密码被服务器存储暴力破解直接失效。这解释了为什么所有主流热词都绕不开它vscode连接ssh远程服务器要稳定免密ssh 免输入密码 vscode是刚需git配置ssh密钥是为了git clone gitgithub.com:user/repo.git不卡壳centos安装docker后要批量部署容器没密钥登录根本没法自动化。它不是炫技而是让 CentOS 从“能用”走向“敢用”的分水岭。你不需要成为密码学专家但必须亲手跑通ssh-keygen -t ed25519 -C your_emailexample.com这一行命令并理解每个参数背后的重量——这才是今天这篇文章的起点。1.1 密钥类型选型为什么推荐 ed25519而不是默认的 rsassh-keygen默认生成 RSA 密钥-t rsa但如果你查过man ssh-keygen或翻过 OpenSSH 官方文档会发现它早已明确标注“Ed25519 is the preferred public key algorithm”。这不是厂商营销话术而是有硬核数学支撑的结论。RSA 的安全性依赖于大数分解难题密钥长度必须拉到 3072 位甚至 4096 位才能对抗现代算力。而 Ed25519 基于椭圆曲线Curve25519其 256 位密钥提供的安全强度等效于 RSA 3072 位。这意味着同样安全等级下Ed25519 密钥体积小 12 倍签名速度快 2 倍验签速度快 1.5 倍。在资源有限的 CentOS 虚拟机尤其是 1G 内存起步的 Minimal 版本上每次 SSH 连接握手时的 CPU 开销Ed25519 几乎可以忽略不计而 RSA 4096 则可能让老旧 CPU 明显卡顿。实测对比在 VMware 中分配 1 核 CPU、1GB 内存的 CentOS 7.9 虚拟机生成密钥耗时ssh-keygen -t rsa -b 4096平均 2.3 秒ssh-keygen -t ed25519平均 0.15 秒单次 SSH 登录握手时间time ssh -o ConnectTimeout5 -o BatchModeyes userlocalhost exitRSA 4096 为 180msEd25519 为 85ms.ssh/id_ed25519.pub文件大小112 字节.ssh/id_rsa.pub4096 位740 字节。更重要的是兼容性。OpenSSH 6.5CentOS 7 自带的 openssh-6.6.1p1 完全支持、Ubuntu 14.04、macOS 10.12、Windows 10 1809 的 OpenSSH 客户端全部原生支持 Ed25519。唯一需要警惕的是极少数老旧设备如某些网络设备的 SSH 服务端但你在 CentOS 上做服务器客户端是 VS Code、Terminal 或 Git Bash完全无需妥协。提示如果你的 CentOS 版本低于 7比如还在用 CentOS 6则必须用-t rsa -b 4096因为其 OpenSSH 版本太老不支持 Ed25519。但请立刻把它列入淘汰清单——CentOS 6 已于 2020 年底停止维护连基础安全补丁都不再提供。1.2 为什么ssh-copy-id是最安全的公钥分发方式手动复制错一个字符就白忙很多人卡在第二步公钥怎么传到 CentOS 服务器网上教程五花八门有人教你cat ~/.ssh/id_rsa.pub | ssh usercentos mkdir -p ~/.ssh cat ~/.ssh/authorized_keys有人让你用scp把公钥文件传过去再cat进去还有人直接vi ~/.ssh/authorized_keys手动粘贴。这些方法看似可行但埋着三个雷权限失控mkdir -p ~/.ssh如果没加chmod 700 ~/.ssh目录权限过大比如 755sshd会直接拒绝登录报错Authentication refused: bad ownership or modes格式污染手动粘贴时Windows 换行符\r\n、多余空格、中文全角符号混入会导致authorized_keys文件解析失败SSH 登录时静默拒绝连错误日志都难定位原子性缺失cat 是追加操作如果authorized_keys原本就有内容新公钥末尾没换行两行密钥会粘连成一行彻底失效。ssh-copy-id就是为解决这些问题而生的。它不是一个花哨工具而是 OpenSSH 自带的 shell 脚本路径通常是/usr/bin/ssh-copy-id内部逻辑极其严谨先检查目标用户~/.ssh目录是否存在不存在则创建并chmod 700将公钥内容写入一个临时文件严格校验换行符和空白字符使用umask 077确保新生成的authorized_keys权限为600最后执行cat追加但会在追加前确保文件末尾有换行符。执行ssh-copy-id -i ~/.ssh/id_ed25519.pub user192.168.122.101后它会自动完成所有权限设置和格式校验。你只需要输入一次密码后续所有连接都免密。这是经过千万次生产验证的“傻瓜式”安全分发比任何手动操作都可靠。记住只要ssh-copy-id成功返回Number of key(s) added: 1你就已经赢了一半。2. 从零开始CentOS 7 环境准备与密钥生成全流程拆解在动手之前请确认你的 CentOS 7 虚拟机已满足最低运行条件。这不是过度谨慎而是避免后续排查时陷入“环境问题”的泥潭。VMware Workstation Pro 中安装 CentOS 7 Minimal 后务必执行以下三步初始化网络连通性自检ping -c 3 192.168.122.1 # 测试能否访问 VMware 的 NAT 网关 ping -c 3 www.baidu.com # 测试外网 DNS 解析与连通性如果第一步失败说明 VMware NAT 网络未启用或虚拟网卡未桥接如果第二步失败但第一步成功则是 DNS 配置问题检查/etc/resolv.conf是否有nameserver 8.8.8.8。这两个问题不解决ssh-copy-id会卡在“Could not resolve hostname”——这正是热词ssh: could not resolve hostname d: name or service not known的典型场景。防火墙放行 SSH 端口CentOS 7 默认启用firewalld它比旧版iptables更易管理但也更“固执”。执行sudo firewall-cmd --permanent --add-servicessh sudo firewall-cmd --reload注意--permanent参数没有它重启后规则丢失。你可以用sudo firewall-cmd --list-all验证ssh服务是否在services:列表中。别试图关闭防火墙systemctl stop firewalld那等于拆掉房子的承重墙——正确的做法是精准放行而非裸奔。SELinux 状态确认sestatus查看 SELinux 状态。如果是enforcing强制模式无需改动如果是permissive宽容模式建议改为enforcingsudo setenforce 1 修改/etc/selinux/config中SELINUXenforcing唯独要警惕disabled状态——它虽不拦截但会让sshd的某些安全特性如UsePAM yes下的密码策略联动失效。SELinux 是 CentOS 的核心防护层禁用它等于主动卸甲。完成环境准备后回到你的本地机器Windows/macOS/Linux打开终端执行密钥生成命令。这里必须强调一个被 90% 教程忽略的关键点密钥必须绑定一个有意义的邮箱标识而非留空。ssh-keygen -t ed25519 -C devmycompany.local -f ~/.ssh/id_centos_prod参数详解-t ed25519指定密钥类型如前所述首选-C devmycompany.local-C是 comment注释它不参与加密但会写入公钥末尾成为id_centos_prod.pub文件的最后一段。这个字符串是你未来管理多套密钥的“标签”。比如你有id_github、id_aws、id_centos_test当某天ssh -T gitgithub.com失败时看一眼ssh-add -l输出的 comment就能秒级定位是哪套密钥出了问题-f ~/.ssh/id_centos_prod-f指定密钥文件名。强烈反对使用默认名id_rsa或id_ed25519。原因很简单当你同时管理 GitHub、GitLab、公司内网 CentOS、AWS EC2 多个环境时所有密钥都叫id_rsassh-add会混乱加载ssh -i参数也极易写错。用描述性文件名如id_centos_prod是职业习惯的第一课。执行后系统会提示Enter passphrase (empty for no passphrase):。请务必输入一个强密码短语passphrase而非留空。这层密码是保护你私钥文件的最后一道锁。即使别人窃取了你的笔记本电脑没有这个 passphrase他无法用你的私钥登录任何服务器。Passphrase 可以比密码更长、更易记比如MyCentOS2024!Secure因为它只在本地输入不传输。生成完成后你会得到两个文件~/.ssh/id_centos_prod你的私钥绝对不可分享不可上传到任何云盘或 Git 仓库~/.ssh/id_centos_prod.pub你的公钥可以自由分发。注意ssh-keygen生成的私钥默认权限是600仅所有者可读写这是正确的。但如果你用cp或其他方式复制过密钥文件务必手动修复chmod 600 ~/.ssh/id_centos_prod。sshd对私钥权限极其敏感任何宽松权限都会导致连接失败。2.1 公钥分发实战ssh-copy-id的隐藏参数与故障应对现在把公钥送到 CentOS 服务器。假设你的 CentOS 用户名为centosIP 为192.168.122.101执行ssh-copy-id -i ~/.ssh/id_centos_prod.pub centos192.168.122.101正常流程是输入centos用户密码 → 等待几秒 → 输出Number of key(s) added: 1→ 完毕。但现实往往更复杂。以下是我在真实环境中踩过的坑及应对方案问题1ssh-copy-id报错ERROR: No identities found原因ssh-copy-id默认只找~/.ssh/id_rsa.pub、~/.ssh/id_dsa.pub等固定名称找不到你自定义的id_centos_prod.pub。解决方案必须显式用-i参数指定路径如上命令所示。切勿省略。问题2连接被拒绝提示Connection refused原因CentOS 的sshd服务未运行或防火墙拦截。排查步骤在 CentOS 上执行sudo systemctl status sshd确认状态为active (running)若未运行sudo systemctl start sshd sudo systemctl enable sshdenable确保开机自启再执行sudo firewall-cmd --list-all | grep ssh确认ssh在服务列表中。问题3ssh-copy-id成功但 SSH 登录仍要密码这是最高频的故障。根本原因几乎全是权限问题。在 CentOS 上执行以下诊断命令# 1. 检查 .ssh 目录权限 ls -ld ~centos/.ssh # 正确输出应为drwx------. 2 centos centos ... .ssh # 如果是 drwxr-xr-x则执行chmod 700 ~centos/.ssh # 2. 检查 authorized_keys 文件权限 ls -l ~centos/.ssh/authorized_keys # 正确输出应为-rw-------. 1 centos centos ... authorized_keys # 如果是 -rw-r--r--则执行chmod 600 ~centos/.ssh/authorized_keys # 3. 检查文件所有者 ls -l ~centos/.ssh/ # 所有文件所有者必须是 centos 用户不能是 root。如果是 root执行sudo chown -R centos:centos ~centos/.ssh实操心得我曾在一个客户环境里因chown误操作将~centos/.ssh所有者改为rootsshd日志/var/log/secure里只有一行Authentication refused: bad ownership or modes毫无头绪。后来用ls -l逐级检查所有者才定位到根因。权限问题永远是 SSH 密钥登录失败的第一怀疑对象没有之一。2.2 VS Code Remote-SSH 的终极配置告别ssh: connect to host xxx port 22: Connection refusedvscode连接ssh远程服务器和ssh 免输入密码 vscode是开发者最迫切的需求。VS Code 的 Remote-SSH 插件强大但配置稍有不慎就会触发ssh connection reset by peer或Could not establish connection to...。核心在于VS Code 不读取你终端里的ssh-agent它需要独立的、显式的密钥路径配置。第一步在 VS Code 中按CtrlShiftPWindows/Linux或CmdShiftPmacOS输入Remote-SSH: Connect to Host...选择Add New SSH Host...。第二步输入连接字符串这里必须精确到端口和密钥路径ssh -i /Users/yourname/.ssh/id_centos_prod centos192.168.122.101注意Windows 用户路径用正斜杠/如C:/Users/yourname/.ssh/id_centos_prod引号必须包裹整个路径防止空格导致解析错误-i参数不可省略这是 VS Code 识别密钥的唯一方式。第三步VS Code 会提示你选择配置文件位置推荐~/.ssh/config然后自动生成如下内容Host centos-prod HostName 192.168.122.101 User centos IdentityFile ~/.ssh/id_centos_prod关键来了这个IdentityFile路径是相对于 VS Code 进程的不是相对于你的 Shell。如果你在 macOS 或 Linux 上~指向当前用户家目录没问题但在 Windows 上VS Code 可能以不同用户上下文启动~可能指向错误位置。最稳妥的做法是写绝对路径Host centos-prod HostName 192.168.122.101 User centos IdentityFile /Users/yourname/.ssh/id_centos_prod最后点击centos-prod主机名VS Code 会调用系统ssh命令连接。首次连接会提示你输入 passphrase就是你生成密钥时设的那个输入后即可进入远程窗口。此后所有操作文件浏览、终端、调试都走这条密钥通道ssh 免输入密码 vscode完全实现。提示如果 VS Code 连接后报错Error: Failed to fetch remote environment大概率是 CentOS 的bash或zsh配置文件~/.bashrc里有echo或printf输出语句。SSH 连接时这些输出会污染环境变量协商导致 VS Code 解析失败。解决方法在~/.bashrc开头添加[[ $- ! *i* ]] return确保非交互式 Shell 不执行后续命令。3. 深度加固sshd_config的 7 个关键参数调优与原理剖析sshd_config是 OpenSSH 服务端的圣经位于/etc/ssh/sshd_config。它默认配置足够“能用”但离“生产可用”差得很远。热词ssh配置、centos配置tomcat等背后都指向同一个事实服务器配置不是一劳永逸的而是需要根据实际场景持续精调。下面这 7 个参数是我十年运维中每台 CentOS 服务器上线前必改的“安全基线”。3.1Port 22→Port 2222端口挪移不是玄学而是过滤噪音的第一道筛子把 SSH 端口从默认的 22 改成 2222或其他高位端口常被质疑“只是隐蔽性安全security through obscurity”。这种观点在学术上没错但在工程实践中它价值巨大。原因在于绝大多数自动化攻击脚本如 Shodan 扫描器、Mirai 僵尸网络只扫描 22、2222、22222 等常见端口而不会遍历 65535 个端口。修改方法sudo vi /etc/ssh/sshd_config # 找到 #Port 22 这一行去掉注释改为 Port 2222然后重启服务sudo systemctl restart sshd。但这只是开始。端口改了防火墙规则必须同步更新sudo firewall-cmd --permanent --remove-servicessh sudo firewall-cmd --permanent --add-port2222/tcp sudo firewall-cmd --reload否则firewalld依然只放行 22 端口你的新端口会被无情拦截。注意Port参数支持多行例如Port 2222和Port 22同时存在表示sshd监听两个端口。这在迁移期很有用先开双端口测试新端口无误后再关闭旧端口。但生产环境严禁长期双开会扩大攻击面。3.2PermitRootLogin no根用户登录不是便利而是定时炸弹PermitRootLogin yes是 CentOS 默认值意味着ssh rootcentos-host可以直接登录。这在早期运维中方便但代价是灾难性的。一旦 root 密码泄露或密钥被盗攻击者获得的是上帝权限可以rm -rf /、dd if/dev/zero of/dev/sda系统瞬间归零。正确做法是永远禁止 root 直接登录只允许普通用户登录再用sudo提权。修改sshd_configPermitRootLogin no这样即使你的 root 密钥被窃也无法通过 SSH 登录。攻击者必须先猜中一个普通用户密码或密钥再突破sudo权限难度指数级上升。配套措施确保你的普通用户如centos在sudoers中有充分权限。执行sudo visudo添加centos ALL(ALL) NOPASSWD: ALLNOPASSWD表示该用户执行sudo命令时无需再次输入密码兼顾安全与效率。3.3PasswordAuthentication no密钥登录的“最终判决书”当PasswordAuthentication yes时sshd会同时接受密码和密钥两种认证方式。这看似“兼容旧习惯”实则是安全漏洞。因为只要密码认证还开着暴力破解脚本就不会停止尝试。PasswordAuthentication no是密钥登录的“最终判决书”。它强制所有连接必须通过密钥认证密码通道彻底关闭。修改后PasswordAuthentication no重启sshd后ssh usercentos-host如果没配密钥会直接报错Permission denied (publickey)没有任何密码输入机会。警告修改此参数前必须确保至少一套密钥已通过ssh-copy-id成功部署并能稳定登录。否则你将被永久锁在服务器门外。我的标准操作是先用密钥登录成功 → 打开第二个终端窗口 → 修改sshd_config→sudo systemctl restart sshd→ 在第一个窗口验证新连接 → 确认无误后再关闭旧窗口。永远保留一条“逃生通道”。3.4MaxAuthTries 3与LoginGraceTime 30给暴力破解者设下“三秒倒计时”MaxAuthTries控制单次连接中允许的最大认证尝试次数默认是 6。设为 3意味着攻击者只有 3 次机会输入正确的密钥或密码如果密码认证还开着的话。LoginGraceTime控制从 TCP 连接到认证超时的总时间默认 120 秒。设为 30 秒意味着从你输入ssh userhost到连接断开只有 30 秒窗口。这两个参数协同工作大幅增加暴力破解成本每次失败尝试后sshd会延迟响应指数退避第 3 次失败后立即断开连接攻击者必须在 30 秒内完成 3 次尝试否则连接重置一切重来。修改MaxAuthTries 3 LoginGraceTime 303.5ClientAliveInterval 300与ClientAliveCountMax 2终结“SSH 连接 reset by peer”ssh连接reset by peer是 VS Code 和终端用户的噩梦。根源是SSH 连接建立后如果长时间没有数据交互比如你去喝杯咖啡中间的 NAT 设备如 VMware 的虚拟路由器、家用宽带路由器会认为这是“死连接”主动清理其连接跟踪表conntrack导致下次发包时被丢弃客户端收到Connection reset by peer。解决方案是启用 SSH 的心跳保活机制ClientAliveInterval 300 # 每 300 秒5 分钟向客户端发一个空包 ClientAliveCountMax 2 # 连续 2 次心跳无响应则断开连接这样300 * 2 600秒10 分钟内连接始终有活动NAT 设备不会清理。VS Code 的 Remote-SSH 会稳定保持连接不再频繁断线重连。3.6UseDNS no解决ssh: could not resolve hostname的底层逻辑UseDNS yes是默认值它让sshd在每次登录时反向解析客户端 IP 地址对应的主机名PTR 记录然后将该主机名写入日志。这在企业内网有完善 DNS 的环境下有用但在家庭网络、VMware 虚拟网络中客户端 IP如192.168.122.1往往没有 PTR 记录sshd会卡住等待 DNS 超时默认 30 秒导致登录延迟甚至触发ssh: could not resolve hostname错误。关闭它UseDNS nosshd将跳过 DNS 查询直接记录 IP 地址登录速度立竿见影。这不是偷懒而是对网络环境的务实适配。3.7AllowUsers最小权限原则的终极体现AllowUsers参数指定哪些用户可以通过 SSH 登录格式为AllowUsers user1 user2。例如AllowUsers centos deploy这意味着即使sshd配置了PermitRootLogin yesroot用户也无法登录即使有其他用户如test、backup存在他们也被明确拒绝。这是“最小权限原则”的终极体现只允许业务必需的用户登录其他一切皆 deny。它比DenyUsers黑名单更安全因为黑名单总有遗漏而白名单是主动收敛。实操心得我管理的一个集群有 200 台 CentOS 服务器所有sshd_config都统一模板其中AllowUsers行由 Ansible 动态注入。当新员工入职只需在 Ansible 清单里添加其用户名所有服务器自动开通权限离职时一键删除权限即时回收。这种自动化是手工配置永远无法企及的安全水位。4. 故障排查实战从ssh -v日志到/var/log/secure的完整链路分析当 SSH 密钥登录失败不要急于重装系统或重配密钥。真正的高手是能从一行日志里读出整个故障链路的人。下面是我整理的“SSH 登录失败四步定位法”覆盖了 95% 的线上问题。4.1 第一步客户端ssh -v日志——看清“握手”在哪一步断裂ssh -vverbose 模式是客户端的 X 光机。执行ssh -v -i ~/.ssh/id_centos_prod centos192.168.122.101输出会很长但只需聚焦三个关键阶段阶段1TCP 连接建立看是否有debug1: Connecting to 192.168.122.101 [192.168.122.101] port 22.和debug1: Connection established.。如果没有说明网络不通或端口错误如你改了Port 2222但没在命令里指定。阶段2密钥认证协商搜索debug1: Offering public key:。如果看到这一行说明客户端成功加载了你的私钥并尝试发送公钥给服务器。如果没看到检查-i路径是否正确或私钥权限是否为600。阶段3服务器拒绝认证最关键的线索在这里。如果看到debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Next authentication method: publickey debug1: Trying private key: /path/to/private/key debug1: Authentications that can continue: password debug1: Next authentication method: password这说明服务器收到了你的公钥但拒绝了它于是降级到密码认证。此时问题 100% 在服务器端需立即查看/var/log/secure。提示ssh -vvv三个 v会输出更详细日志但信息过载。ssh -v足够定位 90% 问题是高效排查的黄金标准。4.2 第二步服务器/var/log/secure日志——sshd的“黑匣子”CentOS 的 SSH 服务日志全部记录在/var/log/secure。用sudo tail -f /var/log/secure实时监控然后在另一台机器上发起 SSH 连接观察日志变化。典型失败日志及对应原因日志片段故障原因解决方案Authentication refused: bad ownership or modes~/.ssh或authorized_keys权限错误chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keysUser centos from 192.168.122.1 not allowed because not listed in AllowUsersAllowUsers白名单未包含该用户编辑/etc/ssh/sshd_config添加用户名重启sshdConnection closed by authenticating user centos port 54321 [preauth]MaxAuthTries超限或LoginGraceTime超时检查sshd_config中相关参数或等待 30 秒后重试Failed password for root from 192.168.122.1 port 54322 ssh2密码认证被尝试但PasswordAuthentication no已生效确认客户端是否用了-i指定密钥或密钥路径是否正确注意/var/log/secure日志量很大用grep精准过滤sudo grep sshd /var/log/secure | grep centos只看该用户的记录。4.3 第三步sshd -t配置语法检查——避免“改配置改崩服务器”sshd -t是 OpenSSH 的配置文件语法检查器。在修改/etc/ssh/sshd_config后必须执行sudo sshd -t如果输出Syntax OK说明配置无语法错误可以安全重启如果报错如line 22: Bad configuration option: PermitRootLogins注意Logins多了个 s则必须修正后再重启。sshd -t是防止systemctl restart sshd后服务启动失败、SSH 连接永久中断的保险丝。4.4 第四步SELinux 上下文检查——被忽视的“隐形杀手”SELinux 有时会默默阻止sshd读取authorized_keys文件即使权限600正确。检查方法# 查看 authorized_keys 的 SELinux 上下文 ls -Z ~/.ssh/authorized_keys # 正确输出应为unconfined_u:object_r:ssh_home_t:s0 authorized_keys # 如果是 system_u:object_r:admin_home_t:s0则执行 restorecon -v ~/.ssh/authorized_keysrestorecon命令会将文件恢复为默认的 SELinux 上下文。这是很多高级用户都忽略的细节却常常是“明明权限都对就是登不上”的终极答案。4.5 常见问题速查表一句话定位三步解决问题现象最可能原因快速验证命令三步解决法Permission denied (publickey)PasswordAuthentication no但客户端未指定密钥ssh -i ~/.ssh/id_xxx userhost1. 确认-i参数2.ssh-add -l看密钥是否加载3.ssh -v看是否Offering public keyConnection refusedsshd服务未运行或防火墙拦截sudo systemctl status sshdsudo firewall-cmd --list-all