把客户端公钥推送到服务器的核心操作，就是通过ssh-copy-id命令一键完成授权，或者手动将~/.ssh/id_rsa.pub追加到服务器端的~/.ssh/authorized_keys文件中，掌握了这两种方式，你就不再需要每次连接都输入密码了。
为什么要先理解公钥与私钥的配对逻辑
很多新手在配置免密登录时，容易把“推”和“拉”的关系弄反，客户端生成的是一对密钥：私钥留在本地（相当于你的身份证），公钥放到服务器（相当于门禁系统里的备案信息），服务器验证的是签名,不是密码本身。
理解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文件每行对应一个公钥，完全支持数百个条目，维护多个公钥的加分操作是：在每个公钥末尾的备注里加上设备名或使用人姓名,方便后续识别和清理。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/git%e5%ae%a2%e6%88%b7%e7%ab%af%e5%85%ac%e9%92%a5%e6%80%8e%e4%b9%88%e4%bc%a0%e5%88%b0%e6%9c%8d%e5%8a%a1%e5%99%a8%ef%bc%9f%ef%bc%8cssh%e5%af%86%e9%92%a5%e9%85%8d%e7%bd%ae%e5%a4%b1%e8%b4%a5%e6%80%8e/
