必须先验证密钥登录成功，再禁用密码认证；否则将导致无法登录。需严格确保权限（~目录非777、.ssh为700、authorized_keys为600）、配置项（PasswordAuthentication no等全部显式设为no，PubkeyAuthentication yes）、语法正确，并用reload而非restart重启服务。
先验证密钥登录能通，再动配置
没验证成功就改 PasswordAuthentication no，等于主动锁门。必须用新密钥完整走通一次登录流程，才算过关。
- 本地生成密钥：运行
ssh-keygen -t ed25519 -C "you@host"，建议输passphrase - 推送公钥：优先用
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server_ip——它自动建目录、写文件、设权限（700和600） - 新开终端测试：直接
ssh user@server_ip，不输密码、秒进才算成功 - 保持当前登录终端别关，这是唯一能回滚的通道
/etc/ssh/sshd_config 必须显式关闭所有密码入口
只设 PasswordAuthentication no 不够，OpenSSH 有多个认证路径，漏一个就可能被绕过。
- 确认以下几行都存在且值为
no（取消注释并显式写）：PasswordAuthentication no、ChallengeResponseAuthentication no、KbdInteractiveAuthentication no、UsePAM no（若未定制 PAM 策略） - 必须显式启用密钥认证：
PubkeyAuthentication yes（别依赖默认值） - 限制 root 登录方式：
PermitRootLogin prohibit-password（允许密钥登，禁所有密码） - 检查
AuthorizedKeysFile是否仍为默认值.ssh/authorized_keys，避免被覆盖
权限错一点，OpenSSH 就静默拒绝
权限问题导致的 Permission denied (publickey) 占实际失败案例的 80% 以上，而且日志里往往没提示。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
-
~（家目录）不能是777，也不能带 sticky bit（如1755），否则 OpenSSH 直接跳过读取 -
~/.ssh目录权限必须是700：chmod 700 ~/.ssh -
~/.ssh/authorized_keys文件权限必须是600：chmod 600 ~/.ssh/authorized_keys - SELinux 启用时（如 CentOS/RHEL），补一句：
sudo restorecon -Rv ~/.ssh
重载前必做两件事：语法检查 + 活终端验证
直接 systemctl restart sshd 风险极高，一旦失败，新连接全断——云服务器通常没有控制台救援入口。
- 先校验配置语法：
sudo sshd -t，无任何输出才代表合法；有报错必须修完再继续 - 重载服务用
sudo systemctl reload sshd（比restart更稳妥，主进程不断） - 另开终端测试两件事：
ssh user@server_ip（应仍能免密进）和ssh -o PubkeyAuthentication=no user@server_ip（应立刻报错No supported authentication methods available） - 如果新连接失败，立刻用保留的活终端改回
PasswordAuthentication yes并reload
真正危险的不是配置项本身，而是把 PasswordAuthentication no 写进去却没验证密钥是否真能用——那一刻服务器就对你关上了门。权限、路径、顺序、验证，四者缺一不可。
