如何配置ssh免密码登录？ssh密钥认证设置方法

配置ssh免密码登录的核心答案只有一句话：在本地执行 ssh-keygen 生成密钥对，再用 ssh-copy-id 把公钥推到服务器，最后确认权限正确，即可实现免密登录。

这整套操作做完通常不超过三分钟，却能让你彻底告别每天输密码的重复劳动，下面按照最常见的实操顺序，拆解每一步要做什么、为什么要这么做,以及出问题时到哪里找原因。

ssh免密码登录的原理和适用场景

为什么密码登录用起来这么别扭

每次连服务器都要输入密码，看起来只是多花几秒钟，真正麻烦的是密码安全策略，出于合规要求，生产环境的服务器密码往往设定得很长，混合大小写字母、数字和特殊符号，输入一次还能忍，一天切换十几台机器就非常煎熬，不少人为了提高效率把密码改简单,反而带来更大的安全风险。

密钥登录解决的是“身份验证”和“便利性”的矛盾

业内专家指出，SSH密钥认证属于非对称加密的一种典型应用场景，简单说就是两个钥匙：一把私钥留在本地，相当于你的身份证，绝不外传；一把公钥放在服务器的 authorized_keys 文件里，相当于服务器的访客名单，登录时文件做一次数学匹配，配对成功就放行,根本不走密码通道。

这个机制带来的直接改变是：

• 本地私钥不经过网络传输，杜绝了密码被中间人截获的风险
• 登录速度更快，省去密码交互和验证的过程
• 配合 ssh-agent 把私钥标记进内存后，连本地密码都不用重复输入
• 适合自动化脚本、Ansible批量操作、CI/CD流水线等无人值守场景

需要准备的三个前提条件

1. 本地机器安装有 OpenSSH 客户端（Win10以上自带、macOS内置、Linux默认都有）
2. 目标服务器的远程登录服务已启用（sshd服务正常监听22端口）
3. 你能通过密码方式正常登录目标服务器（这是分发公钥的前提）

Linux下配置ssh免密码登录的三步流程

这是使用频率最高的一条路径，无论你管理的是酷番云、简米云还是自建的物理机,操作逻辑完全一致。

第一步：生成密钥对

在本地终端执行下面的命令：

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

-t ed25519 指定密钥类型，目前行业共识认为ed25519比传统RSA更安全快捷，如果你的服务器上跑的是比较老的操作系统，OpenSSH版本低于6.5，则改用 ssh-keygen -t rsa -b 4096 更稳妥。

执行过程中会询问存储路径和设置口令（passphrase），全部保持默认路径，存储到 ~/.ssh/id_ed25519 即可，口令处直接回车跳过,这样登录时不需要额外输入任何东西。

完成后检查一下生成了哪些文件：

ls -l ~/.ssh/

里面多了两个文件：私钥 id_ed25519 和公钥 id_ed25519.pub。

第二步：把公钥拷贝到目标服务器

执行下面的命令，把公钥推送到服务器的 ~/.ssh/authorized_keys 文件中：

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server_ip

执行过程中会提示输入一次目标服务器的登录密码，输入后自动完成配置迁移，这台服务器今后就在“信任名单”里了。

如果你的服务器没有 ssh-copy-id 这个工具（比如macOS上偶尔会缺少）,手动把公钥内容追加到远程文件中也有同样的效果：

cat ~/.ssh/id_ed25519.pub | ssh user@server_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

第三步：测试免密登录是否生效

直接尝试连接目标服务器：

ssh user@server_ip

正常情况下不会再提示输入密码,直接进入远程终端的shell界面。

测试完成后还可以顺手检查一下precious文件的权限是否锁死,正确的权限标准是固定的：

• 服务器端 .ssh 目录权限为 700
• 服务器端 authorized_keys 文件权限为 600
• 本地端 .ssh 目录权限为 700
• 本地端私钥文件权限为 600

windows下ssh免密登录配置步骤

很多开发者的日常主力机是Windows，又需要用ssh管理Linux服务器，Windows 10版本1809之后系统自带OpenSSH客户端，配置流程与Linux基本一致,差别只在于命令行的操作方式略有不同。

在PowerShell中生成密钥并推送公钥

打开PowerShell,执行与Linux相同的密钥生成命令：

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

后续步骤的操作逻辑不变：

1. 查看公钥文件内容：Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub
2. 使用ssh-copy-id命令推送公钥：type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh user@server_ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
3. 还需要确保远程目录权限正确：部分Windows用户推送公钥后登录被拒，原因通常是目标服务器上 ~/.ssh 目录的属主不对

Windows下还要注意换行符的问题，在PowerShell中使用 type 管道传递公钥内容时，偶尔会出现多出一个 ^M 字符的情况，导致密钥校验失败，这种场景下优先使用 ssh-copy-id

命令更省心，Windows的OpenSSH已内置了这个工具,直接调用即可：

ssh-copy-id user@server_ip

ssh免密码登录不生效的排错思路

配置步骤本身很简单，但真正投入生产使用时，总会遇到各种各样的环境差异问题，排查思路按照“从低到高”的层次递进,效率更高。

权限设置是最大的高频坑

最常见的报错信息是 Permission denied (publickey,gssapi-keyexch,password)，出现这个提示时,先检查目标服务器的文件权限。

登录服务器执行：

ls -la ~/.ssh/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

还有一层隐蔽的权限问题：如果用户的家目录权限是 775 或 777，sshd会认为不安全，同样拒绝密钥认证，把家目录权限收紧到 755 或 700,然后重启ssh服务即可。

sshd配置文件中的认证开关

服务器的 /etc/ssh/sshd_config 文件决定是否接受密钥登录,需要重点确认三个参数：

PubkeyAuthentication yes
RSAAuthentication yes
PasswordAuthentication yes

前两项必须保持 yes，它们决定是否启用密钥验证方式。PasswordAuthentication 的默认配置看具体情况，暂时不用动，修改完成之后执行 systemctl restart sshd 让配置生效。

是否被完整复制

如果权限和sshd配置都对，仍然提示失败，大概率是公钥内容在复制过程中被截断或引入了额外字符，尤其是从Windows复制到Linux时,粘贴过程中自动换行经常造成密钥不完整。

对比一下本地公钥和服务器 authorized_keys 文件中对应的那行，确认这几点：开头必须包含 ssh-ed25519 或 ssh-rsa 前缀；结尾必须包含当初设定的注释邮箱；整行没有被动过分行。

多用户环境下的路径归属

管理多台服务器时，容易把用户填错，比如默认用 root 用户推公钥，但实际日常操作用的是普通用户,那普通用户目录下的认证文件里自然没有对应的公钥信息。

确保在命令中指定了正确用户：

ssh-copy-id -i ~/.ssh/id_ed25519.pub devops@your_server_ip

密钥文件的安全底线不能松

密钥登录带来便利的同时，引入新的安全责任，私钥泄露相当于服务器大门的钥匙给了别人,必须从源头上做好防护。

私钥文件本身要加密保护

生成密钥时，如果你在passphrase处直接回车，私钥就是裸奔状态，任何拿到私钥文件的人都能直接登录你的服务器,建议遵循以下做法：

• 保留passphrase，它相当于给私钥上第二道锁



• 配合 ssh-agent 使用，启动时输入一次passphrase后暂存在内存中，后面会话不再重复验证
• 设置 AgentForwarding 能让你在跳板机上继续用本机密钥认证，而不用把私钥拷贝到跳板机

服务器关掉密码登录的注意事项

密钥配置验证无误后，可以进一步加固服务器,禁用密码登录：

sudo vi /etc/ssh/sshd_config

把配置文件中的 PasswordAuthentication 改成 no,保存后重启ssh服务。

这个操作的前提是你的密钥登录已达全部可用状态，多数运维事故就是在密钥尚未验证通过的情况下盲目关闭密码认证，结果弄丢了自己登录服务器的最后通道，执行此操作前，强烈建议另开一个终端测试密钥登录是否稳定,从多个网络环境验证过再操作。

及时更换泄露风险的密钥

常被忽视的细节是：开发人员离职、项目外包合作结束、本地电脑丢失，这些场景下旧密钥是否还被允许访问你的服务器，定期巡检安全资产时,顺手做一轮整批的密钥轮换动作：

1. 扫描服务器上的 authorized_keys 文件，确认每一行对应哪些人员
2. 更新服务器端公钥时同步更新所有登录客户端的本地密钥
3. 使用CentOS或Ubuntu均适用，无发行版差异

关于ssh免密码登录的常见问题排查Q&A

ssh免密登录配置完成后仍然提示要输入密码，大概率是什么原因？

出现这种状况时，优先检查服务器端是否开启了对密钥认证的支持，在 sshd_config 文件里确认 PubkeyAuthentication yes 是启用状态，另一个高频原因是SSH服务在读取 authorized_keys 时发现该文件或所在目录的属主不是当前用户。

多数情况下把权限按 700、600 的标准重新设置一遍即可解决。

为什么公钥推送到服务器后，还是无法登录？

检查目标服务器对用户家目录的写入权限是否受限，部分云服务器厂商的安全基线会强制将 /root 目录设为 700，同时禁止其他用户访问，这种情况下需要确认当前操作系统用户对SSH配置目录拥有完整读写权，使用 sudo 执行配置命令，或者改用root用户操作后，再将公钥追加到目标用户的 authorized_keys 中。

生成了rsa密钥之后，还能改成ed25519吗？

可以随时更换，在新环境重新执行 ssh-keygen -t ed25519，然后指导目标服务器重新推送公钥，更换期间如果要保留旧密钥的访问能力，只需在两套密钥并行存在一段时间，待所有客户端都完成切换后，再从服务器的 authorized_keys 中移除旧公钥,这个过渡方式能保证服务不中断。