密钥认证为什么最有效
SSH 的暴力破解全部建立在口令上：只要服务还接受口令登录，公网上的 22 端口就会被持续尝试，成败取决于口令强度和锁定策略。改用密钥认证后这条路径直接消失——攻击者需要拿到私钥文件，而私钥不出现在网络流量里。这是投入最小、效果最确定的一条 SSH 加固，难点不在技术，而在确认所有使用者都已配好密钥。
基本信息
| 加固项 | SSH 认证方式收敛为密钥 |
|---|---|
| 适用平台 | Linux（OpenSSH 服务端） |
| 风险等级 | 高 |
| 基线项 | PasswordAuthentication no、PubkeyAuthentication yes |
| 前置条件 | 所有使用者已生成密钥并完成一次成功登录 |
典型使用场景
- 公网服务器加固：直接消除口令爆破这条攻击路径
- 等保身份鉴别：远程管理要求采用加密与更强的鉴别方式
- 自动化与发布：CI/CD、Ansible 等本来就用密钥，正好统一口径
- 事件后加固：发生过爆破或口令泄露后立即切换到纯密钥
- 多云与多主机管理：密钥可按主机或角色分文件管理，便于收回
核查与修改
核查与修改
grep -Ei '^(PasswordAuthentication|PubkeyAuthentication|PermitRootLogin)' /etc/ssh/sshd_config
sshd -T | grep -Ei 'passwordauthentication|pubkeyauthentication|permitrootlogin' # 看实际生效值
sed -i 's/^#\?PasswordAuthentication .*/PasswordAuthentication no/' /etc/ssh/sshd_config
sed -i 's/^#\?PubkeyAuthentication .*/PubkeyAuthentication yes/' /etc/ssh/sshd_config
sshd -t && systemctl reload sshd # 先语法检查再重载客户端侧：准备密钥并验证
客户端侧：准备密钥并验证
ssh-keygen -t ed25519 -C 'ops@example.com' # 生成密钥对
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server # 公钥下发到服务端
ssh -o PreferredAuthentications=publickey user@server # 只用密钥试登录
ssh -o PreferredAuthentications=password user@server # 确认口令登录已被拒绝sshd_config 关键参数
| 参数 | 建议值 | 说明 |
|---|---|---|
| PasswordAuthentication | no | 关掉口令认证，爆破直接失效 |
| PubkeyAuthentication | yes | 确保密钥认证开启，否则会全部登不上 |
| PermitRootLogin | prohibit-password | root 只能用密钥登录，保留应急路径 |
| KbdInteractiveAuthentication | no | PAM 交互式认证可能仍接受口令，需一并关闭更彻底 |
| AuthorizedKeysFile | .ssh/authorized_keys | 确认公钥存放路径与用户目录权限正确 |
切换前确认所有人都已有可用密钥并完成过一次成功登录：直接关口令会让还没有密钥的人立刻被挡在门外。改动时保留一个已登录会话，改完先新开窗口验证密钥能进，再退出旧会话。
sshd_config 采用首个生效：同一参数出现多次时以第一条为准，在文件末尾追加往往会白改。改完务必用 sshd -T 看最终生效值，它会把默认值与实际配置一起展开，比对着配置文件猜可靠。
更严的做法与代价
需要更强的保证时，可以用 AuthenticationMethods publickey 限定只允许密钥，或结合堡垒机强制跳板。代价是灵活性下降：应急场景下无法临时用口令登录，因此务必保留云控制台或带外管理通道，并将私钥的存放与备份纳入运维规范。