Windows SSH密钥免密登录Ubuntu Server完整实战：从原理到排错

很多玩服务器的朋友都有这个体验Windows上连Ubuntu Server平时用密码登录也凑合能用但一旦要跑脚本、定时任务、批量同步文件密码就成了最大的拦路虎。改成SSH密钥免密登录之后一条ssh命令直接进系统不用再输密码日常维护和自动化都顺滑很多。这篇把Windows电脑配置SSH密钥、免密连接Ubuntu Server的完整流程写一遍从原理到实操再到坑点都覆盖到新手能照做老手也能查漏补缺。先说清楚整套方案的构成。我们要配置的是一套典型的客户端-服务端密钥认证Windows电脑作为客户端持有私钥Ubuntu Server作为服务端保存公钥。登录时服务器用公钥验证客户端手里的私钥验证通过就直接放行整个过程不涉及密码。适合的场景包括日常服务器管理、配合VS Code远程开发、给脚本用SCP/SSH批量传文件以及任何不想被密码打断操作节奏的场景。1. 为什么值得搞一套密钥免密登录1.1 密钥登录到底解决了什么问题用密码登录SSH最大的痛点不是慢而是不安全和不稳定。Linux服务器放在公网上默认22端口每天都会被扫描密码简单一点的机器被暴力破解只是时间问题。就算密码复杂破解风险低一些你也会遇到另一个麻烦——每次连接都要手动输入想写个自动化脚本都得用sshpass之类的东西把密码塞进命令行既不优雅也不安全。密钥登录把这两个问题一起解决了。私钥是本地生成的随机内容长度足够长不存在“猜密码”这种攻击途径登录过程自动完成不需要交互输入脚本、定时任务、CI/CD管道只需要持有私钥就能免密执行远程命令。我自己的服务器切到密钥登录之后基本上再也没看过密码登录方式一眼。用生活化的方式来理解密码登录就像家门钥匙谁拿了一把复制钥匙都有机会进门只要密码泄露一次就完蛋密钥登录更像指纹锁加身份证门锁上登记了你的“身份信息”公钥只有你手上那把独一无二的“指纹”私钥才能打开。公钥可以随便给出去私钥绝对不能离开你的电脑。1.2 SSH密钥认证的运行原理很多教程直接甩命令让用户复制粘贴结果出了问题完全不知道去哪排查。我建议每个人先把原理搞明白后面碰到问题才知道从哪个方向下手。SSH密钥认证依赖的是非对称加密算法。简单来说系统会生成一对密钥一个公钥和一个私钥。公钥可以公开分发私钥必须自己保存绝不能泄露。运算方向是单向的——用私钥加密的数据只有对应的公钥能解开用公钥加密的数据只有对应的私钥能解开。SSH的登录过程大概是这样的客户端发起连接告诉服务器自己打算用哪个密钥认证。服务器回应一个质询challenge客户端使用私钥对这个质询进行签名。服务器用事先保存的公钥验证签名验证通过就允许登录。在这个流程里私钥始终没有离开客户端服务器也不需要知道你的私钥只需要验证你确实持有对应的私钥。所以哪怕服务器被攻破攻击者拿到公钥也反推不出私钥这是非对称加密的核心价值。理解了这层逻辑后面配置文件的每一项你都能读懂它到底在干什么。2. 动手前的环境准备2.1 Windows端确认自带OpenSSH客户端现在Windows 10和Windows 11基本都内置了OpenSSH客户端不需要额外安装第三方工具。第一次使用前先确认一下打开PowerShell或CMD执行ssh -V能输出版本号形如OpenSSH_9.x说明客户端已经就绪。如果提示找不到命令去“设置 - 应用 - 可选功能”里查看有没有安装“OpenSSH客户端”没有就点“添加功能”装一个安装完重开终端就能用。这里补充一个实际经验尽量保持OpenSSH客户端版本别太旧。Windows的可选功能更新是跟随系统更新的一般没问题但如果你发现某些新算法用不了比如后面要讲的ed25519优先检查系统是否更新到了较新版本。2.2 Ubuntu Server端确认sshd服务说完客户端说服务端。Ubuntu Server默认安装了openssh-server是比较常见的但有一部分精简安装可能没装需要自己确认。登录Ubuntu服务器执行sudo systemctl status ssh如果看到绿色的active (running)服务正常。如果没装或者没启动执行sudo apt update sudo apt install openssh-server -y sudo systemctl enable --now sshenable是让sshd开机自启--now是立刻启动。这一步做完Ubuntu这端就能接收SSH连接了。检查一下端口有没有正常监听sudo ss -tlnp | grep :22能看到22端口处于LISTEN状态就说明服务端没问题。2.3 网络层面的连通性自检密钥认证本身不依赖网络环境但如果你连不上服务器后面一切免谈。我建议在配置密钥之前先把网络链路打通。先用ip addr查看Ubuntu服务器的IP地址记下来。Windows这边用ping测试基本连通性ping 服务器IP能ping通说明网络通。如果超时优先检查Ubuntu的防火墙是不是把22端口拦了。Ubuntu上常用的防火墙是UFW查看规则sudo ufw status如果状态是active并且没有放行22端口执行sudo ufw allow OpenSSHOpenSSH是UFW里预设的应用规则相当于放行22/tcp。这一步做完Windows再ping一次顺便用密码登录一次确认整个链路是正常的再往下走密钥配置。3. 生成密钥对与部署公钥3.1 用ssh-keygen生成密钥对环境准备好了接下来生成密钥对。这一步在Windows上完成打开PowerShell执行ssh-keygen -t ed25519 -C windows-ubuntu-key解释一下参数-t ed25519指定使用ed25519算法生成密钥对-C是添加注释通常写你的用途方便以后管理多个密钥时区分。为什么推荐ed25519而不是传统的RSA这是一个实践经验问题。ed25519生成的密钥更短实际使用中认证速度更快、安全性更高而且OpenSSH近几年的版本都原生支持。如果你有比较老的服务器或设备担心兼容性可以用ssh-keygen -t rsa -b 4096生成RSA密钥但在我实际测试的Ubuntu 20.04之后的版本上ed25519完全没有兼容性问题。执行过程中会问三个问题Enter file in which to save the key保存路径默认是C:\Users\你的用户名\.ssh\id_ed25519直接回车用默认即可。Enter passphrase私钥保护口令可选。Confirm passphrase再次输入确认。关于passphrase我要多说几句。很多人以为免密就是私钥不设置口令其实“免密登录服务器”和“私钥要不要额外口令保护”是两个维度。私钥里面可以再设置一层passphrase这样即使别人拿到你的私钥文件也打不开。设置了passphrase之后每次使用私钥连接服务器需要输入一次passphrase但如果配合后面要说的ssh-agent你只需要在登录Windows后解锁一次私钥后续自动使用体验上依然接近免密。我个人的建议是给私钥加一个passphrase安全性和便利性都能兼顾。生成完成后在.ssh目录下会看到两个文件id_ed25519私钥和id_ed25519.pub公钥。私钥文件建议立刻设置访问权限Windows下可以右键属性-安全里收紧或者在PowerShell里用icacls命令处理icacls C:\Users\你的用户名\.ssh\id_ed25519 /inheritance:r /grant:r 你的用户名:F这一步经常被忽略但其实非常重要。私钥本质上就是你远程服务器的门票权限过宽意味着同一台电脑上的其他账户也能读取它。3.2 Windows下如何把公钥安全传到服务器公钥生成的下一步是把它放到Ubuntu服务器的~/.ssh/authorized_keys文件里。这是整个配置里最容易出问题的一步我见过太多人卡在这里。最省事的方式是使用ssh-copy-id。很多教程说这个工具Linux自带、Windows没有其实现在Windows 10/11的OpenSSH套件里面已经包含它了。在PowerShell里直接执行ssh-copy-id 用户名服务器IP命令运行后会要求输入一次密码这是整个配置过程中唯一一次需要密码的场景。执行完毕公钥自动追加到服务器上对应用户的authorized_keys文件里同时会帮你把文件和目录的权限设置好。用这种方式部署后续权限问题的概率会低很多。如果执行时提示找不到ssh-copy-id别慌还有手动部署方案。手动部署本质上是三步把公钥内容复制到剪贴板登录服务器把内容追加到文件中。先在Windows上查看公钥内容cat C:\Users\你的用户名\.ssh\id_ed25519.pub复制输出的整行内容注意是一整行不要换行。然后登录服务器ssh 用户名服务器IP登录后依次执行mkdir -p ~/.ssh chmod 700 ~/.ssh echo 这里粘贴你复制的公钥内容 ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys这里有几个细节值得注意。mkdir -p是确保目录存在如果已有也不报错chmod 700设置.ssh目录只有当前用户可读写执行chmod 600让authorized_keys文件只允许当前用户读写。权限这一步我后面会重点讲原因现在先照做。3.3 手动部署公钥时的权限细节权限问题在SSH密钥登录中占据的坑位至少有四成。sshd对目录和文件权限有严格的检查~/.ssh目录必须是700authorized_keys文件必须是600如果权限过宽sshd直接拒绝使用这个文件表现为“明明公钥放对了但是登录时依然被拒”。手动粘贴公钥还有一个容易被忽略的坑Windows的换行符。如果你在记事本里复制公钥内容粘贴到服务器时可能引入额外的回车符导致公钥解析失败。我遇到过几次这种情况表现为本地看公钥没毛病服务器端看内容也对但就是认证失败。解决办法有两个一是不要用记事本而是用VS Code或者其他编辑器复制内容二是在服务器端执行cat -A ~/.ssh/authorized_keys检查有没有^M之类的特殊字符。如果发现有不正常的换行符重新粘贴一次即可。还有一点如果服务器上这个用户之前没有.ssh目录需要确认创建目录时的属主是你当前登录的这个用户不是root。有些朋友为了方便直接全用root执行命令建出来的目录属主是root后面普通用户登录就有权限读取问题了。创建完目录后顺手看一下ls -ld ~/.ssh确保属主是你的用户名。4. 调整sshd配置实现免密登录4.1 配置项逐个说明公钥部署完成理论上现在就可以尝试密钥登录了。但为了把免密登录做得彻底、安全还需要调整sshd的配置。配置文件在Ubuntu上是/etc/ssh/sshd_config用root权限编辑sudo vim /etc/ssh/sshd_config重点关注和修改这几个配置项PubkeyAuthentication yes PasswordAuthentication no PermitRootLogin prohibit-passwordPubkeyAuthentication表示是否允许公钥认证默认一般是yes确认没被注释就行。PasswordAuthentication是密码认证开关改成no之后服务器就不再接受密码登录这是“免密”的关键。PermitRootLogin建议设置成prohibit-password意思是root用户只允许密钥登录不允许密码登录比完全禁止root登录灵活也比允许root密码登录安全得多。改完之后检查一下配置语法sudo sshd -tsshd -t是测试配置文件的语法有问题会直接报错比重启服务后发现连不上要好得多。语法没问题就重启sshdsudo systemctl restart ssh这里要特别提醒不要在做完密钥登录测试之前就关闭密码认证。我一贯的操法是先把密钥部署好确认能免密登录再回头把PasswordAuthentication改成no重启服务后再测试一次。顺序反了的话密钥配置出现任何小问题你就只能通过VNC、物理控制台或者云厂商的网页终端去救机器了。4.2 安全加固与保留逃生通道把密码认证关掉之后你的服务器安全性提升了一大截但这不代表万事大吉了。我习惯顺手再做几项加固成本很低收益很实在。第一限制允许登录的用户。在sshd_config里加一行AllowUsers 你的用户名这样即使其他用户的密钥泄露了也没法通过SSH登录这台机器白名单比黑名单可靠得多。第二如果有条件换一个非22端口。改端口对安全性的提升有争议因为扫描器是全端口扫描的但它确实能减少大量无意义的登录尝试日志。在sshd_config里改Port字段然后记得在UFW里放行新端口sudo ufw allow 2222/tcp第三保留一个“逃生通道”。我个人的习惯是在完全关闭密码认证之前先在本地终端保持一个已经建立的SSH会话不退出然后另开一个窗口测试新的密钥登录。如果测试失败还有旧会话可以抢救。不要小看这个细节我在生产服务器上见过太多因为配置失误而被锁在门外的案例无一例外都是没留后路。4.3 完整的测试流程配置完成之后测试是关键。先在Windows上打开一个新终端执行ssh 用户名服务器IP如果一切正常你会直接进入服务器的shell不再询问密码。如果设置了私钥passphrase会先要求输入一次passphrase输完就进去了。登录成功后可以看看认证方式echo $SSH_CONNECTION能输出客户端和服务器地址就说明连接建立成功。如果想确认认证过程确实是密钥认证可以加-v查看详细日志ssh -v 用户名服务器IP输出里面找到Authenticated to 服务器IP以及publickey字样就说明走的是密钥认证流程。全程没有密码提示免密登录的目标就已经实现了。测试通过后如果之前没做再回到sshd_config里把PasswordAuthentication改成no重启服务再测试一遍确认密码登录已被禁用。我现在每配完一台服务器都会重复这个流程已经形成肌肉记忆了。5. 常见问题与排查技巧实录5.1 常见问题速查表这部分是踩坑经验的精华。我把实际工作中遇到频率最高的几个问题整理成了速查表按“现象-原因-解决办法”展开排查的时候直接对照着看。现象可能原因解决办法Permission denied (publickey)公钥没放对位置或者权限不对检查authorized_keys内容确认.ssh为700、authorized_keys为600Bad owner or permissions on C:\Users....ssh\configWindows下config文件权限继承导致用icacls收紧config文件的权限去掉继承权限Connection timed out网络不通或防火墙拦截ping服务器检查UFW是否放行SSH端口Too many authentication failures客户端自动尝试了太多密钥使用ssh -i 指定私钥路径或配置Host指定IdentityFileServer refused our key服务端没有匹配的公钥或PubkeyAuthentication未开启检查authorized_keys内容确认sshd_config配置5.2 几个我踩过的坑第一个坑是Windows用户目录下多个私钥导致的认证混乱。如果你电脑里配置过GitHub、Gitee、服务器等多个密钥执行ssh连接时客户端会按顺序尝试所有默认位置的私钥有时会触发服务器端的“尝试次数过多”保护机制直接断开连接。解决办法是在.ssh/config文件里明确指定每台主机用哪个私钥Host ubuntu-server HostName 服务器IP User 你的用户名 IdentityFile ~/.ssh/id_ed25519 IdentitiesOnly yesIdentitiesOnly yes的意思是只使用这里指定的私钥不要额外尝试其他密钥。这个配置对免密的稳定性帮助非常大。第二个坑是Windows的config文件权限问题。这是Windows下SSH特有的问题报错信息是Bad owner or permissions on C:\Users\你的用户名\.ssh\config原因是新建的config文件默认继承了父目录的权限ntfs的ACL权限不够严格OpenSSH直接拒绝使用这个配置文件。修复方法是icacls C:\Users\你的用户名\.ssh\config /inheritance:r /grant:r 你的用户名:F执行完再连接就正常了。配置Windows端的SSH文件权限确实比Linux端要啰嗦一些但搞一次后面就不会再遇到它了。第三个坑是Ubuntu端/var/log/auth.log这个排障入口很多人不知道。Linux系统会把所有SSH认证记录写在这个文件里密钥认证失败时它会把拒绝原因写得明明白白。排查时登录服务器执行sudo tail -n 50 /var/log/auth.log如果看到类似Failed publickey for 用户名 from 客户端IP的日志回应了上面提到的公钥或权限问题如果看到Connection closed by authenticating user可能是客户端这边就没有完成认证流程。5.3 与VS Code等工具联动密钥免密登录配置好之后最舒服的用法其实是配合VS Code。装一个Remote - SSH插件在插件里添加SSH主机填写用户名和服务器IP剩下的连接过程完全复用你刚刚配置的密钥不需要重复输入任何密码。VS Code会直接打开远程工作区编辑代码、跑终端、看日志都在远端服务器上进行体验和本地开发几乎没有区别。Windows Terminal也可以配置成打开即连接wt -p Ubuntu Server -- ssh 用户名服务器IP总的来说密钥配置属于一次投入、长期回报的事。它本身是SSH生态里最基础也最可靠的一项能力只要把原理和权限这两个关键点吃透剩下的就是复制粘贴的问题。我个人的习惯是配完服务器后一定会把私钥备份到一个加密容器里同时确认服务器上至少存在两个可用的登录方式免得哪天真把自己锁在外面。希望这篇内容能帮你把Windows和Ubuntu Server之间的最后一层“密码障碍”拆掉。