小方有点小方先说个现实：我自己的服务器从用密码登录切换到SSH密钥登录，已经好几年了。现在让我回到纯密码登录，我肯定不愿意。原因很简单——密码登录又麻烦又不安全，而密钥登录在安全性和便利性之间找到了最平衡的方案。项目标题里的"客户机与服务器ssh秘钥登录"，本质就是一件事：让客户机可以不用密码、安全地登录远程服务器。
这篇文章我会从原理讲到实操，再到日常高频场景的配置，最后把常见问题一次说透。适合谁看？刚接触Linux服务器的小白、管理多台云服务器的运维、经常用VSCode远程开发的前后端，都能在这里找到自己需要的部分。我会尽量保持说人话，保证你看完能自己搞定密钥认证，而不是只拿到一堆命令。
1. SSH密钥登录的核心思路拆解
1.1 为什么密码登录越来越不够用
先聊我自己的体验。早年间管理服务器，用的是密码登录，每次ssh user@ip然后输密码。一开始觉得没啥，但服务器数量多起来之后，问题就暴露了。
第一是记忆负担。每台服务器的密码如果都不同，你得记一长串；如果都相同，一台机器被攻破就全部沦陷。第二是暴力破解风险。哪怕设置了复杂密码，只要服务器暴露在公网上，每天都会看到大量的Failed password日志，这个我不止一次被吓到。第三是团队协作的麻烦。几个人共用一个密码，有人离职了，要不要改？怎么通知所有人？效率极低。
密钥登录正好把这几个痛点全部解决：登录不需要输入密码，密码本身不存在于认证流程中；私钥不会传输到服务器，破解难度完全不在一个量级；团队成员各自持有自己的私钥，人员变动时只需要在服务器上增删对应的公钥一行配置，几秒钟搞定。
1.2 非对称加密：密钥认证的工作原理
SSH密钥认证基于非对称加密算法，常见的是RSA和Ed25519。它生成一对密钥：私钥和公钥。公钥可以公开分发，私钥必须自己保存好。
怎么理解这对密钥的关系？我用一个生活化类比：公钥就像一把挂锁，你可以把挂锁发给任何人；私钥是你手里的钥匙。别人用挂锁锁上一个箱子，只有你的钥匙能打开。对应到SSH场景，服务器手上的authorized_keys就是它信任的"挂锁"集合，客户机用私钥来证明"我就是那个拥有钥匙的人"。
实际认证流程分三步：
- 客户机发起SSH连接，向服务器声明要用公钥认证。
- 服务器从对应用户的authorized_keys文件中找到该客户机的公钥，生成一个随机挑战并加密，发给客户机。
- 客户机用私钥解密挑战，把结果回传给服务器。服务器验证通过，允许登录。
整个过程私钥始终留在客户机本地，不会出现在网络传输中，也不会上传到服务器。这就是密钥认证比密码认证安全的根本原因——密码每次登录都在传输，存在被截获的风险；私钥不参与双向传输，只要本地不被攻破，外部很难破解。
1.3 客户机与服务器的"角色分工"
在SSH密钥认证中，双方的角色非常清晰。
客户机是发起连接的一方，负责生成密钥对、保管私钥、向服务器提交公钥。服务器是被连接的一方，负责存放公钥，在客户机连接时发起挑战并验证身份。
公钥存放在服务器的哪个位置？对应用户家目录下的~/.ssh/authorized_keys文件。比如root用户登录，公钥就在/root/.ssh/authorized_keys；用ubuntu用户登录，就在/home/ubuntu/.ssh/authorized_keys。
这里有个概念要和虚拟机里的"客户机"区分开。在VMware这类虚拟化平台中，"客户机"通常指虚拟机Guest OS，和宿主机Host对应。但在SSH语境下，客户机指的是发起连接的那台机器，角色由连接方向决定，和机器类型无关。比如你用宿主机SSH连接虚拟机里的Linux，那宿主机就是客户机，虚拟机就是服务器端。我在后面会提到虚拟机场景的注意事项，因为热词里也有"客户机操作系统已禁用cpu"这类报错，这说明不少人确实在用虚拟机做服务器端测试，一旦虚拟化层出问题，SSH服务自然也起不来。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备与工具选型
2.1 客户机端：系统自带还是第三方工具
先说客户机的工具选择。在Windows上，Win10 1809之后的系统内置了OpenSSH客户端，打开PowerShell或CMD直接输入ssh命令就能用