VMware ESXi 使用 SSH 密钥登录的注意事项：公钥路径、FIPS 与 RSA

VMware ESXi 支持使用 SSH 公钥登录，但它在公钥保存路径、系统持久化和算法策略方面都与普通 Linux 有明显差异。直接照搬 ~/.ssh/authorized_keys 或默认使用 Ed25519，可能导致公钥已经写入却仍然无法登录。

本文先给出适用于 ESXi 的通用配置方法，再用一次 Termark 自动化连接失败的实际排查过程说明这些差异。示例中的主机地址、公钥、客户端路径和资产 ID 都需要按实际环境替换。

ESXi SSH 密钥登录的关键差异

公钥不一定放在 ~/.ssh

应先读取 ESXi 当前生效的 AuthorizedKeysFile，不要假设它与普通 Linux 相同：

grep -inE \
  'passwordauthentication|challengeresponseauthentication|usepam|authorizedkeysfile' \
  /etc/ssh/sshd_config

本次 ESXi 8.0 Update 3 的结果为：

ChallengeResponseAuthentication yes
UsePAM yes
PasswordAuthentication no
AuthorizedKeysFile /etc/ssh/keys-%u/authorized_keys

%u 会替换为登录用户名，因此 root 用户的公钥文件是：

/etc/ssh/keys-root/authorized_keys

本次环境中 root 的家目录是 /，使用 ~/.ssh 会展开为 //.ssh，不能作为 ESXi root 的公钥目录。

密码交互与普通密码认证不是一回事

ChallengeResponseAuthentication yes 和 UsePAM yes 允许交互式客户端通过 keyboard-interactive/PAM 输入密码。PasswordAuthentication no 则表示客户端不能依赖普通 SSH password 认证。

因此，某个终端能够弹出密码提示并成功登录，不代表自动化工具也能提交同一密码。需要无人值守执行命令时，应配置公钥认证，而不是启用普通密码认证或使用 sshpass。

FIPS 环境需要检查密钥算法

不要默认认为 Ed25519 一定可用。ESXi 启用 FIPS 后，实际允许的公钥算法可能受到限制。本次环境明确拒绝了 Ed25519：

FIPS mode initialized
userauth_pubkey: signature algorithm ssh-ed25519 not in PubkeyAcceptedAlgorithms [preauth]

这种情况下应选择符合当前策略的 RSA 密钥，而不是修改 ESXi 的允许算法列表来绕过 FIPS。

配置前检查

先确认 ESXi 版本、SSH 配置和认证日志位置：

vmware -vl

grep -inE \
  'passwordauthentication|challengeresponseauthentication|usepam|authorizedkeysfile' \
  /etc/ssh/sshd_config

tail -n 30 /var/log/auth.log

本文实测环境为 VMware ESXi 8.0 Update 3 build 25067014，并已启用 FIPS。不同 ESXi 版本和安全基线可能使用不同算法策略，最终应以本机 sshd_config 和 /var/log/auth.log 为准。

通用配置步骤

1. 在管理端生成专用 RSA 密钥

在负责管理 ESXi 的电脑上生成一把独立的 RSA 4096 密钥：

ssh-keygen -t rsa -b 4096 \
  -f ~/.ssh/esxi_admin_rsa \
  -C "esxi-admin"

查看公钥：

cat ~/.ssh/esxi_admin_rsa.pub

生成的两个文件作用不同：

• ~/.ssh/esxi_admin_rsa 是私钥，只能保存在受控管理端或凭证库中。
• ~/.ssh/esxi_admin_rsa.pub 是公钥，需要写入 ESXi。

如果管理端要求无人值守登录，应评估私钥口令和凭证库托管方案，不要将私钥或口令直接写进脚本。

2. 将公钥写入 ESXi

先通过控制台或仍然有效的交互式 SSH 会话登录 ESXi。将下面的占位内容替换为完整的 RSA 公钥，并保持为一行：

PUBKEY='ssh-rsa AAAA...替换为完整公钥... esxi-admin'

mkdir -p /etc/ssh/keys-root
chmod 700 /etc/ssh/keys-root
touch /etc/ssh/keys-root/authorized_keys

grep -qxF "$PUBKEY" /etc/ssh/keys-root/authorized_keys || \
  printf '%s\n' "$PUBKEY" >> /etc/ssh/keys-root/authorized_keys

chmod 600 /etc/ssh/keys-root/authorized_keys
chown root:root /etc/ssh/keys-root/authorized_keys

grep -qxF 用于避免重复写入相同公钥。为其他允许 SSH 登录的用户配置时，应根据 AuthorizedKeysFile 中的 %u 替换目录名，不能机械照搬 keys-root。

3. 持久化配置

将当前 ESXi 配置同步到持久化存储：

/sbin/auto-backup.sh

命令执行成功后，还应在维护窗口重启 ESXi，再验证公钥登录。当前会话能够登录，只能证明运行时配置有效，不能替代跨重启验证。

4. 在 SSH 客户端中使用私钥

OpenSSH 客户端可以使用以下模板：

ssh -i ~/.ssh/esxi_admin_rsa root@<ESXI_IP>

使用 Termark、堡垒机或其他 SSH 管理工具时，导入同一把私钥，并确保资产使用的是“密钥凭证”，而不是旧的密码凭证或不受 FIPS 支持的密钥。

验证方法

不要只以“出现命令提示符”作为唯一证据。客户端应建立一个全新的连接，并从 ESXi 服务端日志确认认证方式。

在客户端执行：

ssh -i ~/.ssh/esxi_admin_rsa \
  root@<ESXI_IP> \
  "hostname; vmware -vl; echo SSH_KEY_OK"

在 ESXi 上检查最近的认证记录：

tail -n 50 /var/log/auth.log | \
  grep -iE 'Accepted publickey|Connection from|session opened'

成功结果应包含：

Accepted publickey for root from <CLIENT_IP> port <PORT> ssh2: RSA SHA256:<FINGERPRINT>
pam_unix(sshd:session): session opened for user root by (uid=0)

出现 Accepted publickey 才能证明服务端接受了公钥，而不是回退到 keyboard-interactive 密码登录。

实际案例：Termark 自动化连接 ESXi 失败

本次操作最初是为了让 Termark CLI 对 ESXi 执行一次性命令。Termark 桌面终端可以交互输入密码，但 CLI 返回：

ssh: handshake failed: SSH keyboard-interactive answers required

第一个问题：通用公钥命令使用了错误路径

工具生成的通用 Linux 命令准备写入：

~/.ssh/authorized_keys

ESXi 将它展开为 //.ssh/authorized_keys，执行时返回：

chmod: //.ssh: Operation not permitted

根据本机 AuthorizedKeysFile /etc/ssh/keys-%u/authorized_keys，将路径改为 /etc/ssh/keys-root/authorized_keys 后，公钥才能被 sshd 正确读取。

第二个问题：Ed25519 被 FIPS 拒绝

修正路径并设置 0600 权限后，Ed25519 仍然无法登录。/var/log/auth.log 明确记录：

userauth_pubkey: signature algorithm ssh-ed25519 not in PubkeyAcceptedAlgorithms [preauth]

改用 RSA 4096 密钥、在 Termark 中绑定对应的 RSA 私钥凭证后，CLI 新连接成功：

termark exec <ESXI_ASSET_ID> \
  "hostname; vmware -vl; echo TERMARK_RSA_OK"

实测返回：

ESXi-01.local
VMware ESXi 8.0.3 build-25067014
VMware ESXi 8.0 Update 3
TERMARK_RSA_OK

服务端同时记录：

Accepted publickey for root from <CLIENT_IP> port <PORT> ssh2: RSA SHA256:<FINGERPRINT>

Termark 在这里是验证 ESXi 公钥路径和 FIPS 算法差异的实际案例，并不是本文方法的使用前提。相同配置原则同样适用于 OpenSSH、堡垒机和其他支持 SSH 私钥的管理工具。

常见故障对照

安全与运维建议

• 为不同管理员、管理工具或自动化用途创建独立密钥，避免多台设备共用同一把 root 私钥。
• 私钥文件权限应保持为 0600，并放入受控的终端或凭证库。
• 不要为自动化方便而启用普通密码认证，也不要把密码写入 sshpass、脚本或命令历史。
• 不要为了使用 Ed25519 而放宽 FIPS 算法策略，应选择符合当前安全基线的密钥算法。
• 新密钥验证成功后，再清理无效或不再使用的旧公钥，避免误删唯一可用的登录方式。
• 执行 /sbin/auto-backup.sh 后仍需重启验证，并在 ESXi 升级或安全基线变更后再次检查。
• SSH 服务不使用时应关闭；确需长期启用时，应限制管理网络来源并保留操作审计。

结论

在 ESXi 上配置 SSH 密钥登录，最重要的不是把公钥简单复制到 ~/.ssh，而是先确认本机的 AuthorizedKeysFile、算法策略和持久化方式。

对本文实测的 ESXi 8.0 Update 3 FIPS 环境，可靠方案是使用 RSA 4096 密钥，将公钥写入 /etc/ssh/keys-root/authorized_keys，设置正确权限，执行 /sbin/auto-backup.sh，再通过全新客户端连接和 Accepted publickey 日志完成双向验证。Termark 的故障只是帮助暴露这些 ESXi 特性的实际案例。