什么情况下会撞上它

典型场景：在远程主机做临时操作，本地生成临时 SSH 密钥，公钥追加到远端 ~/.ssh/authorized_keys，私钥放本地临时目录。操作中途远端内存耗尽严重换页，SSH 能连上但命令不返回或超时。此时需收尾：删临时密钥、清 /tmp 安装包、终止残留进程，但收尾本身也要走 SSH。

判断依据：远端命令连续两三次超时、且 ssh -v 显示认证通过但卡在执行阶段，就按“远端不可用”处理，先做本地清理，远端留待恢复后补。

为什么会这样

SSH 认证和执行是两个阶段。认证只做密钥交换和签名校验，开销很小；执行要 fork 进程、加载 shell、读磁盘，内存不足时会被拖到几乎无响应。所以“能连上”不代表“能执行命令”。sed -i、pkill 都需要远端真正跑起来，反复重试只会加重负载。

另一个易忽略点：私钥一旦出现在日志、终端回显、聊天窗口或临时文件里，就应视为已泄露，无论是否“损坏”。清理目标是确认没有副本留存，而非让它不可用。

怎么做

第一步：先做本地清理

远端不可用时，本地清理不依赖网络，优先做。

rm -rf /path/to/app/.tmp-ssh
grep -rl "BEGIN OPENSSH PRIVATE KEY" /path/to/app /tmp 2>/dev/null

按内容特征搜索，不要只按文件名。命中后逐个确认：早于本次操作时间的，通常是源码里的测试夹具，可排除。

第二步：确认私钥已不可用

本地私钥删除后，即使远端 authorized_keys 还有对应公钥也无法登录。检查本地是否还有同名或同内容文件即可。

第三步：远端恢复后补做清理

等内存压力缓解，或通过控制台重启、进入救援模式后执行：

sed -i '/temp-install-key/d' ~/.ssh/authorized_keys
grep -c temp-install-key ~/.ssh/authorized_keys   # 期望 0
sudo pkill -9 -f "npm i -g"
rm -f /tmp/node-*.tar.*

添加公钥时就加可识别注释（ssh-keygen -C temp-install-key），是让这一步可靠的前提；没有注释只能比对指纹，成本高得多。

第四步：处理装了一半的软件

command -v your-app
ls /usr/local/lib/node_modules

没装上就不用管；装上了但不想要，按安装方式反向删除：包管理器装的用包管理器卸，手工解压到 /usr/local 的按文件清单删。

怎么确认成了

  • 本地：grep 无命中，或命中项经核对为无关文件。
  • 远端：grep -c 返回 0；ps aux | grep 无残留安装进程；/tmp 下无安装包。
  • 登录面：用原临时密钥连接应被拒绝。

哪步失败就停在哪步：远端超时说明主机未恢复，改用控制台；grep -c 不为 0 说明注释写错或有多处添加，需逐行核对。

边界与代价

这套流程假设你能通过控制台或重启接触主机。纯云主机没有串口时，只能等或提工单。

私钥内容一旦出现在任何持久化位置（日志、剪贴板历史、聊天记录），应轮换相关口令，而不只是删文件；临时密钥应始终带注释、限定有效期，并在操作前就想好清理命令。若该口令在别处也使用，同样建议更换——密钥失效不代表泄露的口令失效。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注