git客户端公钥怎么传到服务器？，ssh密钥配置失败怎么办

把客户端公钥推送到服务器的核心操作，就是通过ssh-copy-id命令一键完成授权，或者手动将~/.ssh/id_rsa.pub追加到服务器端的~/.ssh/authorized_keys文件中，掌握了这两种方式，你就不再需要每次连接都输入密码了。

为什么要先理解公钥与私钥的配对逻辑

很多新手在配置免密登录时，容易把“推”和“拉”的关系弄反，客户端生成的是一对密钥：私钥留在本地（相当于你的身份证），公钥放到服务器（相当于门禁系统里的备案信息），服务器验证的是签名,不是密码本身。

加载中

【Git教程】5-8 SSH公钥配置

苏打开源

1.5万1335

原视频地址

理解authorized_keys文件的作用

服务器端的~/.ssh/authorized_keys文件是整个免密机制的核心，当你在客户端发起SSH连接时，服务器会用这个文件里的公钥来挑战你的私钥，如果匹配成功，直接放行，行业共识认为，理解这个文件的管理权限比记住命令本身更重要文件权限必须是600，所属目录权限必须是700,否则SSH服务会出于安全考虑忽略该文件。

确认本地是否已有密钥对

在推送之前，先检查本地是否存在密钥,打开终端执行：

ls -la ~/.ssh/

如果看到id_rsa和id_rsa.pub两个文件，说明已经生成过密钥对。id_rsa是私钥，务必不要泄露；id_rsa.pub是公钥，就是待会儿要推送到服务器的内容，如果目录为空或者根本没有.ssh目录,则需要重新生成。

git公钥生成后怎么配置

这是国内开发者最常搜索的操作路径，生成密钥的步骤极其简单，但很多人卡在了“生成后不知道该拿这个文件怎么办”,这里给出标准流程。

使用ed25519算法生成更安全的密钥

较新的SSH版本支持ed25519算法，相比传统的rsa更安全且长度更短,执行以下命令：

ssh-keygen -t ed25519 -C "你的邮箱或备注"

如果服务器版本较老，只能兼容RSA,则改用：

ssh-keygen -t rsa -b 4096 -C "你的邮箱或备注"

回车后系统会询问保存路径和密码短语。路径直接回车默认即可，密码短语可以不设置（直接回车两次），但如果追求更高的安全性，建议设置一个，注意，设置密码短语后，每次使用私钥都需要输入这个短语,实际操作中很多人因为嫌麻烦而留空。

复制公钥内容的两种方式

生成完毕后，公钥文件是纯文本，内容格式为ssh-ed25519 AAAA... 你的备注，在Linux或macOS下用cat

命令查看，在Windows的PowerShell下用type命令查看。

cat ~/.ssh/id_ed25519.pub

完整复制输出的所有内容,这是接下来要推送到服务器的核心数据。

ssh公钥推送到服务器命令有哪些

最常见的推送命令是ssh-copy-id，它帮你省去了手动创建目录和处理权限的麻烦，但很多用户想了解更底层的实现原理,我这里把三种典型方式都列出来。

ssh-copy-id一键推送

这是最推荐的方式,尤其适合不熟悉Linux文件权限的新手。

ssh-copy-id -i ~/.ssh/id_ed25519.pub 用户名@服务器IP

执行后输入一次服务器密码，公钥就会自动追加到服务器上对应用户的authorized_keys文件中，命令内部做了三件事：连接服务器、创建.ssh目录（如果不存在）、将公钥追加到authorized_keys。执行完务必测试免密登录：

ssh 用户名@服务器IP

如果直接进入服务器而不再提示密码,推送成功。

手动追加公钥

当ssh-copy-id不可用（部分精简版系统未安装此工具）时，采用手动方式,先在本地查看公钥内容并复制：

cat ~/.ssh/id_ed25519.pub

然后登录服务器：

ssh 用户名@服务器IP

在服务器上执行以下命令：

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "粘贴你刚才复制的公钥内容" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

注意，你的服务器登录用户决定了公钥归属于哪个账户，比如用root登录，那公钥就只对root用户生效，如果你平时用普通用户登录，就要在普通用户的家目录下执行上述操作，这一步是git公钥生成后怎么配置中最容易出错的地方很多用户用root配置完,切换普通用户登录时发现仍要密码。

scp传输后追加

如果公钥文件在本地，也可以通过scp传到服务器临时目录,再登录服务器追加。

scp ~/.ssh/id_ed25519.pub 用户名@服务器IP:/tmp/
ssh 用户名@服务器IP
cat /tmp/id_ed25519.pub >> ~/.ssh/authorized_keys
rm /tmp/id_ed25519.pub

这种方式适合公钥内容过长、手动复制容易遗漏的场景。

GitHub和Gitee平台的公钥配置差异

大多数开发者使用git不仅仅是连接自己的服务器，还要推送代码到代码托管平台，这个场景下，“服务器”变成了平台方的服务器,配置路径从命令行变成了网页操作。

GitHub配置路径

登录GitHub后，依次进入Settings → SSH and GPG keys → New SSH key随意填写，Key区域粘贴你的公钥内容，点击添加，这里的核心坑在于：粘贴时不能有多余空格或换行符,粘贴后仔细检查前后是否有遗漏。

Gitee配置路径

Gitee的路径是设置 → 安全设置 → SSH公钥，整个流程与GitHub类似，但据部分开发者反馈，Gitee的密钥校验有时存在缓存延迟,添加后等待几分钟再测试连接比较稳妥。

公司内部GitLab配置路径

内网部署的GitLab通常路径为Preferences → SSH Keys，部分企业开启了LDAP或SSO登录，这种情况下公钥绑定的是企业的统一身份ID，离职后公钥自动失效,无需手动删除。

测试连接是验证推送是否成功的唯一标准

很多人在配置完公钥后直接git clone，提示权限错误就懵了,测试连接的命令如下：

对于GitHub：

ssh -T git@github.com

看到Hi 你的用户名! You've successfully authenticated 说明成功。

对于Gitee：

ssh -T git@gitee.com

对于自有服务器：

ssh -T 用户名@服务器IP

有些操作场景下推出了ssh config配置来管理多主机密钥，如果你同时使用多个平台，建议在~/.ssh/config中为不同主机指定不同的密钥文件：

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_github
Host myserver
  HostName 192.168.1.100
  User root
  IdentityFile ~/.ssh/id_ed25519_server

这样配置后，git clone git@github.com:用户名/仓库名.git会自动匹配对应的密钥,不用手动切换。

git ssh密钥配置失败常见原因排查

即使操作步骤完全正确，依然有部分开发者遇到配置后不生效的情况，根据多个技术社区的问题汇总,绝大多数失败集中在以下四个原因。

本地私钥和公钥不匹配

如果你之前生成过多次密钥，又在不同目录下执行过操作，可能推送的是A公钥，而当前环境里git使用的是B私钥,排查方法：

ssh-add -l

这个命令列出当前SSH代理中加载的私钥，如果列表为空,手动添加：

ssh-add ~/.ssh/id_ed25519

服务器端目录权限错误

这是手动配置时最常见的问题,用下面命令修复：

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

注意，~/.ssh目录的父目录（即你的家目录）也不能被其他用户写入，否则SSH会拒绝信任,执行：

chmod go-w ~

密钥格式不被服务器接受

部分老版本操作系统自带的SSH服务不认ed25519格式公钥，观察服务器系统版本，如果是CentOS 6或更早的Ubuntu版本，建议重新生成RSA格式密钥，或者用ssh-keygen -p -f ~/.ssh/id_ed25519 -m PEM转换格式。

多个公钥混用导致认证顺序问题

如果有多个公钥文件在~/.ssh目录下，SSH客户端会按顺序尝试，如果某个公钥被服务器拒绝，可能不会自动尝试下一个，解决方式是在~/.ssh/config中通过IdentitiesOnly yes参数强制使用指定密钥。

用户常问的关于公钥推送的实操问题

git配置公钥后clone依然提示要密码是什么原因

这个情况基本可以断定公钥没有被正确加载，先跑一遍ssh -T git@github.com（或对应的平台），看输出信息，如果是Permission denied (publickey)，重点检查当前git仓库的远程URL是否使用的是SSH协议，如果你在clone时用的是https://开头的链接，git会走用户名密码认证，与公钥完全无关,解决办法是修改远程地址：

git remote set-url origin git@github.com:用户名/仓库名.git

公司电脑换新后怎么把旧公钥推送到新服务器的备份

如果你在新电脑上重新生成了一对密钥，且需要推送的服务器还在运行，直接在新电脑上执行ssh-copy-id即可，但注意：新公钥追加到authorized_keys后，旧公钥默认仍然保留，从安全角度考虑，建议登录服务器，手动编辑authorized_keys文件，删除不再使用的旧公钥行,避免离职员工或丢失的设备继续拥有访问权。

多台电脑是否可以共用同一份公钥

技术上完全可以，将同一公钥文件的内容复制到多台需要连接的本地机器上，配上对应的私钥即可，但行业专家指出，多台设备共用同一私钥会扩大泄露面，任一台设备被攻破，私钥就泄露了，所有服务器都会暴露，对于追求高安全性的团队，推荐每台设备生成独立密钥对，然后在服务器上追加多个公钥，每个公钥占一行，这样即便某个设备丢失，只需在服务器上删除对应行即可精准回收权限,不影响其他设备。

服务器端的authorized_keys文件每行对应一个公钥，完全支持数百个条目，维护多个公钥的加分操作是：在每个公钥末尾的备注里加上设备名或使用人姓名,方便后续识别和清理。