★ FEATURED ARTICLE 你有没有过这种经历新配置的一台服务器登录命令长得快要专门存个便签——ssh root123.456.78.90 -p 22022每次还得盯着屏幕敲密码、等指纹确认、再敲一次密码。一天下来反复登录三五台机器光是机械操作就能耗掉十几分钟稍不留神还会输错字母重新来。今天这篇不是讲什么深奥理论就是把一套我用了很多年的方案完整拆给你SSH Key 免密 SSH 配置文件~/.ssh/config最终效果就是你敲一个自定义别名比如ssh lab、ssh prod直接进去不用密码、不用记 IP、不用记端口。写这篇的初衷是很多朋友用 SSH 还是停留在命令 密码的原始阶段偶尔遇到认证失败、VS Code 连不上、批量登录太慢这类问题就要上网翻半天。读完这篇你会明白每一个配置项为什么存在、卡住时怎么定位以及怎么把这一套扩展到几十台机器的运维场景。1. 为什么要把 SSH 登录压缩成一行命令先算一笔时间账。假设你手里有 5 台服务器每天每台平均登录 2 次每次从打开终端到进入 shell 大约耗时 30 秒到 1 分钟——这还不算你翻笔记找 IP、记错端口之后反复试错的时间。一天下来登录这个动作本身就要花掉 5 到 10 分钟。听起来不多但一个月就是两三个小时一年就是整整两三天。而且这种纯机械操作恰恰是出错的温床IP 记混、端口记错、密码过期、小键盘没开数字键……每一条我都踩过。1.1 我那些登录服务器的隐形成本更大的成本不在时间而在打断感。我写代码或者排查问题的时候思路正在关键节点上结果要登录一台机器得先回忆 IP、输入一长串用户名加端口然后等待密码提示、再输密码。这一通操作走完大脑要重新切换回刚才我在想什么的状态至少损失几分钟的专注力。后来我把常用机器全部收进~/.ssh/config登录命令变成ssh web、ssh db、ssh bastion这种短单词配合 SSH Key 免密真正做到了想登哪台就登哪台一秒钟进入状态。这不是锦上添花是实打实提升日常开发效率的操作。1.2 SSH Key 和配置文件各自的角色这套方案里两个东西分工完全不同但缺一不可。SSH Key 解决的是身份验证。你不再每次输入密码而是用一对密钥来证明你是你。客户端持有私钥服务器端存放公钥登录时服务器用公钥验证你的私钥签名。私钥本身可以设置口令passphrase所以免密不等于裸奔后面我会细说。SSH 配置文件解决的是连接参数。服务器地址、端口、用户名、使用的密钥文件、连接超时时间、跳板机设置这些全部能写进~/.ssh/config。这样ssh myserver这种短命令背后自动解析出一整套完整的连接信息。一句话总结钥匙管证明身份配置管走哪扇门、找谁。一个解决认证一个解决寻址组合起来就是你看到的一行命令登录。2. 生成并部署 SSH Key从原理到实操我在不少团队里见过这样的场景老员工给新同事发服务器账号直接甩一串密码让大家用密码登录。密码方式不是不能用但只要机器一多、人一多密码泄露、弱口令、改密码后所有人重新同步这些问题就会轮番上阵。相比之下SSH Key 的部署和维护成本低得多。2.1 密钥对是怎么工作的用人话解释公钥相当于一把锁私钥相当于开锁的钥匙。你把锁公钥挂到服务器的门板上自己留好钥匙私钥。登录的时候客户端出示私钥签名服务器用手里的公钥验证签名是否匹配。验过了门就开。这里有个容易误解的点公钥是可以公开的它就算被任何人看到也没关系——锁挂在门外本来就是让人看的真正不能泄露的是私钥。所以你在服务器上存放的是authorized_keys把公钥内容一行行写进去而私钥必须留在自己的电脑里权限隐患是另一个大坑稍后单独说。2.2 生成密钥时的算法选择和参数细节生成密钥这一步很多教程直接让输ssh-keygen然后一路回车但这里有几个细节值得停下来想清楚。ssh-keygen -t ed25519 -C your_emailexample.com我推荐优先使用Ed25519算法。原因很直接密钥更短、生成更快、安全性更高而且对于现代 OpenSSH 客户端和服务器来说兼容性已经很成熟。如果你要登录的机器是那种年久失修的旧系统OpenSSH 版本过低不认 Ed25519再退而求其次用 RSAssh-keygen -t rsa -b 4096 -C your_emailexample.comRSA 的话务必指定-b 4096低于 2048 的强度现在看基本属于裸奔。-C参数就是给密钥加个备注强烈建议写上这样以后你管理几十个公钥时能一眼看出这是谁的、哪台机器用的。回车之后系统会问你要不要把私钥保存在默认位置~/.ssh/id_ed25519建议直接默认。然后会提示设置 passphrase口令短语这一项很多人直接回车跳过。我个人的建议是本地机器上可以设置一个 passphrase但配合 ssh-agent 使用这样既保证私钥被加密存放又不用每次登录都输一遍口令。具体来说ssh-keygen时设置 passphrase然后执行ssh-add ~/.ssh/id_ed25519输入一次 passphrase 后私钥就缓存在 ssh-agent 进程里后续ssh myserver直接免密进入。新开终端如果失效了重新ssh-add一次就行。注意如果完全不要 passphrase私钥裸躺在磁盘上一旦电脑被人拿走对方拿着私钥就能畅通无阻地登录你所有服务器。这个取舍自己做但我给的方案是设 passphrase ssh-agent兼顾安全和便利。2.3 三种把公钥部署到服务器的方法生成完密钥接下来要把公钥内容放到服务器上。我常用的有三种方式从省事到原始看你的环境选。方式一ssh-copy-id最推荐ssh-copy-id -i ~/.ssh/id_ed25519.pub useryour-server-ip它会自动把公钥追加到服务器~/.ssh/authorized_keys文件里还会顺手处理目录权限。第一次执行会要求输入密码之后就再也不用输了。方式二手动追加适合没有 ssh-copy-id 的机器cat ~/.ssh/id_ed25519.pub | ssh useryour-server-ip mkdir -p ~/.ssh chmod 700 ~/.ssh cat ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys这条命令做的事拆开看就是在服务器上建好~/.ssh目录、把目录权限设为 700、把公钥追加进authorized_keys、把文件权限设为 600。这些权限设置不是洁癖是 OpenSSH 的安全检查机制下面会单独讲。方式三批量部署脚本当你手里有十几台机器、每台都得加同一把公钥时一个个手动跑不现实。可以写个简单的循环for host in 192.168.1.10 192.168.1.11 192.168.1.12; do ssh-copy-id -i ~/.ssh/id_ed25519.pub root$host done第一次执行会反复问你密码配合 sshpass 之类的工具可以自动化但这属于另一篇的话题。至少循环脚本帮你省掉了重复找 IP 的时间。前提是所有机器的账号密码你都有权限操作别越权。2.4 权限问题90% 的认证失败都出在这里这个必须单独写一节。SSH Key 部署完成之后最常遇到的问题就是明明公钥放进去了还是提示 Permission denied (publickey)。绝大多数情况下不是公钥内容不对而是服务器或本地的文件权限不符合 OpenSSH 的严格检查要求。服务端要检查的权限路径要求权限说明用户家目录~不能带 group/other 写权限通常 755 或 700必须检查~/.ssh目录700必须检查~/.ssh/authorized_keys文件600必须检查客户端这边私钥文件权限要求也比较严格通常~/.ssh/id_ed25519必须设为 600不能有 group/other 的任何权限。排查这类问题我一般直接在服务器上执行ls -la ~ | grep .ssh ls -la ~/.ssh看到权限不对顺手修正chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys还有一个容易被忽视的点如果你用 root 登录/root 目录本身权限也要求不能对 group/other 开放写权限。有次我遇到怎么加密钥都登录不上的怪事最后发现是/root目录权限被某个脚本改成了 777系统直接拒绝信任所有公钥。这种时候排查思路要跳出.ssh目录本身往上多看一层。3. ssh config 配置文件从别名到跳板机的完整玩法密钥搞定了登录还需要输ssh rootip -p port依旧不满足一行命令的目标。真正把命令缩短到单词级别靠的是 SSH 配置文件。3.1 配置文件的位置、格式和生效逻辑SSH 配置分全局和用户两级。全局配置文件在/etc/ssh/ssh_config管所有用户和所有连接用户级配置文件在~/.ssh/config只管你自己。一般来说个人使用只需要改用户级配置不用动全局文件。配置文件的生效逻辑是自上而下第一个匹配到的参数生效每个Host段落是一套独立的连接配置。需要注意这个文件不需要重启任何服务改完保存新开的 SSH 连接立即生效。3.2 一个常用条目拆解下面是我给一台测试机配置的典型写法Host lab HostName 192.168.1.50 Port 2222 User ubuntu IdentityFile ~/.ssh/id_ed25519 ServerAliveInterval 60逐行解释一下Host lab这是你缩略词的别名就是之后在终端里敲的ssh lab。HostName 192.168.1.50真实 IP 或域名。Port 2222SSH 服务端口。很多机器为了安全不用默认 22写在这里就不必每次-p了。User ubuntu登录用户名。IdentityFile ~/.ssh/id_ed25519指定用哪把私钥。多个密钥场景下这个字段很关键。ServerAliveInterval 60每 60 秒发一个心跳包防止长时间没操作被服务器断开连接。这个参数在连跳板机、连云服务器时特别实用。配置保存后终端里直接敲ssh lab你的 SSH 客户端会自动按照配置去连192.168.1.50:2222用ubuntu用户和指定私钥完成登录。一行命令不需要记任何东西。这里要提一个细节如果配置了多个Host条目写的时候不要给它们整出重叠的匹配范围。比如Host *这种通配符段落通常放文件最后用来写所有连接都适用的默认参数。3.3 跳板机与内网机器ProxyJump 与配置模板工作里最常见的一个场景是办公网不能直连生产内网要先登录一台跳板机堡垒机再从跳板机跳到目标机器。这个操作用 SSH 配置文件可以做到一条命令直达。Host bastion HostName 203.0.113.10 User admin IdentityFile ~/.ssh/id_ed25519 ServerAliveInterval 60 Host internal HostName 10.0.0.5 User root ProxyJump bastion IdentityFile ~/.ssh/id_ed25519关键就是这个ProxyJump bastion。它的含义是当我要连internal这台机器时先经过bastion这台已配置的主机进行跳转。配置完成后你在本地终端敲ssh internalSSH 会自动先连跳板机再从跳板机连到内网目标。整个过程看起来就像直接登录内网机器。如果跳板机本身用的端口、用户比较特殊ProxyJump后面还可以写更完整的参数比如ProxyJump admin203.0.113.10:2200。另外老版本 OpenSSH 里用的是ProxyCommand写法是ProxyCommand ssh -W %h:%p bastion我个人更喜欢新版简洁的ProxyJump前提是你的 OpenSSH 版本支持7.3 以上普遍没问题。3.4 多密钥管理和通配符批量配置当你的机器分属多个环境、使用不同的密钥对时IdentityFile字段就是多密钥场景的核心。举个例子Host work-* User dev IdentityFile ~/.ssh/work_key Host personal-* User me IdentityFile ~/.ssh/personal_key这里用到了通配符。Host work-*匹配所有以work-开头的别名比如work-api、work-dbHost personal-*匹配个人用途的机器。这样你不需要给每台机器重复写用户名和密钥路径只需要在每个具体条目里写上HostName和Port就行。有一个我很喜欢的做法是再创建一个~/.ssh/config.d/目录按环境拆分配置文件然后在主配置里统一引入Include ~/.ssh/config.d/*比如config.d/production.conf放生产环境、config.d/staging.conf放预发环境。机器多了以后这种按环境拆文件的组织方式会让维护变得清晰很多。OpenSSH 7.3 以上支持Include指令老版本请先确认版本。4. 验证效果与常见报错排查配置写完之后别急着开心先做个系统的验证。我自己每次配完新机器都会走一遍完整的测试确保一行命令并非纸上谈兵。4.1 配置后的一行命令登录效果打开终端输入ssh lab如果一切正常你应该直接进入服务器 shell不需要输密码、不需要确认指纹。第一次连接时 SSH 会问你是否信任这台主机的 host key输入yes确认后会把它写进~/.ssh/known_hosts以后不再询问。如果你在生成密钥时设置了 passphrase 且当前没有加载到 ssh-agent这里会先要求输入一次私钥口令。这是正常现象不代表配置失败。4.2 用 ssh -v 逐行读登录过程出了问题第一件事就是开调试模式ssh -v lab想要更详细的信息可以加-vvv。调试输出里我会优先看几行关键信息debug1: Reading configuration data /home/you/.ssh/config确认配置文件被读取了。debug1: Offering public key: ~/.ssh/id_ed25519确认客户端在尝试提供这把私钥。debug1: Server accepts key: ~/.ssh/id_ed25519确认服务器接受了公钥验证。如果在Offering public key之后就断了或者一直提示Permission denied那问题集中在密钥本身或服务器端授权如果根本没走到提供密钥这一步那问题在配置文件的参数端口、用户名、HostName或者网络连通性。另外提一个排查技巧手动加-i指定密钥进行测试可以排除配置文件中的 IdentityFile 写错路径的情况。比如ssh -i ~/.ssh/id_ed25519 -p 2222 ubuntu192.168.1.50这条能登录而ssh lab不能那你的问题一定出在配置文件的字段拼写或者参数覆盖上。4.3 常见报错权限拒绝、认证失败、known_hosts 冲突我把高频遇到的现象和对应的定位方向整理成一张表方便你对照排查报错现象大概率原因排查路径Permission denied (publickey)密钥未授权、权限不对、用户不对检查 authorized_keys、密钥文件权限、Config 里 User 字段Connection refused端口错误或服务未启动检查 Port 字段、服务器systemctl status sshdWARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!服务器系统重装导致 host key 变化检查 known_hosts 对应条目确认是合法变更后清理旧条目Too many authentication failures客户端同时提供了太多密钥该主机条目里用IdentitiesOnly yes限制只使用指定密钥Bad owner or permissions本地私钥权限过大chmod 600 ~/.ssh/id_ed25519其中IdentitiesOnly yes是我经常建议加上的一行Host lab HostName 192.168.1.50 User ubuntu IdentityFile ~/.ssh/id_ed25519 IdentitiesOnly yes它告诉 SSH 客户端连接这台机器时只尝试配置里指定的这把密钥别去逐个尝试 ssh-agent 里缓存的其它密钥。这样既避免和身份验证计数限制撞上也能防止你笔记本里存的一堆密钥被服务器挨个试探。4.4 VS Code Remote-SSH 连不上的排查思路很多前端和全栈开发现在都用 VS Code 的 Remote-SSH 插件做远程开发。这个场景下插件本质上调用的还是你本机的ssh命令和配置文件所以上面讲的排查思路全都适用。不过它有一个特有的坑VS Code 会在远程主机的~/.vscode-server里安装服务端组件如果这个目录的权限或者磁盘空间出问题会表现为连接上去了但又马上断开一直卡在下载 VS Code Server。这时候我的排查步骤是先用终端手动ssh lab登录确认基本的 SSH 链路没问题。登录成功后查看远程主机~/.vscode-server目录是否存在。如果目录残留乱象直接在服务器上删除这个目录后重连rm -rf ~/.vscode-serverVS Code 下次连接会自动重建。另外一个连接 VS Code 时的常见问题是插件默认读取KnownHosts的指纹校验规则如果你之前用其他工具连过同一台机器、host key 记录变了插件会报出比较晦涩的错误。先把~/.ssh/known_hosts里对应主机条目清理掉再重新连接通常就能解决。5. 批量登录几十台服务器配置文件的延伸玩法如果只有三五台机器上面这套已经够用了。但当你开始管几十台机器或者经常在同一批机器上重复执行命令时配置文件的威力还能继续放大。5.1 用 ~/.ssh/config 统一管理多台机器我把生产环境的机器按角色分组命名比如prod-api-1、prod-api-2、prod-db-1。每一台在~/.ssh/config里都是一段独立配置但相同角色的机器共享用户和密钥于是用上小节说的通配符和 Include 组织方式配置文件会非常清晰Host prod-api-* User deploy IdentityFile ~/.ssh/deploy_key StrictHostKeyChecking no这样不仅登录方便项目文档里也不用再维护服务器 IP 清单了——想看某台机器的地址cat ~/.ssh/config即是全部。这里补充一个建议StrictHostKeyChecking no这个配置要慎重使用。它代表首次连接时不再询问 host key 指纹属于方便换安全的设置。我通常只对跳板机后面的动态内网主机开启对于公网生产机器还是保持默认避免中间人风险。5.2 一键登录任意主机的两种脚本思路光有别名还不够我经常会在某角色的任意机器上执行命令。这时候要么写个带参数的 shell 函数要么用循环。先看一个简单的基于主机名前缀的函数把它放进.zshrc或.bashrcsshi() { ssh prod-api-$1 }这样sshi 1就等于ssh prod-api-1sshi 2就是ssh prod-api-2。另一种更自动化的思路是让脚本读取服务器清单配合ssh的-o参数或者配置模板实现批量在 N 台机器上执行同一命令for i in 1 2 3; do ssh prod-api-$i uptime df -h | tail -5 done这个脚本实测下来批量收集状态非常高效注意输出内容会比较多建议加上echo prod-api-$i 之类分隔线。5.3 连接复用ControlMaster让批量操作明显变快这是我觉得非常值得开启的功能。SSH 每次建立完整连接都要经过 TCP 握手和密钥交换批量连续登录时这个过程累积下来相当耗时。开启ControlMaster后同一台主机的多次 SSH 连接会复用已经建立的那条 TCP 通道后续连接几乎是秒进。配置写法如下Host * ControlMaster auto ControlPath ~/.ssh/controlmux/%r%h:%p ControlPersist 10m需要先创建~/.ssh/controlmux目录。这里面几个参数的含义是ControlMaster auto自动判断是否作为主连接已有连接就复用。ControlPath指定复用通道的 socket 文件位置。ControlPersist 10m主连接空闲后保持 10 分钟在这段时间里新连接直接走复用通道。我个人的体验是跑一个循环批量巡检 20 台机器不开启 ControlMaster 时大约要两分钟开启后相同任务大约几十秒就完成。尤其当你需要 scp 多个文件、反复 ssh 进同一批机器做调试时这个配置的体感提升非常明显。最后再单独提醒一句整套方案的核心是把人要记的参数交给~/.ssh/config把人要输的密码交给 SSH Key。两者独立作用又互相配合你不需要每次登录都记住用户是 ubuntu、端口是 2222、密钥是哪个文件这些信息已经固化成配置而你只需要敲下那个短别名。这也是我为什么敢说配置好这套之后你会再也不想回到密码登录的原始时代。
阅读完成 · 觉得有帮助？
