配置 SSH 服务仅允许指定密钥登录，是当下抵御暴力破解最直接、最有效的手段。 完成这一步配置，你的服务器基本告别了“密码猜测”这一最常见的入侵路径。
先给结论：核心思路是修改 /etc/ssh/sshd_config 文件，将 PasswordAuthentication 设为 no，同时开启 PubkeyAuthentication，并把你的公钥提前写入服务器，这样，除了持有私钥的你，任何人都无法通过 SSH 登录，包括那些每天都在扫描你 22 端口的黑客脚本。
为什么必须抛弃密码登录
很多人觉得密码登录方便，但代价是巨大的，业内专家指出，互联网上针对 22 端口的暴力破解攻击从未停止过，任何暴露在公网的服务器，每天都会收到几十次到几千次的陌生 IP 尝试登录。
密码登录的致命弱点
- 弱口令是重灾区：
root、123456、admin这类密码,破解只是时间问题。 - 字典攻击成本极低：黑客的字典库包含海量常用密码组合，配合自动化工具,几分钟就能跑完一轮。
- 撞库风险：你在其他网站泄露过密码,会被直接拿来尝试登录你的服务器。
- 无法追踪：密码是共享的秘密，一旦泄露,你根本不知道是谁在用。
密钥登录则完全不同。 它基于非对称加密算法，私钥只存在你本地设备，公钥放在服务器，没有私钥，即使知道用户名，也无法完成身份验证,这相当于给服务器换了一把只有你有的钥匙。
如何配置 ssh 密钥登录？一份实操指南
这里以最常见的 Linux 服务器（Ubuntu/Debian/CentOS）和本地 Windows/Mac 终端为例,整个过程分四步走。
第一步：在本地生成密钥对
打开本地终端（Windows 10 以上自带 OpenSSH 客户端，直接使用 PowerShell 即可）,输入命令：
ssh-keygen -t ed25519 -C "你的备注信息"
推荐使用 ed25519 算法，它比传统的 RSA 更安全、速度更快，而且密钥长度更短，如果你的系统不支持，可以用 ssh-keygen -t rsa -b 4096。
- 一路回车，选择默认保存路径（
~/.ssh/id_ed25519）。 - 务必设置私钥口令（passphrase），这一步很多人忽略，但非常重要，即使私钥文件被窃取，没有口令,对方也无法使用。
- 生成后，你会看到两个文件：
id_ed25519（私钥，永远不要离开你的设备）和id_ed25519.pub
（公钥，可以随意分发）。
第二步：将公钥部署到服务器
这个操作有多种方式，推荐使用 ssh-copy-id 工具，它能自动帮你追加公钥到服务器的 ~/.ssh/authorized_keys 文件,并设置好权限。
ssh-copy-id -i ~/.ssh/id_ed25519.pub 用户名@服务器IP
执行后会要求输入一次服务器密码（这是你最后一次输入密码），完成后,直接测试密钥登录：
ssh 用户名@服务器IP
如果顺利进入系统,说明公钥已经生效。
手动部署的场景：如果你的本地没有 ssh-copy-id（比如某些 Windows 旧版本），可以手动操作,登录服务器后执行：
mkdir -p ~/.ssh echo "公钥内容" >> ~/.ssh/authorized_keys chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys
这里的权限设置很关键，如果权限过于开放，sshd 服务会直接拒绝读取这个文件,导致登录失败。
第三步：修改 sshd 配置并重启服务
确认密钥登录没问题后，编辑服务器上的 SSH 配置文件：
sudo vim /etc/ssh/sshd_config
找到并修改以下参数，如果前面有 ,先去掉注释：
# 禁用密码登录，这是核心 PasswordAuthentication no # 启用公钥认证 PubkeyAuthentication yes # 明确指定密钥文件位置 AuthorizedKeysFile .ssh/authorized_keys # 建议禁止 root 直接登录，使用普通用户 + sudo PermitRootLogin prohibit-password
特别注意：修改配置前,最好先测试配置是否有语法错误。
sudo sshd -t
如果输出为空，说明配置没问题,然后重启服务：
sudo systemctl restart sshd
重启前请务必保持当前 SSH 会话不要关闭。 如果新配置有误，你还有当前会话可以修复，一旦断开,可能就真的进不去了。
第四步：验证安全效果
重新开一个终端窗口，尝试用密钥登录，确认能正常进入,然后故意用错误密码测试：
ssh 用户名@服务器IP
此时会直接提示 Permission denied (publickey)，不再弹出密码输入框，这说明配置成功,密码认证已经被彻底关闭。
多用户场景下的密钥管理与授权
如果是团队协作，多个人需要管理同一台服务器,每个成员都应该有自己的密钥对。
各用各的钥匙，出了问题好溯源
- 每个成员在本地生成自己的密钥对，私钥自己保管,公钥发给管理员。
- 管理员把每个人的公钥分别追加到各自用户的
~/.ssh/authorized_keys文件中。 - 这样每个人都有自己的系统账号,登录日志能清晰记录是谁在什么时候操作过。
- 某个人离职，直接删掉他的账号或从
authorized_keys中移除他的公钥即可,不影响其他人。
利用 SSH Config 文件简化连接
当服务器多了之后，每次都输入 ssh 用户名@IP -p 端口 很麻烦，可以在本地 ~/.ssh/config 文件中配置主机别名：
Host my-server
HostName 你的服务器IP
User root
Port 22
IdentityFile ~/.ssh/id_ed25519
之后直接输入 ssh my-server 就能连接,省时省力。
关闭密码登录后的常见问题与急救方案
这是很多人最担心的一步，一旦操作失误，服务器可能彻底失联,下面这些方案能帮你脱困。
配置后无法登录，提示 Permission denied
- 检查
authorized_keys权限：确保.ssh目录是700，authorized_keys文件是600。 - 检查 SELinux 上下文：CentOS 系统如果开启了 SELinux，需要执行
restorecon -Rv ~/.ssh来恢复正确的上下文。 - 检查密钥格式：确认粘贴到服务器上的公钥内容是一整行,没有换行或空格。
- 检查 sshd 配置：再次执行
sudo sshd -t确认语法无误。
急救入口：如果你用的是云服务器，大多数云厂商（简米云、酷番云、AWS）都提供了网页版的 VNC 登录或 救援模式，通过这个入口，即使 SSH 完全不可用,你也能登录服务器修改配置。
忘记私钥口令或私钥丢失
- 私钥一旦丢失且没有备份,你将被永久锁在服务器外。
- 此时只能通过 VNC 登录，重新生成一对新的密钥，将新公钥覆盖到
authorized_keys。 - 或者临时修改
sshd_config，将PasswordAuthentication改回yes，重启服务后用密码登录，再把新公钥部署上去,最后再次关闭密码登录。
建议：私钥一定要有备份，可以存放在加密的 U 盘或密码管理器中。
让密钥登录更安全的三个进阶习惯
关闭密码登录只是第一步，为了让这套机制更坚固,以下几个习惯值得养成。
使用 SSH Agent 管理私钥
如果私钥设置了 passphrase，每次连接都要输入一次口令，很烦人，使用 ssh-agent 可以帮你缓存私钥：
eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519
输入一次口令后，后续连接同一台机器都不需要再输入了，Mac 用户还可以让系统钥匙串帮你记住。
配合 fail2ban 做二次防御
即使关闭了密码登录，攻击者依然会尝试连接，反复建立认证请求，安装 fail2ban 可以自动封禁多次尝试失败的 IP：
sudo apt install fail2ban
默认配置下，连续失败 5 次，IP 会被封禁 10 分钟,这能有效降低无效连接对服务器资源的消耗。
定期审计 authorized_keys 文件
定期检查服务器上所有用户的 ~/.ssh/authorized_keys，确保里面没有多余的、你不认识公钥，建议每季度执行一次审计，一旦发现异常公钥,立即移除并修改系统密码。
常见疑问解答
问：我配置了密钥登录，但密码登录还能用，为什么？
答：配置没有完全生效，检查 sshd_config 文件中是否有多处 PasswordAuthentication 配置，sshd 默认以第一个找到的配置为准，确保将整个文件中的该参数都修改为 no，并执行 sudo systemctl restart sshd 重启服务。
问：云服务器默认用 root 登录，我可以直接关闭 root 的密码登录吗？
答：可以，推荐使用 PermitRootLogin prohibit-password，这允许 root 使用密钥登录，但禁止密码登录，不过更安全的方式是创建一个普通用户并赋予 sudo 权限，日常使用该用户操作，需要提权时再执行 sudo 命令，减少 root 账号暴露面，酷番云和简米云的默认安全组通常也建议不开放 22 端口给所有 IP，而是限制为你的办公网络 IP。
问：不同云厂商的密钥管理工具有什么区别？
答：简米云、酷番云均提供基于密钥对的实例登录方式，密钥由云端托管并注入系统，这种方式的优势在于创建实例时无需设置密码，且适用于批量开通服务器场景，但如果你在第三方安全审计中需要确认私钥完全由自己控制，推荐使用自建密钥，即按照本文手动配置的方式，私钥生成和存储都在本地完成，不经过云厂商系统，两者并不冲突，你也可以在云厂商控制台创建密钥，同时在系统内追加自己的公钥,实现双通道登录管理。