香港服务器SSH密钥免密登录怎么配置？从生成密钥到禁用密码登录

在 Ubuntu Server 22.04/24.04 LTS 香港服务器上，可以使用 OpenSSH 的 Ed25519 公钥认证实现免密码登录，再关闭 SSH 的密码认证和键盘交互认证。完整流程是：确认服务器环境、在管理端生成密钥、把公钥写入服务器账号的 authorized_keys、从新终端验证密钥登录，最后通过 SSH 配置禁用密码登录。

这里的“免密”指服务器不再要求输入账号密码；如果私钥本身设置了保护口令，首次使用私钥时仍可能需要输入私钥口令，或者通过 ssh-agent 缓存。禁用 PasswordAuthentication 可以关闭 SSH 密码暴力破解入口，但不能替代私钥保护、账号权限控制和系统更新。

适用环境与上线目标

本文以以下环境为主进行配置：

香港服务器的地域不会改变 OpenSSH 的认证配置。只要服务器可以正常建立 SSH 连接，密钥生成、上传、验证和禁用密码的步骤与其他 Ubuntu 服务器一致。

开始前必须具备的条件

执行配置前，至少确认以下事项：

• 当前仍能通过 SSH 登录服务器，并且当前账号具有 sudo 权限。
• 可以打开第二个终端窗口，用于验证新密钥登录。
• 已知服务器公网 IP 或解析到服务器的域名。
• 服务器没有依赖 SSH 的键盘交互式多因素认证。本文会关闭 KbdInteractiveAuthentication，如果现有环境依赖此机制，应先调整认证策略。
• 不要关闭当前 SSH 会话，直到新终端验证成功。
• 如果服务器由自动化脚本、监控或发布系统连接，需要先为这些连接准备独立公钥，否则禁用密码后可能导致自动化任务中断。

如果还没有普通管理账号，可以在服务器当前会话中创建一个。以下命令适用于 Ubuntu，创建过程会提示设置账号信息：

sudo adduser deployadmin
sudo usermod -aG sudo deployadmin

如果 deployadmin 已经存在，不要重复执行创建命令，只需确认它属于 sudo 组：

id deployadmin
getent group sudo

示例输出中应能看到 deployadmin 的 UID、主组以及 sudo 组成员关系。本文后续以 deployadmin 作为登录账号；如果实际账号不同，请将命令中的账号替换为实际用户名。

一、确认服务器上的 SSH 环境

先在香港服务器当前 SSH 会话中检查系统版本、SSH 服务状态和服务端版本。

cat /etc/os-release
systemctl is-active ssh
command -v sshd
sudo sshd -V 2>&1 | head -n 1

Ubuntu Server 的正常结果通常类似：

active
/usr/sbin/sshd
OpenSSH_8.xp1 Ubuntu-...

版本号因系统补丁不同可能存在差异，不需要与示例完全一致。重点是：

• systemctl is-active ssh 返回 active；
• sshd 命令存在；
• 当前 SSH 会话没有异常断开。

如果服务器尚未安装 OpenSSH Server，可以执行以下安装命令：

sudo apt update
sudo apt install -y openssh-server
sudo systemctl enable --now ssh

这组命令会更新 APT 索引并安装 SSH 服务，适用于 Ubuntu 的 APT 环境。安装或启用服务可能触发服务启动动作，但不会替代后续的密钥配置。执行后再次确认：

systemctl is-active ssh
sudo ss -lntp | grep ssh

如果系统不是 Ubuntu Server 22.04/24.04，先不要直接套用服务名和配置路径。应先使用以下命令确认服务实际名称：

systemctl list-unit-files | grep -E '^ssh(d)?\.service'

二、在管理端生成 Ed25519 密钥

密钥应在日常管理使用的电脑上生成，而不是在香港服务器上生成。私钥只保存在管理端，服务器只保存公钥。

Linux 或 macOS

在管理端终端执行：

mkdir -p "$HOME/.ssh"
chmod 700 "$HOME/.ssh"

ssh-keygen -t ed25519 -a 100 \
  -f "$HOME/.ssh/id_ed25519_hk" \
  -C "deployadmin@hk-server"

命令说明：

• -t ed25519：生成 Ed25519 类型密钥；
• -a 100：提高私钥口令的派生计算次数，增加离线破解成本；
• -f：指定私钥和公钥保存路径；
• -C：添加便于识别的注释，不参与认证。

执行时会依次询问私钥保存位置和保护口令。建议为私钥设置口令。生成后会得到两个文件：

~/.ssh/id_ed25519_hk
~/.ssh/id_ed25519_hk.pub

其中：

• id_ed25519_hk 是私钥，不能上传服务器、不能放入网站目录、不能发送给其他人；
• id_ed25519_hk.pub 是公钥，可以写入服务器的 authorized_keys。

检查本地文件权限：

chmod 600 "$HOME/.ssh/id_ed25519_hk"
chmod 644 "$HOME/.ssh/id_ed25519_hk.pub"

ls -l "$HOME/.ssh/id_ed25519_hk" "$HOME/.ssh/id_ed25519_hk.pub"

私钥通常应显示为仅当前用户可读写，例如：

-rw-------  ... id_ed25519_hk
-rw-r--r--  ... id_ed25519_hk.pub

查看公钥指纹可以帮助确认上传的是哪一把公钥：

ssh-keygen -lf "$HOME/.ssh/id_ed25519_hk.pub"

Windows PowerShell

如果管理端是 Windows 10/11，并且系统已启用 OpenSSH Client，可以在 PowerShell 中执行：

New-Item -ItemType Directory -Force "$env:USERPROFILE\.ssh" | Out-Null

ssh-keygen -t ed25519 -a 100 `
  -f "$env:USERPROFILE\.ssh\id_ed25519_hk" `
  -C "deployadmin@hk-server"

生成后的文件位于：

C:\Users\当前用户名\.ssh\id_ed25519_hk
C:\Users\当前用户名\.ssh\id_ed25519_hk.pub

私钥仍然只保留在本地。不要把没有 .pub 后缀的文件复制到服务器。

三、把公钥写入服务器

先在管理端设置本次操作使用的变量。下面的 IP 只是示例，请替换成香港服务器实际公网 IP 或域名：

export SERVER_IP='203.0.113.10'
export SSH_USER='deployadmin'
export KEY="$HOME/.ssh/id_ed25519_hk"

方式一：使用 ssh-copy-id

Linux 和大多数 macOS 环境可以直接执行：

ssh-copy-id -i "${KEY}.pub" "${SSH_USER}@${SERVER_IP}"

命令会要求输入一次服务器账号密码。输入的是服务器当前登录账号的密码，不是私钥口令。成功后通常会提示新增了一把密钥。

然后使用指定私钥进行测试：

ssh -i "$KEY" \
  -o IdentitiesOnly=yes \
  "${SSH_USER}@${SERVER_IP}"

如果成功进入服务器，说明公钥已经被服务端读取。此时仍然不要关闭原来的 SSH 会话。

方式二：没有 ssh-copy-id 时手动追加

如果管理端没有 ssh-copy-id，可以使用管道把公钥内容追加到服务器：

cat "${KEY}.pub" | ssh "${SSH_USER}@${SERVER_IP}" '
  umask 077
  mkdir -p "$HOME/.ssh"
  cat >> "$HOME/.ssh/authorized_keys"
  chmod 700 "$HOME/.ssh"
  chmod 600 "$HOME/.ssh/authorized_keys"
'

这条命令只传输 .pub 公钥文件。authorized_keys 使用追加方式，因此不会覆盖该账号已有的其他公钥。

如果担心重复追加，可以先在管理端查看公钥内容：

cat "${KEY}.pub"

再在服务器上检查是否已经存在同一行：

grep -F "$(cat ~/.ssh/id_ed25519_hk.pub 2>/dev/null)" ~/.ssh/authorized_keys

更实用的服务器端检查方式是查看文件内容和权限：

ls -ld /home/deployadmin
ls -ld /home/deployadmin/.ssh
ls -l /home/deployadmin/.ssh/authorized_keys

Ubuntu 默认用户主目录通常为 /home/deployadmin。如果账号使用了自定义主目录，应先查询真实路径：

getent passwd deployadmin

输出格式中第六列就是用户主目录。

方式三：从 Windows PowerShell 上传公钥

Windows 没有 ssh-copy-id 时，可以在 PowerShell 中执行：

$SERVER_IP = "203.0.113.10"
$SSH_USER = "deployadmin"
$PUBKEY = "$env:USERPROFILE\.ssh\id_ed25519_hk.pub"

Get-Content $PUBKEY | ssh "$SSH_USER@$SERVER_IP" `
  "umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys; chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys"

如果使用的是当前 Windows 用户默认的 SSH 私钥路径，也可以通过 SSH 配置文件统一指定，后文会给出配置示例。

四、在禁用密码前完成一次强制密钥测试

在关闭服务器密码认证之前，必须验证以下条件：

1. 指定的私钥能够登录；
2. 登录使用的是目标账号；
3. 客户端没有偷偷使用其他密钥；
4. 在客户端明确关闭密码认证后仍然可以登录。

先执行普通测试：

ssh -i "$KEY" \
  -o IdentitiesOnly=yes \
  "${SSH_USER}@${SERVER_IP}" \
  'printf "key login ok\n"; id; hostname'

期望看到类似结果：

key login ok
uid=1001(deployadmin) gid=1001(deployadmin) groups=1001(deployadmin),27(sudo)
hk-server

如果私钥设置了保护口令，此时可能会提示输入私钥口令。这不代表服务器仍然使用密码登录，而是本地 SSH 客户端在解锁私钥。

接下来执行更严格的测试。此命令会在客户端禁止密码和键盘交互认证：

ssh -i "$KEY" \
  -o IdentitiesOnly=yes \
  -o BatchMode=yes \
  -o PasswordAuthentication=no \
  -o KbdInteractiveAuthentication=no \
  "${SSH_USER}@${SERVER_IP}" \
  'printf "public key authentication passed\n"'

期望输出：

public key authentication passed

如果私钥有口令且没有加入 ssh-agent，BatchMode=yes 可能因为无法交互输入私钥口令而失败。可以先手动解锁私钥：

ssh-add "$KEY"

如果本机尚未启动 SSH Agent，可以执行：

eval "$(ssh-agent -s)"
ssh-add "$KEY"

然后重复严格测试。ssh-agent 会在当前会话中暂存解锁后的私钥，具体缓存时间由管理端环境决定。不要在不受信任的多人共用电脑上长期保存私钥。

通过 SSH 配置文件简化登录

确认密钥可以工作后，可以在管理端创建或编辑 ~/.ssh/config：

Host hk-server
    HostName 203.0.113.10
    User deployadmin
    IdentityFile ~/.ssh/id_ed25519_hk
    IdentitiesOnly yes

设置配置文件权限：

chmod 600 "$HOME/.ssh/config"

以后可以使用别名连接：

ssh hk-server

不要在配置中使用 StrictHostKeyChecking=no 来跳过主机指纹确认。首次连接时应核对服务器主机指纹，避免把密钥发送给错误的主机。

五、备份 SSH 配置并关闭密码认证

确认密钥登录成功后，回到服务器当前 SSH 会话，先备份主配置文件：

sudo cp -a /etc/ssh/sshd_config \
  "/etc/ssh/sshd_config.bak.$(date +%Y%m%d-%H%M%S)"

同时确认配置目录存在：

sudo install -d -m 755 /etc/ssh/sshd_config.d

Ubuntu 通常会通过 /etc/ssh/sshd_config 引入 /etc/ssh/sshd_config.d/ 下的配置文件。为了避免直接改动系统主配置，可以创建一个单独的策略文件：

sudo tee /etc/ssh/sshd_config.d/00-key-only.conf >/dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
AuthenticationMethods publickey
PermitEmptyPasswords no
PermitRootLogin no
EOF

每项配置的作用如下：

本文以普通 sudo 账号执行管理操作，因此将 PermitRootLogin 设置为 no。如果现有自动化任务必须使用 root 公钥登录，可以将这一行改为：

PermitRootLogin prohibit-password

这表示 root 仍可使用公钥登录，但不允许使用 root 密码登录。修改前必须确认相关自动化连接使用的确实是公钥，否则会造成任务中断。

UsePAM yes 如果已经存在，不建议为了本次配置删除。PAM 还可能负责账号状态、会话初始化和资源限制；本次关闭的是 SSH 的密码及键盘交互认证入口。

检查是否存在重复配置

OpenSSH 配置中，如果同一个参数在不同位置出现，实际生效值可能受配置读取顺序影响。因此，写入策略文件后先检查所有相关配置：

sudo grep -RInE \
  '^[[:space:]]*(PubkeyAuthentication|PasswordAuthentication|KbdInteractiveAuthentication|AuthenticationMethods|PermitEmptyPasswords|PermitRootLogin)[[:space:]]+' \
  /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/null

再检查服务实际解析出的有效值：

sudo sshd -T | grep -E \
  '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|authenticationmethods|permitemptypasswords|permitrootlogin)[[:space:]]+'

目标结果应接近：

pubkeyauthentication yes
passwordauthentication no
kbdinteractiveauthentication no
authenticationmethods publickey
permitemptypasswords no
permitrootlogin no

如果有效值仍然是 passwordauthentication yes，不要继续重载服务。先查看哪一个配置文件提前设置了该参数，再根据实际文件顺序调整。可以使用：

sudo sshd -T | less

如果配置中存在 Match 条件，还应针对实际登录用户和来源地址检查：

sudo sshd -T -C user=deployadmin,addr=客户端公网IP,host=服务器主机名 | \
  grep -E '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|authenticationmethods|permitrootlogin)[[:space:]]+'

将 客户端公网IP 和 服务器主机名 替换成真实值。带 Match 的配置可能导致全局检查结果与某个用户实际得到的结果不同。

六、检查语法后重载 SSH 服务

修改配置后，先做语法检查。此命令不会重启服务，也不会改变当前认证策略：

sudo sshd -t

没有任何输出通常表示语法检查通过。如果出现错误，先不要执行 reload，根据报错的文件名和行号修正配置。

语法通过后，确认当前会话仍然存在，并打开另一个终端窗口。然后重载 SSH 服务：

sudo systemctl reload ssh
sudo systemctl is-active ssh

期望结果：

active

reload 会让 SSH 服务重新读取配置，通常不会主动断开已有会话。与 restart 相比，重载更适合修改认证策略，但仍然不能代替新终端验证。

七、验证密码已关闭、密钥仍然可用

验证新连接使用公钥

从管理端新开一个终端，强制不复用旧 SSH 连接：

ssh -i "$KEY" \
  -o IdentitiesOnly=yes \
  -o ControlMaster=no \
  -o ControlPath=none \
  -o BatchMode=yes \
  -o PasswordAuthentication=no \
  -o KbdInteractiveAuthentication=no \
  "${SSH_USER}@${SERVER_IP}" \
  'printf "new key-only session ok\n"; id; hostname'

期望输出：

new key-only session ok
uid=1001(deployadmin) gid=1001(deployadmin) groups=1001(deployadmin),27(sudo)
hk-server

如果使用了 ~/.ssh/config 中的别名，也可以这样测试：

ssh -o ControlMaster=no -o ControlPath=none \
  -o BatchMode=yes \
  -o PasswordAuthentication=no \
  -o KbdInteractiveAuthentication=no \
  hk-server 'printf "alias login ok\n"'

验证密码登录被拒绝

可以从管理端进行一次明确的密码认证测试：

ssh "${SSH_USER}@${SERVER_IP}" \
  -o PubkeyAuthentication=no \
  -o PreferredAuthentications=password \
  -o PasswordAuthentication=yes \
  -o KbdInteractiveAuthentication=no \
  -o BatchMode=yes

预期结果是连接被拒绝，常见提示类似：

Permission denied (publickey).

不同 OpenSSH 版本可能显示的认证方式列表略有差异。重点是：

• 不再出现密码输入提示；
• 密码认证不能成功；
• 使用指定私钥的连接仍然成功。

这次失败登录会写入认证日志，属于预期验证行为。不要在短时间内反复大量测试，以免触发服务器已有的登录防护策略。

查看服务端认证日志

Ubuntu 通常可以通过 systemd 日志查看 SSH 认证记录：

sudo journalctl -u ssh --since "10 minutes ago" --no-pager

也可以查看最近几十条：

sudo journalctl -u ssh -n 50 --no-pager

部分系统还会将认证记录写入 /var/log/auth.log：

sudo tail -n 50 /var/log/auth.log

成功的公钥登录通常能够看到用户、来源地址和公钥认证相关记录。密码测试失败时，日志中可能出现认证失败、密码认证被拒绝或用户未授权等信息。

检查服务器上的密钥文件权限

SSH 的 StrictModes 机制会检查用户主目录和密钥文件权限。以 deployadmin 为例：

sudo namei -l /home/deployadmin/.ssh/authorized_keys
sudo stat -c '%A %U:%G %n' \
  /home/deployadmin \
  /home/deployadmin/.ssh \
  /home/deployadmin/.ssh/authorized_keys

常见的安全权限状态如下：

drwx------ deployadmin deployadmin /home/deployadmin/.ssh
-rw------- deployadmin deployadmin /home/deployadmin/.ssh/authorized_keys

如果文件归属或权限不正确，可以在服务器上修正：

sudo chown -R deployadmin:deployadmin /home/deployadmin/.ssh
sudo chmod 700 /home/deployadmin/.ssh
sudo chmod 600 /home/deployadmin/.ssh/authorized_keys

如果用户主目录被组用户或其他用户写入，也可能导致 SSH 拒绝读取密钥。可以检查并收紧主目录权限：

sudo chmod go-w /home/deployadmin

该命令会取消主目录对组用户和其他用户的写权限，执行前应确认没有依赖该写权限的业务程序。

常见失败情况与处理方法

1. 仍然提示输入服务器密码

先确认客户端是否使用了正确的私钥：

ssh -vvv -i "$KEY" \
  -o IdentitiesOnly=yes \
  "${SSH_USER}@${SERVER_IP}"

调试输出中应能看到类似信息：

Offering public key: ... id_ed25519_hk
Server accepts key: ...
Authenticated to ...

如果只看到 Offering public key，没有 Server accepts key，通常表示服务端没有接受这把公钥。重点检查：

• 登录用户名是否正确；
• 公钥是否写入了该用户的 authorized_keys；
• 公钥是否被换行、截断或粘贴了额外字符；
• .ssh 和 authorized_keys 权限是否符合要求；
• 服务端是否读取了自定义用户主目录；
• 客户端是否实际使用了另一把密钥。

如果客户端在公钥失败后继续询问密码，说明密码认证还没有关闭，或者本次测试没有通过 -o PasswordAuthentication=no 禁止密码。可以检查有效配置：

sudo sshd -T | grep -E '^(passwordauthentication|kbdinteractiveauthentication|authenticationmethods)[[:space:]]+'

2. 报错 Permission denied (publickey)

这类错误表示 SSH 服务端没有完成公钥认证，常见排查顺序如下：

先在服务器上确认文件存在：

sudo -u deployadmin test -r /home/deployadmin/.ssh/authorized_keys
echo $?

返回 0 表示文件可读。然后检查文件内容是否包含目标公钥：

sudo grep -n 'ssh-ed25519' /home/deployadmin/.ssh/authorized_keys

如果使用的不是 Ed25519，也可以直接查看文件中是否存在对应公钥注释。不要在公开工单或聊天中粘贴私钥内容。

再检查 SSH 服务日志：

sudo journalctl -u ssh -n 100 --no-pager

如果日志提示权限过宽，重新执行权限修正命令。如果提示用户不存在或主目录路径错误，应核对：

getent passwd deployadmin

3. sshd -t 语法检查失败

如果执行：

sudo sshd -t

返回配置错误，当前运行中的 SSH 服务通常仍使用旧配置，因为新文件尚未成功重载。此时不要执行 systemctl reload ssh。

检查新建的策略文件：

sudo sed -n '1,120p' /etc/ssh/sshd_config.d/00-key-only.conf

如果需要暂时撤销本次新增文件，可以先改名保留现场：

sudo mv \
  /etc/ssh/sshd_config.d/00-key-only.conf \
  /etc/ssh/sshd_config.d/00-key-only.conf.disabled

然后再次检查：

sudo sshd -t

如果语法通过，并且需要恢复原有运行策略，可以执行：

sudo systemctl reload ssh

4. 重载后新会话全部无法登录

不要立即关闭仍然可用的旧会话。先在旧会话中确认：

sudo sshd -t
sudo sshd -T | grep -E \
  '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|authenticationmethods|permitrootlogin)[[:space:]]+'

如果发现 authorized_keys 路径、用户权限或配置值错误，可以先禁用新增策略文件：

sudo mv \
  /etc/ssh/sshd_config.d/00-key-only.conf \
  /etc/ssh/sshd_config.d/00-key-only.conf.disabled

sudo sshd -t
sudo systemctl reload ssh

如果无法通过 SSH 建立任何会话，应使用服务器管理面板提供的远程控制台或带外终端进行回滚。不要反复猜测配置并重启服务，否则可能增加排查难度。

5. 使用了 SSH 多因素认证

如果服务器原本使用基于 PAM 的键盘交互认证，配置：

KbdInteractiveAuthentication no
AuthenticationMethods publickey

可能会使现有多因素认证流程失效。此时不要直接套用本文的完整策略。应先确认现有认证方式，再决定是否保留键盘交互认证。无论如何，都需要确保“密码作为单独认证方式”被关闭，并在新终端验证最终的认证链路。

6. root 登录被拒绝

如果配置了：

PermitRootLogin no

root 不能再通过 SSH 直接登录，这是预期结果。管理操作应切换到 deployadmin 后使用：

sudo -i

如果确实存在必须使用 root 公钥的自动化任务，应将配置调整为：

PermitRootLogin prohibit-password

然后执行语法检查、重载和新连接验证。不要为了恢复方便把 PermitRootLogin yes 与密码认证一起重新打开。

回滚方案

回滚前提是保留当前 SSH 会话，或者可以使用服务器控制台。回滚只处理本次新增的密钥策略文件，不会删除用户的公钥和账号数据。

仅回滚新增策略文件

如果问题来自 /etc/ssh/sshd_config.d/00-key-only.conf，执行：

sudo mv \
  /etc/ssh/sshd_config.d/00-key-only.conf \
  /etc/ssh/sshd_config.d/00-key-only.conf.disabled

sudo sshd -t
sudo systemctl reload ssh
sudo systemctl is-active ssh

确认服务为 active 后，再从管理端测试原有登录方式。回滚后，系统会恢复其他配置文件中原本的认证策略。

恢复主配置备份

如果还修改过 /etc/ssh/sshd_config，先列出备份文件：

sudo ls -lt /etc/ssh/sshd_config.bak.*

确认备份时间和内容后，使用实际文件名恢复。例如：

sudo cp -a \
  /etc/ssh/sshd_config.bak.20250101-120000 \
  /etc/ssh/sshd_config

sudo sshd -t
sudo systemctl reload ssh

恢复主配置不会自动删除新增的 00-key-only.conf。如果该文件仍然存在，应根据回滚目标一并改名：

sudo mv \
  /etc/ssh/sshd_config.d/00-key-only.conf \
  /etc/ssh/sshd_config.d/00-key-only.conf.disabled

如果已经无法通过 SSH 登录，应在服务器控制台中完成上述操作。回滚后要重新检查：

sudo sshd -T | grep -E \
  '^(pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|authenticationmethods|permitrootlogin)[[:space:]]+'

上线验收清单

完成配置后，可以按以下项目逐项验收：

• [ ] Ubuntu Server 22.04/24.04 的 SSH 服务状态为 active。
• [ ] 管理端私钥仅保存在本地，服务器没有保存私钥文件。
• [ ] 服务器目标账号的 ~/.ssh 权限为 700。
• [ ] authorized_keys 权限为 600，归属目标账号。
• [ ] 使用 -i 指定的 Ed25519 私钥可以建立新 SSH 会话。
• [ ] 使用 BatchMode=yes、PasswordAuthentication=no 的测试可以成功。
• [ ] 关闭公钥、强制使用密码的测试被拒绝。
• [ ] sshd -t 语法检查没有输出错误。
• [ ] sshd -T 显示 pubkeyauthentication yes。
• [ ] sshd -T 显示 passwordauthentication no。
• [ ] sshd -T 显示 kbdinteractiveauthentication no。
• [ ] AuthenticationMethods 为 publickey，或与实际多因素认证策略一致。
• [ ] 已确认 PermitRootLogin 的值不会影响现有自动化任务。
• [ ] 已保留主配置备份和回滚文件。
• [ ] 已从新终端验证成功后，才关闭旧 SSH 会话。

完成这些检查后，香港服务器的 SSH 登录就会以公钥为主要认证方式，并拒绝常规密码登录。后续如果更换电脑、轮换密钥或移除旧账号，应先添加并验证新公钥，再删除旧公钥，避免误删唯一可用的管理入口。