预算有限的初创企业部署香港AMD服务器，如何配置SSH访问控制

先把目标状态定下来

预算有限的初创企业，判断“香港AMD服务器哪款性价比高？适合初创企业”时，不应只看AMD处理器的核心数或月租价格。对于需要远程维护的业务，能否提供独立公网IPv4、控制台或救援入口、快照能力，以及是否方便限制SSH来源地址，同样决定了实际使用成本。

本次配置的目标是：使用普通管理员账号登录，采用SSH密钥认证，禁止root直接登录和密码登录，只允许指定管理组访问SSH；条件允许时，再将SSH端口限制为办公室或固定运维出口IP。以下步骤以Ubuntu Server 22.04/24.04为例，服务名称通常为ssh，配置路径为/etc/ssh/。

建议的参考配置如下，具体规格应以业务进程、数据库和容器数量为准：

这些数值是部署前的参考范围，不代表某个在售型号的当前价格、库存或官方规格。对于初创企业，宁可选择配置略低但具备控制台和快照能力的方案，也不要为了节省少量费用而选择完全没有恢复入口的服务器。

操作前检查与备份

准备两个登录通道

开始修改SSH前，至少保留以下通道中的两种：

• 当前仍然可用的SSH会话；
• 服务商提供的控制台、KVM或救援入口；
• 第二个已经验证过的管理员密钥。

不要在唯一SSH会话中直接修改配置后立即退出。systemctl reload ssh通常不会中断已经建立的连接，但新连接可能因为配置错误、用户权限错误或防火墙规则而无法建立。

从当前服务器执行基础检查：

sudo -v
cat /etc/os-release
ssh -V
sudo /usr/sbin/sshd -t
systemctl is-active ssh || systemctl is-active sshd
sudo ss -lntp | grep -E ':(22)\s'
printf '当前SSH连接：%s\n' "$SSH_CONNECTION"

如果sshd -t没有任何输出，通常表示当前配置语法通过。如果提示文件不存在、服务未安装或路径不同，应先根据实际系统检查软件包和服务名称，不要直接套用后续命令。

记录当前配置

以下操作只复制配置，不会改变正在运行的SSH服务。备份目录权限设置为仅root可读，便于后续回滚。

BKP="/root/ssh-hardening-backup-$(date +%Y%m%d-%H%M%S)"

sudo install -d -m 700 "$BKP"
sudo cp -a /etc/ssh/sshd_config "$BKP/"
sudo cp -a /etc/ssh/sshd_config.d "$BKP/"

if command -v ufw >/dev/null 2>&1; then
    sudo ufw status numbered | sudo tee "$BKP/ufw-status.txt" >/dev/null || true
fi

printf '备份目录：%s\n' "$BKP"

同时确认当前是否已经存在以下配置。若已有业务账号通过SSH登录，后续启用AllowGroups前必须把这些账号逐一确认，否则可能造成账号无法登录。

sudo grep -RniE '^(PermitRootLogin|PasswordAuthentication|KbdInteractiveAuthentication|PubkeyAuthentication|AllowUsers|AllowGroups|AuthenticationMethods|AllowTcpForwarding|X11Forwarding)' \
    /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/null || true

分步配置SSH访问控制

1. 创建独立管理员账号和管理组

不要使用root作为日常远程登录账号。下面创建一个名为deployadmin的管理员账号，并加入专用的sshadmins组。账号名可以根据企业内部规范替换。

if ! getent group sshadmins >/dev/null 2>&1; then
    sudo groupadd --system sshadmins
fi

if ! id deployadmin >/dev/null 2>&1; then
    sudo adduser deployadmin
fi

sudo usermod -aG sshadmins,sudo deployadmin
id deployadmin

adduser会交互式要求设置账号信息。这里的密码仅用于账号初始化和本地sudo操作，后续SSH配置关闭密码认证后，远程SSH不会再接受密码。

如果业务部署账号不需要系统管理权限，不要把它加入sudo组。可以将deployadmin只作为运维管理员，把业务发布账号单独设置为非特权用户，避免业务凭据泄露后直接获得系统管理权限。

2. 导入管理员公钥并先测试

在管理电脑上执行以下命令，将本机的Ed25519公钥复制到新账号。SERVER_IP替换为服务器公网IPv4地址，密钥文件名按实际情况调整。

ssh-copy-id -i ~/.ssh/id_ed25519.pub deployadmin@SERVER_IP

复制完成后，在服务器上检查权限：

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

不要立即关闭当前root或旧管理员SSH会话。先从管理电脑新开一个终端，强制只使用公钥连接：

ssh \
  -o IdentitiesOnly=yes \
  -o PreferredAuthentications=publickey \
  -o PasswordAuthentication=no \
  -o KbdInteractiveAuthentication=no \
  -i ~/.ssh/id_ed25519 \
  deployadmin@SERVER_IP

登录后验证账号和管理权限：

whoami
id
sudo -v

如果这一步失败，应先解决密钥、目录权限、账号名称或网络问题，不能继续关闭root和密码登录。

3. 写入SSH安全配置

Ubuntu通常会读取/etc/ssh/sshd_config.d/*.conf中的配置。创建一个排序靠后的配置片段，便于独立管理和回滚：

sudo tee /etc/ssh/sshd_config.d/99-startup-access.conf >/dev/null <<'EOF'
# 仅允许管理组成员通过SSH登录
AllowGroups sshadmins

# 禁止root直接远程登录
PermitRootLogin no

# 只允许公钥认证
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
AuthenticationMethods publickey

# 降低暴力尝试的影响
MaxAuthTries 4
LoginGraceTime 30

# 关闭当前业务不需要的转发能力
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no

# 保留连接存活检测
ClientAliveInterval 300
ClientAliveCountMax 2

# 记录更详细的登录事件
LogLevel VERBOSE
EOF

这组配置的核心作用是：

• AllowGroups sshadmins：只有指定管理组成员可以通过SSH登录；
• PermitRootLogin no：即使有人取得root公钥，也不能直接使用root远程登录；
• PasswordAuthentication no和KbdInteractiveAuthentication no：关闭密码及交互式密码认证，降低密码泄露和撞库风险；
• AuthenticationMethods publickey：要求使用公钥认证；
• AllowTcpForwarding no、AllowAgentForwarding no和PermitTunnel no：关闭当前业务不需要的转发功能，减少SSH被当作中转通道使用的机会。

如果现有发布流程明确依赖SSH端口转发，应删除或调整AllowTcpForwarding no，不要为了套用示例而中断业务。调整后必须重新执行配置检查和连接测试。

先检查生效配置，再重载服务：

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T | grep -E '^(allowgroups|permitrootlogin|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|authenticationmethods|allowagentforwarding|allowtcpforwarding|x11forwarding|permittunnel|maxauthtries|logingracetime|clientaliveinterval|clientalivecountmax) '
sudo systemctl reload ssh
sudo systemctl is-active ssh

如果sshd -T显示的结果与配置文件不一致，先检查主配置和片段中的重复项：

sudo grep -RniE '^(AllowGroups|PermitRootLogin|PubkeyAuthentication|PasswordAuthentication|KbdInteractiveAuthentication|AuthenticationMethods|AllowAgentForwarding|AllowTcpForwarding|X11Forwarding|PermitTunnel)' \
    /etc/ssh/sshd_config /etc/ssh/sshd_config.d

OpenSSH对部分配置采用先读取值生效的规则。如果旧配置片段中已经出现相同指令，应清理重复项或将最终配置放到实际生效的位置，确认sshd -T输出正确后再重载服务。

4. 再限制SSH的来源地址

密钥认证解决的是“凭据是什么”，来源地址限制解决的是“谁可以接触到SSH服务”。如果企业有固定办公室出口IP或固定运维出口，建议在服务器防火墙中只放行该地址。

先确认当前防火墙状态和业务监听端口：

sudo ufw status verbose
sudo ss -lntp

以下以文档专用地址203.0.113.10/32为例。实际使用时必须替换成企业真实的固定公网IP。/32表示只允许一个IPv4地址。

sudo ufw allow from 203.0.113.10/32 to any port 22 proto tcp

如果服务器对外提供Web服务，只有在业务确实需要时才放行对应端口：

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

启用默认拒绝入站前，必须把现有业务端口和监控端口列清楚。该操作会影响所有未明确允许的入站连接，不只影响SSH。确认规则完整后再执行：

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status numbered

如果办公网络没有固定公网IP，不要把当前动态IP永久写入白名单，否则出口变化后可能无法登录。此时可以先保持“公钥认证加全球可达的22端口”，确认运维出口稳定后再增加来源限制。不要把修改SSH端口当成主要安全措施，端口变化无法替代密钥认证和来源控制。

如果服务器启用了IPv6，还要检查UFW是否启用IPv6规则，以及是否存在通过IPv6暴露SSH的情况：

grep '^IPV6=' /etc/default/ufw
sudo ss -lntp | grep -E '(\[::\]:22|0\.0\.0\.0:22)'

对于固定IPv6运维地址，应同步添加对应的IPv6来源规则；如果暂时不使用IPv6，应结合业务实际关闭不必要的IPv6入站路径，而不是只配置IPv4白名单。

成功验证：至少做四项测试

验证管理员密钥登录

从允许的管理地址新开连接：

ssh \
  -o IdentitiesOnly=yes \
  -o PreferredAuthentications=publickey \
  -o PasswordAuthentication=no \
  -o KbdInteractiveAuthentication=no \
  -i ~/.ssh/id_ed25519 \
  deployadmin@SERVER_IP

连接成功后执行：

whoami
id
sudo -v

预期结果是登录用户为deployadmin，用户组中包含sshadmins和必要的管理组，并且可以正常执行sudo认证。

验证root和密码登录被拒绝

不要关闭当前成功的管理员会话，另开终端测试：

ssh \
  -o IdentitiesOnly=yes \
  -o PreferredAuthentications=publickey \
  -i ~/.ssh/id_ed25519 \
  root@SERVER_IP

root登录应被拒绝。再测试密码认证路径：

ssh \
  -o PubkeyAuthentication=no \
  -o PreferredAuthentications=password \
  -o KbdInteractiveAuthentication=no \
  deployadmin@SERVER_IP

该连接也应失败。如果密码测试仍然能够登录，立即检查sshd -T的最终值，而不是只看配置文件中的某一行。

验证服务状态和日志

sudo systemctl status ssh --no-pager
sudo journalctl -u ssh -n 50 --no-pager
sudo /usr/sbin/sshd -T | grep -E '^(allowgroups|permitrootlogin|passwordauthentication|kbdinteractiveauthentication|authenticationmethods) '

如果系统服务名称是sshd，将命令中的ssh替换为sshd。日志中应能看到新管理员的成功认证，也应能看到被拒绝的root或密码登录尝试。

验证防火墙规则

sudo ufw status numbered
sudo ss -lntp | grep ':22'

从允许的管理地址测试22端口和SSH登录；从未列入白名单的网络测试时，只需确认连接被防火墙拒绝即可，不要为了测试而临时扩大开放范围。

出现问题时先保住现有会话

配置语法错误

如果执行sshd -t失败，不要执行reload。先定位报错行：

sudo /usr/sbin/sshd -t
sudo nl -ba /etc/ssh/sshd_config.d/99-startup-access.conf

如果问题来自本次新增片段，可以暂时将其移出读取路径：

sudo mv /etc/ssh/sshd_config.d/99-startup-access.conf \
    /etc/ssh/sshd_config.d/99-startup-access.conf.disabled

sudo /usr/sbin/sshd -t
sudo systemctl reload ssh

新账号无法登录

保持旧会话不退出，依次检查：

id deployadmin
getent group sshadmins
sudo namei -l /home/deployadmin/.ssh/authorized_keys
sudo journalctl -u ssh -n 100 --no-pager

常见原因包括：公钥复制到了错误用户、.ssh目录或authorized_keys权限过宽、账号没有加入sshadmins组、客户端使用了错误的私钥，或者防火墙没有放行当前出口地址。

客户端可以临时打开详细日志：

ssh -vv \
  -o IdentitiesOnly=yes \
  -i ~/.ssh/id_ed25519 \
  deployadmin@SERVER_IP

看到服务器拒绝公钥时，优先检查账号和文件权限；连22端口都失败时，优先检查UFW、服务商安全组和来源地址。

防火墙启用后无法连接

如果启用UFW后SSH中断，应立即使用服务商控制台处理。优先删除本次新增的错误规则；只有在确认当前防火墙规则会阻断全部管理入口时，才从控制台临时停用UFW：

sudo ufw status numbered
sudo ufw delete allow from 203.0.113.10/32 to any port 22 proto tcp

完全停用防火墙会扩大所有入站服务的暴露面，只适合作为短时间恢复措施。恢复登录后，应重新放行实际业务端口和正确的管理来源，再启用防火墙。

明确回滚方式

如果需要恢复本次SSH配置，先确认仍有控制台或当前管理员会话，然后执行：

sudo mv /etc/ssh/sshd_config.d/99-startup-access.conf \
    /etc/ssh/sshd_config.d/99-startup-access.conf.disabled

BKP=$(sudo find /root -maxdepth 1 -type d \
    -name 'ssh-hardening-backup-*' \
    -printf '%T@ %p\n' 2>/dev/null | sort -nr | head -1 | cut -d' ' -f2-)

printf '准备使用的备份：%s\n' "$BKP"
sudo cp -a "$BKP/sshd_config" /etc/ssh/sshd_config
sudo /usr/sbin/sshd -t
sudo systemctl reload ssh

如果只需要撤销本次新增片段，不要覆盖整个sshd_config。只有在确认主配置也被误改、并且备份目录确实对应本次操作时，才恢复主配置文件。

回滚并不意味着马上删除deployadmin账号。账号删除属于破坏性操作，可能影响仍在使用它的运维人员。应先确认替代管理员已经可以登录，再按企业账号生命周期流程移除账号、撤销公钥和回收权限。

上线验收清单

• [ ] 至少保留一个可用的服务商控制台或救援入口。
• [ ] deployadmin可以使用公钥登录，且已验证sudo权限。
• [ ] root远程登录被拒绝。
• [ ] 密码和交互式密码认证被拒绝。
• [ ] 只有sshadmins组成员可以通过SSH登录。
• [ ] sshd -t检查通过，systemctl reload ssh执行成功。
• [ ] sshd -T显示的生效配置符合预期。
• [ ] UFW或服务商防火墙只放行必要端口。
• [ ] SSH来源已限制为固定运维地址；若暂时无法限制，已明确采用密钥认证作为过渡方案。
• [ ] 配置备份目录可用，并且已验证一次片段禁用回滚。
• [ ] 后续OpenSSH更新安排在有控制台和备份的维护窗口内，更新后重新执行配置检查和登录验证。