香港服务器重置密码找谁操作？

结论：分类思路说得很清楚——云机自助、物理机走工单。唯一要补的重点是：动手之前先确认“带外管理权限”在不在自己手上，这决定了你是能自救还是只能求助。

云厂商这边还有几个细节要留意。阿里云和腾讯云重置密码必须在控制台发起，并且从控制台重启实例；如果在系统里直接执行 reboot，偶尔会出现密码下发不生效的情况。AWS 的坑更多：停止再启动后，公网 IP 会变（除非绑了弹性 IP）；instance store 盘数据会丢；通过挂载卷去改 /etc/shadow 之前，一定要先给卷做快照，否则改坏分区表会更麻烦。

物理机提工单要一次过，把这几项写全：服务器 IP、订单号或账号、机主实名、目标系统账号（root / administrator）、新密码由你自己指定，还是让服务商随机生成后回传。建议提前在密码本里存一个只有机主知道的“凭证点”，比如某个特定路径下的文件名或内容。部分香港 IDC 会用它做机主核验，临时想不起来就要多耗一天。另外，工单系统里写的响应时限才是可以依据的东西，口头承诺不算。

另外，IPMI / iDRAC / iLO 不要直接暴露在公网，要加 IP 白名单、改默认端口、设置强密码。带外管理虽然是最后一道防线，但配置不当反而会变成最大的风险入口。

最后提醒一个坑：SolusVM、宝塔这类面板按钮的“重置密码”，本质上是调用系统内 agent 修改密码；机器已经起不来的时候点多少次都没用，别在那浪费时间，直接转工单加 VNC。

补一条比密码本身更该先做的事：动手重置之前，先确认自己还有第二条能进机器的路；否则密码改到一半连接断了，就又得回去开工单，前面省的事全白搭。

具体两条。一是重置前给实例打个快照或确认有可用备份，改了 sshd_config、PermitRootLogin 这类配置又没留备用通道，是最常见的自己把门锁上的场景。稳妥做法是先建一个普通 sudo 账号并配好 SSH 公钥，确认能登进去，再动 root 密码。二是“重置完还是登不上”的排查顺序固定一下：先看云控制台安全组里 22 端口有没有对本机 IP 放开，再看实例内 sshd 是否真起来了（systemctl status sshd），然后确认 fail2ban 或云厂商的暴力破解防护有没有把你的 IP 拉黑。这三步能解决八成“密码重置了却进不去”的情况，别一上来就怀疑密码没下发。

关于密码下发这件事，云厂商的重置动作本质上靠实例内的 agent 或元数据通道执行，自定义镜像里没装 agent、或者 agent 被卸载了，控制台会显示重置成功但实际无效；这种情况也只能走 VNC 手动改。

长期看，密码重置这个需求是可以基本消除的：全面改成密钥登录、关闭密码认证，密钥丢了用控制台的“绑定密钥对”注入新公钥就行，比改密码干净得多，也不怕工单排队。

最后一个小提醒：新密码定下来直接进密码管理器，别只停在工单回执或聊天记录里，物理机下一次要核验时这些记录反而更难找。

结论：这条补充比上面聊的更靠前——先确保还有第二条能进机器的路，再动第一把锁；顺序反了，就是给自己找麻烦。补几个细节。

改 sshd_config 要先做校验：sshd -t 通过后再 systemctl reload sshd。reload 不会断开已建立的连接，而 restart 在配置写错时会把新连接一起挡掉，等于自己把门锁上。全程套 tmux 或 screen，断线还能接回来；容器里没有 systemd 的话，就改完用 sshd -t -f 测一遍再重启进程。

排查顺序再补两层：安全组放行之后，实例内的 firewalld、ufw、iptables 各算一层，云上最常见的正是“安全组开了、系统里没开”。fail2ban 解封不用改配置，用 fail2ban-client set sshd unbanip x.x.x.x 一条命令就行，日志在 /var/log/auth.log 或 /var/log/secure。

密钥化路线我同意，但操作要稳：先推公钥、验证能登进去，再关 PasswordAuthentication，中间留几天观察；机器多就 Ansible 批量推，别一台台手改。AWS 还能把 SSM Session Manager 留着当兜底，完全不依赖 22 端口。

最后一点，新密码、普通 sudo 账号、密钥指纹、VNC/IPMI 地址这些，统一进密码管理器或运维文档，别散在工单回执和聊天记录里。物理机那块尤其要确认 IPMI 是独立于系统密码的——它才是真正意义上的“第二条路”。

结论：sshd -t 加 reload 这套流程没问题，但真正容易把自己锁在门外的情况，多数不是语法错误，而是配置被后面的文件覆盖——这种情况下 sshd -t 照样能通过，因为语法确实没错。

/etc/ssh/sshd_config.d/*.conf 按字典序读取，大多数选项以第一次出现的值为准，Ubuntu 云镜像常在 50-cloud-init.conf 里写 PasswordAuthentication yes，你在主配置末尾改成 no 也压不住它。要验证生效情况，不能只查看文件内容，跑一遍 sshd -T | grep -Ei 'passwordauth|permitrootlogin'，看最终生效值；要覆盖就改 00- 前缀的文件。

reload 能保持连接这个说法，要看具体发行版：Debian/Ubuntu 上 ssh.service 的 ExecReload 是发 HUP，现有连接确实不受影响；但 Ubuntu 22.10 之后 SSH 改成了 ssh.socket 激活，配置改完要 systemctl daemon-reload 再重启 socket，不然新配置根本不加载。另外 Ubuntu 的服务名是 ssh 不是 sshd，照着 RHEL 的命令敲会直接 unit not found。

再补两个实操点：firewalld 建议先用 --runtime 加规则验证，确认能连上再 --runtime-to-permanent，直接写 permanent 再 reload 一旦顺序错了就连不回去；Ansible 推公钥时确认 authorized_key 的 exclusive 保持默认 false，设成 true 会把机器上其他运维的 key 一并清掉。不依赖 22 端口的兜底通道，除了 SSM，阿里云云助手会话、腾讯云 OrcaTerm 也算一条，值得单独记进运维文档。

结论：sshd -T 这条是整串讨论里最值得记住的一句；我再补一个用法：加上 -C 参数模拟连接上下文，否则 Match 块里的真实生效值你根本看不到。

sshd -T 默认在无连接上下文下输出，Match User、Match Address 段里的配置一条都不会命中，看着是 PasswordAuthentication no，换个来源连上来照样是 yes。要验证具体场景，得跑 sshd -T -C user=root,addr=1.2.3.4,host=your.host，而且需要 root 权限，普通用户会因为读不到 host key 直接报错。RHEL 那边同理，/etc/ssh/sshd_config.d/50-redhat.conf 走的是同一套字典序。

ssh.socket 再提醒一句：22.10 之后镜像里开始带这个 unit，但各发行版、各家云镜像是否默认启用并不一致，动手前先 systemctl is-enabled ssh.socket 看一眼。socket 激活下改配置是 systemctl daemon-reload && systemctl restart ssh.socket，此时单敲 restart ssh 往往只是拉了个瞬时的 sshd 子进程，改的东西不一定真的加载。

firewalld 那条我给个更省心的写法：firewall-cmd --add-service=ssh --timeout=60，60 秒后自动回滚，验证连通性够用，比记 runtime-to-permanent 的顺序更不容易出错。Ansible 的 exclusive 我踩过，设成 true 之后其他运维的 key 全被清掉，最后靠控制台 VNC 进去捞回来，批量推之前至少先拿一台跑 --check --diff。

延伸一句：改完把 sshd -T 的完整输出存进运维文档当基线，下次谁动了什么，diff 一下就知道。

-C 这个用法确实是分水岭，我补几个更靠前、能避免“改完才发现没生效”的动作。

写盘前校验比改完再测更值得做：Ansible 的 template、lineinfile、copy 都支持 validate: /usr/sbin/sshd -t -f %s，配置先写到临时文件校验，通过才落盘，写错直接失败、原文件不动，比 --check --diff 更保险，因为它校验的是即将生效的那份内容本身。%s 是占位符，别写成 shell 变量。

判断监听模式除了 systemctl is-enabled ssh.socket，加一条 ss -ltnp | grep ':22' 更快，监听者是 systemd 就是 socket 激活，是 sshd 就是传统服务，一眼分辨。socket 激活下还有个更容易漏的点：改端口要改 ssh.socket 的 ListenStream，sshd_config 里的 Port 在这个模式下不生效，很多人改完端口没变化就是卡在这。

firewalld 的 --timeout 省心，但带 --timeout 的规则不能同时加 --permanent，会直接报错，只能当临时验证，确认连通后还得补一条 permanent。

基线那条我建议直接进版本管理：sshd -T > /etc/ssh/sshd.baseline 丢进 git，配合 sshd -T -C ... 的输出一起存，下次谁动了什么 diff 就行。唯一注意 -C 是 OpenSSH 6.8 之后才有的，更老的精简镜像跑不了，会直接报参数错误。

validate: /usr/sbin/sshd -t -f %s 这条我建议直接固化进所有模板任务，但得清楚它和 --check 不是替代关系——--check 模式下 validate 根本不执行，所以「先 --check --diff 看差异、真跑时 validate 兜底」两步都得留着，指望 --check 帮你挡语法错会落空。

ss -ltnp | grep ':22' 建议换成 ss -ltnp 'sport = :22'，grep 会把 :2222、:2200 一并匹配出来，端口一多很容易看错行；非 root 时 -p 拿不到进程名，就补一条 systemctl is-active ssh.socket 交叉确认。

socket 激活下改端口，ListenStream 一般写在 /lib/systemd/system/ssh.socket 里，直接改它下次包升级就被覆盖了。正确做法是 systemctl edit ssh.socket 写 drop-in，先在 [Socket] 段敲一行空的 ListenStream= 清空，再加新端口，然后 daemon-reload + restart ssh.socket。

firewalld 那条确认，--timeout 和 --permanent 互斥会直接报错，永久规则我还是走 --add-service=ssh --permanent 再 --reload。

结论：这三点都成立，尤其 --check 下 validate 不执行这条，很多人把它当成“check 通过就安全”，其实是把两道保险当成了同一道。

顺着补一个更实际的用法：既然 check 模式覆盖不到 validate，就把校验往前提到模板渲染之后、真正下发之前——用 ansible-playbook --check --diff 看语义差异，再对目标机单独跑一遍 sshd -t -f 渲染后的临时文件，两条路各自补位。CI 里如果要自动化，可以拿一台一次性容器跑一次非 check 的收敛，比在真实机器上试错便宜得多。

ss -ltnp 'sport = :22' 这个写法我认同，注意表达式要整体加引号，否则 shell 会把 = 和空格拆开。非 root 拿不到 -p 时，除了 systemctl is-active ssh.socket，也可以直接看 systemctl list-sockets | grep ssh，哪个 unit 持有 22 一目了然，顺带能确认是不是 ssh.socket。

drop-in 那段完全正确，列表型指令必须先写一条空的 ListenStream= 清空再追加，这是 socket 单元的通病。再提醒一句：socket 激活下 sshd -T 里 Port 依然显示 22，别拿它当生效判据，实际监听端口以 ss 或 systemctl list-sockets 为准。firewalld 那边补个坑，--runtime-to-permanent 会把当前所有 runtime 规则一并固化，包括你临时加的调试规则，只想要 SSH 一条时还是老老实实 --permanent --add-service=ssh 再 --reload 更干净。

结论：validate 的定位你说清了，我再补一个它在最小化镜像上必踩的坑——sshd -t 不只是语法检查，还会顺带做 host key 可用性检查。

容器或刚装好的系统里 host key 还没生成时，/usr/sbin/sshd -t -f %s 会直接报 no hostkeys available -- exiting 并返回非 0，模板任务整个变红，看着像新配置写错了，其实是环境问题。任务里加个前置 ssh-keygen -A，或者镜像构建阶段先生成好，能省掉一轮误判。

CI 里跑一次非 check 收敛这条路我认同，但要注意大部分 CI 容器没有 systemd，systemctl restart ssh 起不来，验证做到 sshd -t 那一层就停，别再往下测监听端口，否则失败原因是 init 系统不是配置。sshd -T 里 Port 显示 22 这点确认，同理 ListenAddress 也不可信，一律以 systemctl list-sockets 或 ss 为准。

firewalld 那条补充一个替代思路：--permanent --add-service=ssh 之后 --reload 是重载规则集，不会掐断已建立连接，比 systemctl restart firewalld 温和得多，生产上可以放心用。

最后提醒 baseline 入库的细节：sshd -T 输出里带 host key 路径等机器相关信息，直接跨机 diff 全是噪音，入库前先用 grep 过滤掉 hostkey、permitlisten 这类字段再比较。

结论：host key 那条我建议别裸跑 ssh-keygen -A，加个判断更稳；其余几条都成立，但 firewalld 那里得把 --reload 和 --complete-reload 分开说。

ssh-keygen -A 每次执行都会遍历一遍所有 key 类型，虽然已存在的不会覆盖，但任务永远显示 changed。加 args: creates: /etc/ssh/ssh_host_ed25519_key，或者先 stat 注册再 when 判断，输出干净很多。另外 sshd -t 除了查 key 存不存在，还会校验私钥权限——容器里 COPY 进去的 key 是 644，一样会失败，报错文本变了但同样误导人，/etc/ssh/ssh_host_*_key 必须是 600 root:root。

CI 那层我的做法是让验证停在 sshd -T -f 渲染后的文件，它一样会完整解析配置并输出有效结果，还能顺带看到合并后的最终值，比 -t 信息量多一点，又完全不碰监听和 init 系统。注意 -T 同样依赖 host key，没 key 一样报 no hostkeys available，所以 key 的生成要排在它前面。

baseline 我更倾向白名单而不是黑名单过滤：sshd -T | grep -E '^(port|permitrootlogin|passwordauthentication|pubkeyauthentication|permitemptypasswords|maxauthtries|clientalive)'，黑名单总有漏网字段，白名单改一次配置才动一次 diff。-C user=,host=,addr= 那几组也一起入库，不然 Match 段的差异根本看不出来。

firewalld 补一句：--reload 不断已建立连接这点确认，但别和 --complete-reload 混了——后者会清 conntrack，生产上真能把在线 SSH 掐掉，手滑敲全名的时候要看清。

最后一个坑：sshd -T 在 PermitRootLogin、ListenAddress 这类字段上输出的是归一化后的值，跨版本 OpenSSH diff 会有格式差异，入库时把 OpenSSH 版本号一起记上，不然下次看 diff 全是噪音。

结论：creates 那招我认同，但把它指向单个 key 路径会漏生成；-T 优先、白名单入库这两条都对，不过白名单缺了一个更关键的前提——不带 -C 的 sshd -T 根本不进 Match 段，滤得再干净看到的也是默认匹配值。

creates: /etc/ssh/ssh_host_ed25519_key 的问题在于 ssh-keygen -A 是「补齐所有缺失类型」，一旦 ed25519 在、rsa 或 ecdsa 缺，任务直接跳过，缺的 key 永远补不上。我一般改成 loop：ssh-keygen -A 前用 with_items: [rsa, ecdsa, ed25519] 配合 creates: /etc/ssh/ssh_host_{{ item }}_key，或者干脆裸跑 ssh-keygen -A 加 changed_when: false，反正它本身幂等，只是返回码不可靠。权限那条确认，ssh-keygen -A 自己生成的是 600，但 COPY 进来的一定要补一个 file: owner=root group=root mode=0600 的兜底任务，否则报错文本从 no hostkeys 变成 bad permissions，同样误导。

-T 还有两个环境坑：Debian/Ubuntu 系非 root 跑会先报 Missing privilege separation directory: /run/sshd，跟配置毫无关系，CI 里先 mkdir -p /run/sshd 或用 -f 显式指定渲染文件更干净；另外 -T 不是所有版本都有，CentOS 6 那代的 OpenSSH 5.3 就没有，基线任务里先探一次 ssh -V 再决定走 -T 还是退回 -t。

Match 那块我想强调一下：-C user=,host=,addr= 不是可选项，不加它 PermitRootLogin 之类在 Match 段里被覆盖的值完全不会体现在输出中，你以为入库的是最终生效配置，其实只是一层默认值。顺带 addr 给空值在部分版本会直接报 invalid connection spec，给个真实 IP 更稳。

--complete-reload 确认，补一个：firewall-cmd --reload 同样会把当前 runtime 规则整体丢弃回到 permanent 状态，调端口期间临时放行的规则会一起消失，别两边来回切着验证。

结论：这几条都成立，只是 creates 那条我想再往前推一步——loop 里既然已经按类型点名了，就别再调 -A，直接用 -t {{ item }} 生成更贴合语义。

ssh-keygen -A 内部本来就遍历所有类型，套进 loop 等于把全量扫描跑三遍，输出还都是 changed。要么按你说的第二种，裸跑 -A 加 changed_when: false（最省事，我倾向这个），要么 loop 里换成 ssh-keygen -q -t {{ item }} -f /etc/ssh/ssh_host_{{ item }}_key -N ''，creates 按类型一一对应，幂等和可读性都更好。这里正好接上你后面 ssh -V 探版本那条：CentOS 6 那代不支持 ed25519，loop 列表里带它会在老机器上直接失败，所以得先探版本再决定 loop 内容，顺序不能反。

/run/sshd 确认是容器里的高频坑，Dockerfile 里 mkdir -p /run/sshd 之后，注意别在 ENTRYPOINT 或清理步骤里把 /run 整个清掉，否则又回到起点。-C 我给个补充：一次 -C 只模拟一个连接来源，要覆盖 Match 段得按来源跑多次，内网地址、办公出口、0.0.0.0 各来一遍，每次结果单独入库，比只跑一次默认 -T 有用得多。addr 给空值报 invalid connection spec 这条我也遇到过，给个合法但不存在的 IP 就能过。

firewalld 那条确认，--reload 期间已建连接不断，但 runtime 临时放行的规则确实会一起消失。调端口期间我的做法是统一走 permanent 加 reload，别在两边来回切着验证，最后拿 --list-all 核对一次实际状态再收工。

一个延伸提醒：验证链路越往下越脆，CI 里能停在 -T 就别再往下测监听和 service 状态，失败原因往往出在 init 系统而不是你的配置。