还在用密码登录服务器？手把手教你 SSH 密钥配置与密码禁用全攻略（附安全方案横评）

选型背景：为什么密码登录成了“定时炸弹”？

各位站长朋友，不知道你有没有经历过这样的时刻：午后正喝着咖啡，突然收到云平台一条告警短信——“您的服务器存在暴力破解风险”。登录后台一看，SSH 登录日志里密密麻麻全是来自海外 IP 的失败尝试，从 root 到 admin，从 22 端口到 2222 端口，扫得你头皮发麻。

这就是密码登录的原罪。只要密码还开着，你的服务器就相当于在公网上裸奔，任凭黑客用字典和脚本轮番轰炸。哪怕你设置了再复杂的 16 位密码，也架不住 Botnet 集群每天百万次的碰撞尝试。更别提很多新手站长图省事，直接用了弱密码，那基本等于把服务器钥匙挂在了门口。

要彻底根治这个问题，唯一的出路就是禁用密码登录，全面切换到 SSH 密钥认证。密钥登录基于非对称加密算法，私钥不出本地电脑，公钥放在服务器上。没有私钥，黑客就算拿到密码也没辙，因为密码认证的通道已经被你亲手焊死了。

今天这篇文章，笔者就带大家把这件事一次做透。不仅会给出具体的操作命令，还会把市面上主流的“密钥管理方案”拉出来做个横向对比，帮你找到最适合自己业务场景的那一款。

核心方案对比：三种主流 SSH 密钥管理模式横评

🔥 【限时特惠福利】高性价比独享云服务器限时 1 折起

搭建网站或部署容器推荐选择高稳定性独享云服务器。限时特惠通道开放中，点击即可领取专属满减代金券与特惠折扣：

👉 立刻领取云服务器限时优惠券

💡 延伸阅读：Docker 镜像拉取超时失败？国内镜像加速源到底怎么配？三套方案横向测评，彻底告别卡顿

在动手操作之前，我们先从宏观视角看看目前主流的几种密钥管理方案。这决定了你后续是“一把梭”还是“精细化运营”。

对比维度	方案A：单密钥对	方案B：多密钥对（按主机区分）	方案C：SSH Agent 转发
安全性	中（私钥泄露则全军覆没）	高（单点泄露影响面可控）	中高（依赖本地 Agent 防护）
管理成本	极低（只需维护一对密钥）	较高（需要维护多套公钥清单）	低（只需维护本地密钥）
适用场景	个人博客、单机测试环境	生产环境、多台服务器隔离管理	跳板机/堡垒机环境、需要二次跳转
优势	配置简单，上手最快	故障隔离，权限清晰	无需在跳板机存私钥，灵活
劣势	一旦丢失，恢复困难	密钥文件多，容易搞混	Agent 转发有被复用风险

看完表格，如果你还是拿不准，别急。下面笔者把方案A和方案B的完整操作步骤拆开揉碎讲清楚，你跟着做一遍，自然就明白该怎么选了。

方案A深度评测：单密钥对极简配置（适合个人站长）

💡 深度技术指南：容器内存告急，宿主机直接卡死？这份 Docker 内存排查实战手册请收好

这是最经典的玩法，也是笔者最推荐新手起步的方式。核心思路就是：本地生成一对密钥，把公钥上传到服务器，然后关掉密码登录。

第一步：在本地生成密钥对

无论你用的是 macOS 还是 Linux，都自带 OpenSSH 客户端。打开终端，输入以下命令：

ssh-keygen -t ed25519 -C "your_email@example.com"

这里强烈推荐使用 ed25519 算法，它比传统的 RSA 更安全、速度更快，而且密钥长度更短。如果你用的是老旧的 Windows 7 或者某些特殊环境，可能需要退回 RSA 4096 位：

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

执行后系统会问你保存路径和 passphrase（口令）。路径直接回车默认即可，但 passphrase 一定要设置。这个口令是保护你私钥的最后一道防线，就算私钥文件被盗，没有口令对方也无法使用。

第二步：上传公钥到服务器

这里推荐使用 ssh-copy-id 命令，一条命令搞定公钥安装和权限设置：

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@你的服务器IP

执行后会提示你输入一次服务器密码，输入正确后公钥就自动追加到了服务器的 ~/.ssh/authorized_keys 文件中。

如果没有 ssh-copy-id 命令（比如某些精简版系统），可以手动操作：

cat ~/.ssh/id_ed25519.pub | ssh root@你的服务器IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

第三步：验证密钥登录并关闭密码认证

先别急着关密码，先测试密钥是否能正常登录：

ssh -i ~/.ssh/id_ed25519 root@你的服务器IP

如果顺利登录，说明配置成功。此时再编辑 SSH 配置文件：

sudo vim /etc/ssh/sshd_config

找到以下几个关键项，确保它们是以下值：

# 禁用 root 密码登录（如果不需要 root 直接登录建议设为 no）
PermitRootLogin prohibit-password

# 启用密钥登录
PubkeyAuthentication yes

# 最关键的一步：禁用密码登录
PasswordAuthentication no

# 禁用空密码
PermitEmptyPasswords no

保存退出后，重启 SSH 服务让配置生效：

sudo systemctl restart sshd

⚠️ 重要提醒：在执行这一步之前，请务必确保你已经用密钥成功登录过一次，并且保持当前 SSH 会话不要断开。万一配置有问题，你还能用现有的连接恢复现场。这是无数站长用血泪换来的教训。

方案B深度评测：多密钥对隔离管理（适合生产环境）

如果你手上有五六台服务器，有的是业务服务器，有的是数据库服务器，有的是测试机，再共用同一把密钥就非常危险。一旦某台测试机被攻破，攻击者拿着私钥就能横扫你整个生产集群。

方案B的思路是为每台服务器生成独立的密钥对，并给密钥文件起好辨识度的名字。

操作步骤：分而治之

假设你有两台服务器，一台是 Web 服务器，一台是数据库服务器。你可以这样生成密钥：

# 生成 Web 服务器专用密钥
ssh-keygen -t ed25519 -f ~/.ssh/web_server_key -C "web-prod"

# 生成数据库服务器专用密钥
ssh-keygen -t ed25519 -f ~/.ssh/db_server_key -C "db-prod"

上传公钥时，使用 -i 参数指定对应的公钥文件：

ssh-copy-id -i ~/.ssh/web_server_key.pub root@web服务器IP
ssh-copy-id -i ~/.ssh/db_server_key.pub root@db服务器IP

登录时也要显式指定密钥文件：

ssh -i ~/.ssh/web_server_key root@web服务器IP

为了免去每次敲 -i 参数的麻烦，可以在本地 ~/.ssh/config 文件中配置主机别名：

Host web-prod
    HostName 你的Web服务器IP
    User root
    IdentityFile ~/.ssh/web_server_key

Host db-prod
    HostName 你的数据库服务器IP
    User root
    IdentityFile ~/.ssh/db_server_key

配置完成后，直接 ssh web-prod 就能登录，简洁高效。

关于 SSH Agent 的补充说明

方案C提到的 Agent 转发，适合有跳板机场景的运维老手。简单来说，就是把你的私钥“借”给跳板机用于认证，但私钥本身不落地。这里不展开细说，因为对于绝大多数站长而言，方案A和方案B已经完全够用。如果未来业务复杂到需要堡垒机，再研究不迟。

最终选型建议与安全加固清单

说了这么多，到底怎么选？笔者的建议很直接：

个人博客、小型站点、测试环境：选方案A。单密钥对 + 强 passphrase，配合云平台的安全组限制只允许常用 IP 访问 22 端口，安全系数已经足够高。
公司业务、多台服务器、有明确环境隔离需求：选方案B。虽然管理成本稍高，但安全隔离带来的收益远大于这点麻烦。

无论选哪种方案，下面这几个加固动作请务必一并完成：

修改 SSH 默认端口：将 22 端口改为 1024 以上的随机端口（如 22022），能过滤掉 90% 以上的无差别扫描。
启用 Fail2Ban：即使关闭了密码登录，Fail2Ban 依然能帮你拦截针对 SSH 服务的异常连接尝试。
禁用 root 直接登录：创建一个普通用户，赋予 sudo 权限，日常操作使用普通用户，需要提权时再 sudo。这能有效避免 root 权限被直接利用。

最后再多说一句，服务器安全从来不是一劳永逸的事。除了把好 SSH 这道大门，也别忘了定期给系统打补丁、升级软件包。另外，如果你还没有一台靠谱的云服务器来实践这些操作，不妨选择正规云厂商的新用户优惠机型，毕竟安全加固的第一步，是拥有一台配置合理、网络稳定的“家”。

希望这篇教程能帮你睡个好觉，不再被凌晨三点的暴力破解告警吵醒。