做运维和开发的朋友应该都知道SSH Key这个东西几乎是每天都要打交道的。不管你是要登录云服务器、往GitHub上推代码还是管理公司内网的一批Linux机器只要涉及SSH远程连接就绕不开密钥认证。我在Ubuntu上折腾过不少次生成SSH Key的操作从最开始跟着教程一步一步敲命令到后来理解了整个原理、踩过各种坑中间其实有不少值得记录的东西。这篇内容就围绕“Ubuntu系统中生成SSH Key”这条主线展开把从生成、部署到排错、多密钥管理的完整过程都过一遍。不管你是刚接触Linux的新手还是已经用过一段时间但想搞清楚背后逻辑的进阶用户都能从里面找到能直接拿去用的东西。我会尽量把每一步为什么这么做讲明白而不是只丢给你一串命令就完事。1. SSH Key到底是什么为什么值得换掉密码登录1.1 先搞清楚SSH Key的工作原理很多人第一次接触SSH Key的时候听说了“公钥”“私钥”这两个词但并不知道它们之间到底是什么关系。打个比方你可以把公钥想象成一把锁把私钥想象成唯一的钥匙。你可以把锁公钥随意分发出去放到你想要登录的服务器上而钥匙私钥必须牢牢留存在你自己的电脑里绝对不能给别人。当你发起SSH连接的时候服务器会拿着一把“挑战”来考验你它会用你事先放好的那把锁公钥生成一个只有钥匙私钥才能正确回答的问题。你的客户端用私钥回答完毕服务器验证通过连接就建立了。整个过程里私钥的内容不会直接传输到网络上传输的只是一个经过签名的验证结果所以安全性比密码登录高出一个量级。理解了这一点你就能明白为什么大家都推荐用SSH Key而不是密码登录了。密码是静态的一旦在网络传输过程中被截获或者因为撞库、弱口令被爆破别人就能直接登录你的机器而密钥是一套动态的挑战-应答机制即使网络抓包也抓不到私钥本身安全性完全不一样。1.2 密码登录的痛点在哪里我自己在真实环境里见过太多因为密码登录出事的例子。最常见的就是服务器暴露在公网上被自动化脚本不断地尝试爆破。那些脚本会从密码字典里挨个试比如admin、123456、password一天能撞几万次。就算你设了一个还不错的密码防住了简单的爆破也架不住某些人安全意识淡薄把密码写到代码仓库里、贴到聊天记录里一次泄露全线崩溃。另外密码登录还有一个很烦人的问题每次连接都要输一次密码。你要是频繁操作多台服务器一天下来手都快敲酸了而且密码输多了难免会有输错的时候。SSH Key配置好之后直接一条命令就登录上去不用输任何东西那种顺滑感用一次就回不去了。1.3 什么时候必须用SSH Key有些场景下SSH Key不只是“推荐”而是“必须”。比如GitHub、GitLab这些代码托管平台早就关闭了用账号密码进行Git操作的方式想往远程仓库推送代码只能走SSH Key或者Personal Access Token。还有企业内部的一些跳板机通常也强制要求密钥认证普通用户根本没有用密码登录的权限。我做项目部署的时候也深有体会CI/CD流水线里构建服务器要拉取私有仓库代码、要登录生产环境执行发布脚本这些场景没法人工输入密码必须预先配好密钥。可以说掌握了SSH Key的生成和使用是Linux系统管理、DevOps工作流里绕不开的一项基本功。2. 生成SSH Key前的准备与环境检查2.1 确认Ubuntu系统里有没有装好OpenSSH客户端在开始生成密钥之前我先确认一下系统环境。Ubuntu桌面版通常自带OpenSSH客户端但你最好还是亲自检查一遍尤其是那些精简安装过后的系统。打开终端执行ssh -V如果能看到类似OpenSSH_9.6p1 Ubuntu-3ubuntu13.5, OpenSSL 3.0.13 30 Jan 2024这样的输出说明客户端已经装好了。如果提示command not found那就先安装一下sudo apt update sudo apt install openssh-client -y这里顺便提一句很多人会把“生成SSH Key”和“配置SSH服务端”搞混。生成密钥只需要客户端工具不需要装openssh-server。只有当你打算让别的机器能SSH登录到这台Ubuntu的时候才需要安装并启用服务端。如果你的需求只是从本机去连接别的服务器那么只装客户端就够了。2.2 检查是否已经有现成的SSH Key很多人一开始会犯一个错误不检查旧密钥直接生成新的结果把之前配置好的密钥覆盖了导致原本能登录的服务器全部失灵。我自己就干过这种事当时为了图省事连续按了几下回车等我反应过来的时候老的私钥已经被覆盖了GitHub上的配置也全部失效最后只能重新上传公钥白折腾了一晚上。所以生成之前先看看~/.ssh目录里有什么ls -la ~/.ssh如果没有这个目录说明你这台机器上还从来没有生成过密钥如果目录里有id_rsa、id_ed25519这类文件说明已经有密钥了。这时候你需要判断一下如果你记得私钥的密码而且这些密钥还在正常使用那就没必要重新生成。如果你不确定这些密钥是否安全或者早就忘了私钥密码那可以考虑生成一个新的并把旧密钥妥善备份后删除。如果你需要在同一台机器上管理多个账号比如两个GitHub账号那也不应该覆盖而是生成不同命名的密钥文件通过配置文件区分使用。2.3 确认当前的用户和目录权限SSH对目录权限非常敏感很多“莫名其妙”的报错其实都是权限问题。开始之前先确认一下当前登录用户和家目录。whoami echo $HOME正常情况下你的SSH密钥文件放在/home/你的用户名/.ssh/下面。如果当前用户是root那就是/root/.ssh/。这里有个原则要记牢.ssh目录的权限不能是777私钥文件的权限不能是644。私钥要是权限过宽SSH客户端会直接拒绝使用它。后面我在“常见问题”部分还会详细讲这块。3. ssh-keygen 完整实操从命令行到密钥文件3.1 最常用的生成命令与参数选择生成SSH Key的核心命令就是ssh-keygen它本身参数不多但每个参数都值得你花几分钟搞清楚。我最常用的生成方式是ssh-keygen -t ed25519 -C your_emailexample.com -f ~/.ssh/id_ed25519解释一下这几个参数的含义-t ed25519指定密钥类型。目前我强烈推荐使用Ed25519它的密钥长度短、生成速度快、安全性高OpenSSH从6.5版本开始就支持了。-C your_emailexample.com是添加一个注释通常写你的邮箱或者用途说明。这个注释会出现在公钥文件的末尾方便你以后辨认这把密钥是谁的、用来干嘛的。-f ~/.ssh/id_ed25519指定密钥文件的保存路径。如果不加这个参数它默认会生成在当前用户家目录的.ssh下面文件名是id_ed25519。如果出于兼容性考虑你必须要用RSA密钥来连接某些老旧的服务器或者设备那可以退一步用ssh-keygen -t rsa -b 4096 -C your_emailexample.com -f ~/.ssh/id_rsa注意这里-b 4096是关键它表示密钥长度是4096位。RSA密钥长度太短比如1024位已经不安全了市面上几乎所有要求严格的环境都会拒绝。但说实话只要是2014年之后更新的系统和设备基本上都支持Ed25519所以我的建议很直接默认用Ed25519碰到老设备再说。3.2 生成过程中的交互提示到底怎么回执行完上面的命令终端会有一系列交互提示。很多新手卡在这一步不知道该输入什么其实答案很简单。第一步它会问你要把密钥保存在哪里Generating public/private ed25519 key pair. Enter file in which to save the key (/home/user/.ssh/id_ed25519):如果你想用默认路径直接回车就行。如果你之前指定了-f参数这步就不会问或者直接显示你指定的路径。这里我不建议把密钥文件命名得太随意比如放在家目录下、叫a.key那样后面找起来很麻烦。规范的做法就是放在~/.ssh/下文件名能体现用途比如id_ed25519_github、id_ed25519_work。第二步它会让你设置私钥的密码passphraseEnter passphrase (empty for no passphrase): Enter same passphrase again:这里就要仔细想一想了。如果直接按两次回车私钥就不设密码以后用起来最方便但别人拿到你的私钥文件也能直接用。如果设置了密码每次使用私钥都要输入一次安全性更高但便利性下降。我的建议是个人电脑上开发用可以设一个简单的passphrase然后配合ssh-agent来记忆服务器上的自动化部署密钥通常不设passphrase否则重启后没法自动连接。这里没有绝对正确的选择只有适不适合你的使用场景。3.3 生成完成之后你应该看到哪些文件整个过程结束后到~/.ssh目录里看一眼ls -la ~/.ssh/你会看到生成的私钥和公钥两个文件。以Ed25519为例一个是id_ed25519这是私钥绝对不能泄露另一个是id_ed25519.pub这是公钥可以安全地分发。它们的关系就像钥匙和锁的配对应关系锁可以复制多把发给多台服务器但钥匙只有你自己有。公钥文件的内容是一行文本结构大概是ssh-ed25519 AAAA...一串很长的字符 your_emailexample.com前面是密钥类型中间是Base64编码的密钥本体最后是注释。我用cat ~/.ssh/id_ed25519.pub查看公钥内容时通常会顺手复制出来后面配置GitHub或者服务器的时候都要用。3.4 生成之后立刻检查私钥权限这是我在生产环境踩过坑后才养成的习惯。生成完密钥我第一件事不是急着去部署公钥而是先检查权限ls -l ~/.ssh/id_ed25519正常情况下私钥文件的权限应该是-rw-------也就是600。如果你看到的是-rw-r--r--甚至-rw-rw-rw-那么很多SSH服务器会直接拒绝使用这把密钥日志里会报“permissions too open”。如果权限不对手动改一下chmod 600 ~/.ssh/id_ed25519 chmod 700 ~/.ssh有不少人忽略了目录权限。.ssh目录本身的权限也必须是700或者750不能是777。如果目录对所有人可写SSH会认为这个目录不安全同样会拒绝加载你的私钥。4. 公钥部署免密登录的三种落地方式4.1 方式一ssh-copy-id命令一键部署生成了密钥下一步就是把公钥部署到目标服务器上。最简单直接的方式是用ssh-copy-id命令。假设你要登录的服务器IP是192.168.1.100用户名是ubuntu那命令就是ssh-copy-id -i ~/.ssh/id_ed25519.pub ubuntu192.168.1.100这条命令会先用密码登录到远程服务器然后把指定的公钥追加到远程用户的~/.ssh/authorized_keys文件里同时设置好相关目录和文件的权限。整个过程是自动完成的不会出现“公钥写进去了但权限不对”的情况。执行完之后你用密钥登录试试ssh ubuntu192.168.1.100如果没有意外已经可以免密登录了。用ssh-copy-id唯一的缺点是前提条件是你当前还能用密码登录目标服务器。如果你之前已经把密码登录关掉了或者目标服务器从来没有给你密码那就得用下面的方式。4.2 方式二手动复制公钥到服务器当你无法用密码登录、但又能通过某种方式往服务器上写入文件的时候手动复制公钥就成了唯一的选择。比如服务器是云厂商的网页控制台提供的你可以在控制台里编辑authorized_keys文件。手动部署的步骤如下。先在本地查看公钥内容cat ~/.ssh/id_ed25519.pub复制整行输出然后在服务器上执行mkdir -p ~/.ssh chmod 700 ~/.ssh echo 这里粘贴你复制的公钥内容 ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys这里有几个小细节要提醒你如果用echo 的方式注意是双引号不是单引号避免Shell对引号内容做奇怪的解析。authorized_keys里可以有多行公钥每行一把不会互相覆盖。所以追加和新建都行只要不搞乱原有内容。文件权限必须是600目录权限必须是700这是SSH的硬性要求少一个都会出问题。4.3 方式三通过GitHub等平台配置公钥还有一种场景不是登录服务器而是配置代码托管平台的SSH访问。以GitHub为例打开GitHub网页进入Settings→SSH and GPG keys→New SSH key把id_ed25519.pub的内容粘贴进去保存就完成了。配置好之后测试连接ssh -T gitgithub.com第一次连接时SSH会询问是否信任GitHub的指纹信息输入yes回车。如果看到类似Hi 你的用户名! Youve successfully authenticated, but GitHub does not provide shell access.的输出说明密钥已经生效。以后git push、git pull走HTTPS那套账号密码验证的时代就和你无关了全程SSH丝般顺滑。这里要注意的是同一台机器上同一个GitHub账号可以配置多把公钥比如公司电脑和家里电脑各配一把。但反过来同一把公钥最好不要同时加到两个不同的GitHub账号里GitHub检测到重复Key会直接报错“Key already in use”。如果你确实有多个GitHub账号那就要用到后面第六部分讲的多密钥管理方案。4.4 部署完成后务必验证登录链路无论用哪种方式部署公钥最后都要做一次完整的验证。我的习惯是先验证密钥登录能够成功再检查是否真的不再提示输入密码。ssh -v ubuntu192.168.1.100-v参数会输出详细的调试信息。如果最后的验证过程走向用的是publickey而没有任何password的交互提示说明公钥部署成功。如果还提示输入密码有几种可能公钥没进对用户的authorized_keys、权限不对、或者SSH服务端配置里关闭了公钥认证。5. 权限与安全老手也会踩的坑5.1 私钥泄露的严重性我在这个行业里见过不少“密钥泄露”导致的事故。有的人把私钥文件传到了聊天工具里有的人把私钥和代码一起提交到了Git仓库等反应过来的时候攻击者已经用他的密钥登录了云主机在里面挖矿、发垃圾邮件甚至植入了后门。要记住私钥就是你身份的终极凭证它的重要性不亚于银行卡密码。一旦私钥泄露正确的处理方式是立即使该密钥失效在所有相关的服务器和平台里删除对应的公钥然后生成一对新密钥重新部署。不要心存侥幸觉得“应该没人注意到”攻击者扫描和利用泄露密钥的速度远超你的想象。5.2 合理使用passphrase与ssh-agent前面提到过私钥可以设置passphrase。有人会觉得“设了密码不还是每次都要输吗好麻烦”。其实完全可以通过ssh-agent来解决这个体验问题。先用ssh-agent把私钥加入内存eval $(ssh-agent -s) ssh-add ~/.ssh/id_ed25519第一次执行ssh-add会让你输入私钥的passphrase输入一次之后只要ssh-agent进程还活着后面再用这把私钥连接服务器、推送代码都不需要再重复输入passphrase。这种方式既保证了私钥在静态存储时是加密的又不会牺牲日常使用的便利性是我目前最推荐的个人电脑配置。Ubuntu桌面版有时还会自动启动ssh-agent你可以用echo $SSH_AUTH_SOCK查看环境变量是否已经设置。如果输出了类似/run/user/1000/keyring/ssh的路径说明系统级的ssh-agent已经在运行了直接执行ssh-add就行。5.3 服务器端的安全加固思路公钥部署好后很多人的下一步想法是“既然密钥这么好那把密码登录关了吧”。这个想法没毛病但一定要谨慎操作。建议你做两步第一步先备份服务器的SSH配置文件sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak第二步编辑/etc/ssh/sshd_config找到并修改以下几个关键项PasswordAuthentication no PubkeyAuthentication yes PermitRootLogin prohibit-password改完之后先别急着断开当前连接而是新开一个终端窗口用密钥登录验证一次确认没问题再重启SSH服务sudo systemctl restart sshd我自己就见过有人改完配置、重启服务结果密钥登录其实一直没配置通最后只能通过云厂商的VNC控制台救场。所以这里再三强调配置变更前一定要确保有一条可靠的备用登录通道。5.4 定期轮换密钥与审计密钥不是配好就能一劳永逸的。从安全运营的角度看定期轮换密钥是一种好习惯。尤其是当有员工离职、设备丢失、或者怀疑密钥可能泄露时都应该立刻把相关公钥从服务器和平台中移除并重新生成。另外在服务器上定期检查~/.ssh/authorized_keys文件、在GitHub上审查已授权的Key列表也都是简单有效的审计手段。我一般会每个月花几分钟过一遍看看有没有自己不认识的公钥出现。如果发现异常第一时间删除并排查可能的入侵痕迹。6. 多密钥管理与日常使用技巧6.1 一台机器上管理多个SSH Key的场景很多人的实际需求不是只有一把密钥而是有多把一把用于GitHub个人号一把用于公司的GitLab还可能有一把专门用来登录某台生产服务器。这种情况下如果都叫id_ed25519系统里就乱套了。正确的做法是为每种用途单独生成密钥并赋予不同的文件名。比如ssh-keygen -t ed25519 -C personal-github -f ~/.ssh/id_ed25519_github ssh-keygen -t ed25519 -C work-gitlab -f ~/.ssh/id_ed25519_work ssh-keygen -t rsa -b 4096 -C legacy-server -f ~/.ssh/id_rsa_legacy这样在~/.ssh目录下每一对密钥都清晰可辨。我在项目里管理了多个客户的服务器每台服务器用独立的密钥文件一眼就能看出来哪把钥匙是开哪扇门的。6.2 通过config文件指定不同场景使用不同密钥生成了多把密钥之后还需要告诉SSH客户端什么场景用哪把密钥否则它会默认寻找id_ed25519或者id_rsa。解决办法是在~/.ssh/config文件里写配置。比如GitHub的配置Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github公司GitLab的配置Host gitlab.company.com HostName gitlab.company.com User git IdentityFile ~/.ssh/id_ed25519_work服务器的配置Host myserver HostName 192.168.1.100 User ubuntu Port 22 IdentityFile ~/.ssh/id_ed25519_server这里解释一下Host是你在命令行里输入的别名HostName是真实的域名或IPUser是登录用户名IdentityFile指定用哪把私钥。配置好之后你就可以直接ssh myserver登录不需要再敲完整的ubuntu192.168.1.100了。6.3 给config文件设置正确的权限~/.ssh/config文件本身也可能包含一些敏感信息比如内网地址、用户名等所以它的权限不能太宽松。我一般会设置成600chmod 600 ~/.ssh/config别小看这一步。如果config文件权限为644SSH客户端在某些严格配置下也会拒绝加载其中的配置。所有~/.ssh下的密钥文件和配置文件权限宁可紧一点不要太松。6.4 日常使用中的几个实用命令最后分享几个我日常一定会用到的快捷命令帮助你和密钥无缝配合。查看当前ssh-agent里加载了哪些密钥ssh-add -l删除agent里某个密钥ssh-add -d ~/.ssh/id_ed25519测试某个host的密钥认证是否正常而不实际执行远程命令ssh -T gitgithub.com连接服务器时手动指定私钥文件不依赖configssh -i ~/.ssh/id_ed25519_work ubuntu192.168.1.50这几个命令用熟了你在处理多台服务器、多个代码仓库的时候会从容很多。6.5 密钥备份的正确姿势密钥文件是没法“找回密码”的丢了就是丢了。私钥文件一旦丢失你在所有服务器和平台上的公钥配置就形同虚设只能全部重新生成、重新部署。所以备份很重要但备份的方式更关键。我的建议是不要把私钥文件以明文形式直接扔到网盘、聊天记录或者云笔记里。如果非要备份应该先用安全工具对私钥文件加密压缩或者直接把带passphrase的私钥文件备份到加密的存储介质里。密钥的密码强度也要保证不要用生日、手机号这种能猜出来的内容。我个人的做法是私钥除了放在电脑本地只会通过加密的密码管理器保存一份加密副本并开启两步验证。这样既照顾了安全性又留了后路。结尾文章写到这里关于Ubuntu系统里生成SSH Key的整个流程基本都过了一遍。我从最开始只会对着教程按回车到现在能根据场景选合适的密钥类型、处理多密钥共存、排查各种权限问题中间确实走了不少弯路。回头看我觉得最值钱的不是记住那一两条命令而是理解了密钥背后“公钥是锁、私钥是钥匙”的模型以及SSH为什么对权限那么较真。服务器上的那些权限限制本质上都是在保护你这把钥匙不被滥用。最后再分享一个小技巧吧无论你是在Ubuntu上还是其他Linux发行版上操作生成完密钥之后养成一个习惯——把公钥内容发出去之前先用ssh-keygen -lf ~/.ssh/id_ed25519.pub查看一下密钥指纹顺手记在笔记里。以后你如果怀疑哪台服务器配置错了密钥或者怀疑公钥被替换了对比一下指纹就能立刻定位问题。这个小细节我在排查环境异常的时候帮过我很多次希望能给你省点事。
做运维和开发的朋友应该都知道SSH Key这个东西几乎是每天都要打交道的。不管你是要登录云服务器、往GitHub上推代码还是管理公司内网的一批Linux机器只要涉及SSH远程连接就绕不开密钥认证。我在Ubuntu上折腾过不少次生成SSH Key的操作从最开始跟着教程一步一步敲命令到后来理解了整个原理、踩过各种坑中间其实有不少值得记录的东西。这篇内容就围绕“Ubuntu系统中生成SSH Key”这条主线展开把从生成、部署到排错、多密钥管理的完整过程都过一遍。不管你是刚接触Linux的新手还是已经用过一段时间但想搞清楚背后逻辑的进阶用户都能从里面找到能直接拿去用的东西。我会尽量把每一步为什么这么做讲明白而不是只丢给你一串命令就完事。1. SSH Key到底是什么为什么值得换掉密码登录1.1 先搞清楚SSH Key的工作原理很多人第一次接触SSH Key的时候听说了“公钥”“私钥”这两个词但并不知道它们之间到底是什么关系。打个比方你可以把公钥想象成一把锁把私钥想象成唯一的钥匙。你可以把锁公钥随意分发出去放到你想要登录的服务器上而钥匙私钥必须牢牢留存在你自己的电脑里绝对不能给别人。当你发起SSH连接的时候服务器会拿着一把“挑战”来考验你它会用你事先放好的那把锁公钥生成一个只有钥匙私钥才能正确回答的问题。你的客户端用私钥回答完毕服务器验证通过连接就建立了。整个过程里私钥的内容不会直接传输到网络上传输的只是一个经过签名的验证结果所以安全性比密码登录高出一个量级。理解了这一点你就能明白为什么大家都推荐用SSH Key而不是密码登录了。密码是静态的一旦在网络传输过程中被截获或者因为撞库、弱口令被爆破别人就能直接登录你的机器而密钥是一套动态的挑战-应答机制即使网络抓包也抓不到私钥本身安全性完全不一样。1.2 密码登录的痛点在哪里我自己在真实环境里见过太多因为密码登录出事的例子。最常见的就是服务器暴露在公网上被自动化脚本不断地尝试爆破。那些脚本会从密码字典里挨个试比如admin、123456、password一天能撞几万次。就算你设了一个还不错的密码防住了简单的爆破也架不住某些人安全意识淡薄把密码写到代码仓库里、贴到聊天记录里一次泄露全线崩溃。另外密码登录还有一个很烦人的问题每次连接都要输一次密码。你要是频繁操作多台服务器一天下来手都快敲酸了而且密码输多了难免会有输错的时候。SSH Key配置好之后直接一条命令就登录上去不用输任何东西那种顺滑感用一次就回不去了。1.3 什么时候必须用SSH Key有些场景下SSH Key不只是“推荐”而是“必须”。比如GitHub、GitLab这些代码托管平台早就关闭了用账号密码进行Git操作的方式想往远程仓库推送代码只能走SSH Key或者Personal Access Token。还有企业内部的一些跳板机通常也强制要求密钥认证普通用户根本没有用密码登录的权限。我做项目部署的时候也深有体会CI/CD流水线里构建服务器要拉取私有仓库代码、要登录生产环境执行发布脚本这些场景没法人工输入密码必须预先配好密钥。可以说掌握了SSH Key的生成和使用是Linux系统管理、DevOps工作流里绕不开的一项基本功。2. 生成SSH Key前的准备与环境检查2.1 确认Ubuntu系统里有没有装好OpenSSH客户端在开始生成密钥之前我先确认一下系统环境。Ubuntu桌面版通常自带OpenSSH客户端但你最好还是亲自检查一遍尤其是那些精简安装过后的系统。打开终端执行ssh -V如果能看到类似OpenSSH_9.6p1 Ubuntu-3ubuntu13.5, OpenSSL 3.0.13 30 Jan 2024这样的输出说明客户端已经装好了。如果提示command not found那就先安装一下sudo apt update sudo apt install openssh-client -y这里顺便提一句很多人会把“生成SSH Key”和“配置SSH服务端”搞混。生成密钥只需要客户端工具不需要装openssh-server。只有当你打算让别的机器能SSH登录到这台Ubuntu的时候才需要安装并启用服务端。如果你的需求只是从本机去连接别的服务器那么只装客户端就够了。2.2 检查是否已经有现成的SSH Key很多人一开始会犯一个错误不检查旧密钥直接生成新的结果把之前配置好的密钥覆盖了导致原本能登录的服务器全部失灵。我自己就干过这种事当时为了图省事连续按了几下回车等我反应过来的时候老的私钥已经被覆盖了GitHub上的配置也全部失效最后只能重新上传公钥白折腾了一晚上。所以生成之前先看看~/.ssh目录里有什么ls -la ~/.ssh如果没有这个目录说明你这台机器上还从来没有生成过密钥如果目录里有id_rsa、id_ed25519这类文件说明已经有密钥了。这时候你需要判断一下如果你记得私钥的密码而且这些密钥还在正常使用那就没必要重新生成。如果你不确定这些密钥是否安全或者早就忘了私钥密码那可以考虑生成一个新的并把旧密钥妥善备份后删除。如果你需要在同一台机器上管理多个账号比如两个GitHub账号那也不应该覆盖而是生成不同命名的密钥文件通过配置文件区分使用。2.3 确认当前的用户和目录权限SSH对目录权限非常敏感很多“莫名其妙”的报错其实都是权限问题。开始之前先确认一下当前登录用户和家目录。whoami echo $HOME正常情况下你的SSH密钥文件放在/home/你的用户名/.ssh/下面。如果当前用户是root那就是/root/.ssh/。这里有个原则要记牢.ssh目录的权限不能是777私钥文件的权限不能是644。私钥要是权限过宽SSH客户端会直接拒绝使用它。后面我在“常见问题”部分还会详细讲这块。3. ssh-keygen 完整实操从命令行到密钥文件3.1 最常用的生成命令与参数选择生成SSH Key的核心命令就是ssh-keygen它本身参数不多但每个参数都值得你花几分钟搞清楚。我最常用的生成方式是ssh-keygen -t ed25519 -C your_emailexample.com -f ~/.ssh/id_ed25519解释一下这几个参数的含义-t ed25519指定密钥类型。目前我强烈推荐使用Ed25519它的密钥长度短、生成速度快、安全性高OpenSSH从6.5版本开始就支持了。-C your_emailexample.com是添加一个注释通常写你的邮箱或者用途说明。这个注释会出现在公钥文件的末尾方便你以后辨认这把密钥是谁的、用来干嘛的。-f ~/.ssh/id_ed25519指定密钥文件的保存路径。如果不加这个参数它默认会生成在当前用户家目录的.ssh下面文件名是id_ed25519。如果出于兼容性考虑你必须要用RSA密钥来连接某些老旧的服务器或者设备那可以退一步用ssh-keygen -t rsa -b 4096 -C your_emailexample.com -f ~/.ssh/id_rsa注意这里-b 4096是关键它表示密钥长度是4096位。RSA密钥长度太短比如1024位已经不安全了市面上几乎所有要求严格的环境都会拒绝。但说实话只要是2014年之后更新的系统和设备基本上都支持Ed25519所以我的建议很直接默认用Ed25519碰到老设备再说。3.2 生成过程中的交互提示到底怎么回执行完上面的命令终端会有一系列交互提示。很多新手卡在这一步不知道该输入什么其实答案很简单。第一步它会问你要把密钥保存在哪里Generating public/private ed25519 key pair. Enter file in which to save the key (/home/user/.ssh/id_ed25519):如果你想用默认路径直接回车就行。如果你之前指定了-f参数这步就不会问或者直接显示你指定的路径。这里我不建议把密钥文件命名得太随意比如放在家目录下、叫a.key那样后面找起来很麻烦。规范的做法就是放在~/.ssh/下文件名能体现用途比如id_ed25519_github、id_ed25519_work。第二步它会让你设置私钥的密码passphraseEnter passphrase (empty for no passphrase): Enter same passphrase again:这里就要仔细想一想了。如果直接按两次回车私钥就不设密码以后用起来最方便但别人拿到你的私钥文件也能直接用。如果设置了密码每次使用私钥都要输入一次安全性更高但便利性下降。我的建议是个人电脑上开发用可以设一个简单的passphrase然后配合ssh-agent来记忆服务器上的自动化部署密钥通常不设passphrase否则重启后没法自动连接。这里没有绝对正确的选择只有适不适合你的使用场景。3.3 生成完成之后你应该看到哪些文件整个过程结束后到~/.ssh目录里看一眼ls -la ~/.ssh/你会看到生成的私钥和公钥两个文件。以Ed25519为例一个是id_ed25519这是私钥绝对不能泄露另一个是id_ed25519.pub这是公钥可以安全地分发。它们的关系就像钥匙和锁的配对应关系锁可以复制多把发给多台服务器但钥匙只有你自己有。公钥文件的内容是一行文本结构大概是ssh-ed25519 AAAA...一串很长的字符 your_emailexample.com前面是密钥类型中间是Base64编码的密钥本体最后是注释。我用cat ~/.ssh/id_ed25519.pub查看公钥内容时通常会顺手复制出来后面配置GitHub或者服务器的时候都要用。3.4 生成之后立刻检查私钥权限这是我在生产环境踩过坑后才养成的习惯。生成完密钥我第一件事不是急着去部署公钥而是先检查权限ls -l ~/.ssh/id_ed25519正常情况下私钥文件的权限应该是-rw-------也就是600。如果你看到的是-rw-r--r--甚至-rw-rw-rw-那么很多SSH服务器会直接拒绝使用这把密钥日志里会报“permissions too open”。如果权限不对手动改一下chmod 600 ~/.ssh/id_ed25519 chmod 700 ~/.ssh有不少人忽略了目录权限。.ssh目录本身的权限也必须是700或者750不能是777。如果目录对所有人可写SSH会认为这个目录不安全同样会拒绝加载你的私钥。4. 公钥部署免密登录的三种落地方式4.1 方式一ssh-copy-id命令一键部署生成了密钥下一步就是把公钥部署到目标服务器上。最简单直接的方式是用ssh-copy-id命令。假设你要登录的服务器IP是192.168.1.100用户名是ubuntu那命令就是ssh-copy-id -i ~/.ssh/id_ed25519.pub ubuntu192.168.1.100这条命令会先用密码登录到远程服务器然后把指定的公钥追加到远程用户的~/.ssh/authorized_keys文件里同时设置好相关目录和文件的权限。整个过程是自动完成的不会出现“公钥写进去了但权限不对”的情况。执行完之后你用密钥登录试试ssh ubuntu192.168.1.100如果没有意外已经可以免密登录了。用ssh-copy-id唯一的缺点是前提条件是你当前还能用密码登录目标服务器。如果你之前已经把密码登录关掉了或者目标服务器从来没有给你密码那就得用下面的方式。4.2 方式二手动复制公钥到服务器当你无法用密码登录、但又能通过某种方式往服务器上写入文件的时候手动复制公钥就成了唯一的选择。比如服务器是云厂商的网页控制台提供的你可以在控制台里编辑authorized_keys文件。手动部署的步骤如下。先在本地查看公钥内容cat ~/.ssh/id_ed25519.pub复制整行输出然后在服务器上执行mkdir -p ~/.ssh chmod 700 ~/.ssh echo 这里粘贴你复制的公钥内容 ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys这里有几个小细节要提醒你如果用echo 的方式注意是双引号不是单引号避免Shell对引号内容做奇怪的解析。authorized_keys里可以有多行公钥每行一把不会互相覆盖。所以追加和新建都行只要不搞乱原有内容。文件权限必须是600目录权限必须是700这是SSH的硬性要求少一个都会出问题。4.3 方式三通过GitHub等平台配置公钥还有一种场景不是登录服务器而是配置代码托管平台的SSH访问。以GitHub为例打开GitHub网页进入Settings→SSH and GPG keys→New SSH key把id_ed25519.pub的内容粘贴进去保存就完成了。配置好之后测试连接ssh -T gitgithub.com第一次连接时SSH会询问是否信任GitHub的指纹信息输入yes回车。如果看到类似Hi 你的用户名! Youve successfully authenticated, but GitHub does not provide shell access.的输出说明密钥已经生效。以后git push、git pull走HTTPS那套账号密码验证的时代就和你无关了全程SSH丝般顺滑。这里要注意的是同一台机器上同一个GitHub账号可以配置多把公钥比如公司电脑和家里电脑各配一把。但反过来同一把公钥最好不要同时加到两个不同的GitHub账号里GitHub检测到重复Key会直接报错“Key already in use”。如果你确实有多个GitHub账号那就要用到后面第六部分讲的多密钥管理方案。4.4 部署完成后务必验证登录链路无论用哪种方式部署公钥最后都要做一次完整的验证。我的习惯是先验证密钥登录能够成功再检查是否真的不再提示输入密码。ssh -v ubuntu192.168.1.100-v参数会输出详细的调试信息。如果最后的验证过程走向用的是publickey而没有任何password的交互提示说明公钥部署成功。如果还提示输入密码有几种可能公钥没进对用户的authorized_keys、权限不对、或者SSH服务端配置里关闭了公钥认证。5. 权限与安全老手也会踩的坑5.1 私钥泄露的严重性我在这个行业里见过不少“密钥泄露”导致的事故。有的人把私钥文件传到了聊天工具里有的人把私钥和代码一起提交到了Git仓库等反应过来的时候攻击者已经用他的密钥登录了云主机在里面挖矿、发垃圾邮件甚至植入了后门。要记住私钥就是你身份的终极凭证它的重要性不亚于银行卡密码。一旦私钥泄露正确的处理方式是立即使该密钥失效在所有相关的服务器和平台里删除对应的公钥然后生成一对新密钥重新部署。不要心存侥幸觉得“应该没人注意到”攻击者扫描和利用泄露密钥的速度远超你的想象。5.2 合理使用passphrase与ssh-agent前面提到过私钥可以设置passphrase。有人会觉得“设了密码不还是每次都要输吗好麻烦”。其实完全可以通过ssh-agent来解决这个体验问题。先用ssh-agent把私钥加入内存eval $(ssh-agent -s) ssh-add ~/.ssh/id_ed25519第一次执行ssh-add会让你输入私钥的passphrase输入一次之后只要ssh-agent进程还活着后面再用这把私钥连接服务器、推送代码都不需要再重复输入passphrase。这种方式既保证了私钥在静态存储时是加密的又不会牺牲日常使用的便利性是我目前最推荐的个人电脑配置。Ubuntu桌面版有时还会自动启动ssh-agent你可以用echo $SSH_AUTH_SOCK查看环境变量是否已经设置。如果输出了类似/run/user/1000/keyring/ssh的路径说明系统级的ssh-agent已经在运行了直接执行ssh-add就行。5.3 服务器端的安全加固思路公钥部署好后很多人的下一步想法是“既然密钥这么好那把密码登录关了吧”。这个想法没毛病但一定要谨慎操作。建议你做两步第一步先备份服务器的SSH配置文件sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak第二步编辑/etc/ssh/sshd_config找到并修改以下几个关键项PasswordAuthentication no PubkeyAuthentication yes PermitRootLogin prohibit-password改完之后先别急着断开当前连接而是新开一个终端窗口用密钥登录验证一次确认没问题再重启SSH服务sudo systemctl restart sshd我自己就见过有人改完配置、重启服务结果密钥登录其实一直没配置通最后只能通过云厂商的VNC控制台救场。所以这里再三强调配置变更前一定要确保有一条可靠的备用登录通道。5.4 定期轮换密钥与审计密钥不是配好就能一劳永逸的。从安全运营的角度看定期轮换密钥是一种好习惯。尤其是当有员工离职、设备丢失、或者怀疑密钥可能泄露时都应该立刻把相关公钥从服务器和平台中移除并重新生成。另外在服务器上定期检查~/.ssh/authorized_keys文件、在GitHub上审查已授权的Key列表也都是简单有效的审计手段。我一般会每个月花几分钟过一遍看看有没有自己不认识的公钥出现。如果发现异常第一时间删除并排查可能的入侵痕迹。6. 多密钥管理与日常使用技巧6.1 一台机器上管理多个SSH Key的场景很多人的实际需求不是只有一把密钥而是有多把一把用于GitHub个人号一把用于公司的GitLab还可能有一把专门用来登录某台生产服务器。这种情况下如果都叫id_ed25519系统里就乱套了。正确的做法是为每种用途单独生成密钥并赋予不同的文件名。比如ssh-keygen -t ed25519 -C personal-github -f ~/.ssh/id_ed25519_github ssh-keygen -t ed25519 -C work-gitlab -f ~/.ssh/id_ed25519_work ssh-keygen -t rsa -b 4096 -C legacy-server -f ~/.ssh/id_rsa_legacy这样在~/.ssh目录下每一对密钥都清晰可辨。我在项目里管理了多个客户的服务器每台服务器用独立的密钥文件一眼就能看出来哪把钥匙是开哪扇门的。6.2 通过config文件指定不同场景使用不同密钥生成了多把密钥之后还需要告诉SSH客户端什么场景用哪把密钥否则它会默认寻找id_ed25519或者id_rsa。解决办法是在~/.ssh/config文件里写配置。比如GitHub的配置Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github公司GitLab的配置Host gitlab.company.com HostName gitlab.company.com User git IdentityFile ~/.ssh/id_ed25519_work服务器的配置Host myserver HostName 192.168.1.100 User ubuntu Port 22 IdentityFile ~/.ssh/id_ed25519_server这里解释一下Host是你在命令行里输入的别名HostName是真实的域名或IPUser是登录用户名IdentityFile指定用哪把私钥。配置好之后你就可以直接ssh myserver登录不需要再敲完整的ubuntu192.168.1.100了。6.3 给config文件设置正确的权限~/.ssh/config文件本身也可能包含一些敏感信息比如内网地址、用户名等所以它的权限不能太宽松。我一般会设置成600chmod 600 ~/.ssh/config别小看这一步。如果config文件权限为644SSH客户端在某些严格配置下也会拒绝加载其中的配置。所有~/.ssh下的密钥文件和配置文件权限宁可紧一点不要太松。6.4 日常使用中的几个实用命令最后分享几个我日常一定会用到的快捷命令帮助你和密钥无缝配合。查看当前ssh-agent里加载了哪些密钥ssh-add -l删除agent里某个密钥ssh-add -d ~/.ssh/id_ed25519测试某个host的密钥认证是否正常而不实际执行远程命令ssh -T gitgithub.com连接服务器时手动指定私钥文件不依赖configssh -i ~/.ssh/id_ed25519_work ubuntu192.168.1.50这几个命令用熟了你在处理多台服务器、多个代码仓库的时候会从容很多。6.5 密钥备份的正确姿势密钥文件是没法“找回密码”的丢了就是丢了。私钥文件一旦丢失你在所有服务器和平台上的公钥配置就形同虚设只能全部重新生成、重新部署。所以备份很重要但备份的方式更关键。我的建议是不要把私钥文件以明文形式直接扔到网盘、聊天记录或者云笔记里。如果非要备份应该先用安全工具对私钥文件加密压缩或者直接把带passphrase的私钥文件备份到加密的存储介质里。密钥的密码强度也要保证不要用生日、手机号这种能猜出来的内容。我个人的做法是私钥除了放在电脑本地只会通过加密的密码管理器保存一份加密副本并开启两步验证。这样既照顾了安全性又留了后路。结尾文章写到这里关于Ubuntu系统里生成SSH Key的整个流程基本都过了一遍。我从最开始只会对着教程按回车到现在能根据场景选合适的密钥类型、处理多密钥共存、排查各种权限问题中间确实走了不少弯路。回头看我觉得最值钱的不是记住那一两条命令而是理解了密钥背后“公钥是锁、私钥是钥匙”的模型以及SSH为什么对权限那么较真。服务器上的那些权限限制本质上都是在保护你这把钥匙不被滥用。最后再分享一个小技巧吧无论你是在Ubuntu上还是其他Linux发行版上操作生成完密钥之后养成一个习惯——把公钥内容发出去之前先用ssh-keygen -lf ~/.ssh/id_ed25519.pub查看一下密钥指纹顺手记在笔记里。以后你如果怀疑哪台服务器配置错了密钥或者怀疑公钥被替换了对比一下指纹就能立刻定位问题。这个小细节我在排查环境异常的时候帮过我很多次希望能给你省点事。
