1. 为什么要专门配置SSH密钥登录1.1 密码输入的日常痛点做过Linux运维或者经常连服务器的人应该都有这种体验手里管着三五台甚至十几台机器每次登录都要输一遍用户名和密码。密码短了不安全长了记不住有的机器密码还不一样记混了就得翻笔记隔三差五还要按公司安全规范强制改密码改完又是一轮手忙脚乱。这还只是麻烦层面的事。更实际的问题是密码在网络上传输虽然SSH协议本身做了加密但密码一旦被暴力破解工具盯上弱口令就是分分钟的事。我见过不少服务器日志里每天有几百上千次失败的SSH登录尝试全是扫描器在猜密码。如果你的密码落在了一个常用字典里被撞开只是时间问题。密钥登录解决的就是这两件事把每次输密码变成一次配置、永久免输同时把认证方式从你知道什么变成你拥有什么——没有私钥光知道用户名也进不来。严格来说密钥认证的强度也远高于密码认证因为私钥本身的复杂度远超人类能记住的密码。1.2 密钥登录原理一对钥匙的故事理解SSH密钥登录可以用一个很生活化的类比公钥和私钥就像一把锁和一把钥匙。你把锁公钥挂在服务器门上自己手里攥着钥匙私钥。每次登录服务器用锁来验证你是不是持有匹配的钥匙。具体流程是这样的客户端发起连接时服务器会生成一段随机数据用公钥加密后发给客户端客户端收到后用私钥解密再返回给服务器比对。如果对得上服务器就知道你确实持有对应的私钥认证通过。这个过程叫作挑战-应答认证整个过程中私钥始终不离开你的本地机器也不在网络上传送所以比密码更安全。还有一个容易混淆的概念要讲清楚密钥登录和免密登录SSH Agent转发不是一回事。密钥登录只是不输密码如果你配置了私钥口令passphrase第一次加载私钥时还是要输一次口令的。后面我会讲到怎么在Xshell里把这个口令也省掉实现真正的全自动登录。1.3 这套方案适合谁这篇文章的完整流程是围绕Xshell 7.0客户端和RHEL7/CentOS7服务端来写的。如果你满足下面任一场景直接照着做就行日常用Xshell管理一台或多台Linux服务器受够了反复输密码公司有安全合规要求需要关闭SSH密码登录、强制使用密钥认证自己维护的机器被人暴力扫描过想把登录方式彻底加固一遍刚接触Linux不久想系统搞清楚密钥登录到底是什么、怎么配。有一点要提前说明RHEL7和CentOS7的SSH服务端配置逻辑基本一致以下所有操作在两个系统上都适用。如果你用的是更新的RHEL8/9或者Rocky Linux步骤也不会有太大变化只是个别配置项的位置可能略有调整。2. 准备工作环境确认与工具选型2.1 服务器端检查清单动手之前先把服务器的底摸清楚。你至少需要确认三件事第一SSH服务是否正常运行。执行systemctl status sshd看到active (running)就说明服务是好的。如果没装用yum install -y openssh-server装上再启动。第二你当前登录的账号是否有sudo权限。因为后面要改sshd_config文件、重启sshd服务这些都需要root权限。如果你只有一个普通用户先确认它能不能sudo。第三确认SELinux的状态。CentOS7/RHEL7默认SELinux是Enforcing模式。很多人在密钥登录上翻车其实不是密钥配置错而是SELinux拦了。后面我会专门讲怎么处理这里你先运行getenforce看一眼心里有个数。另外建议顺手敲一下ssh -V确认OpenSSH版本。7.x以上版本对这个流程毫无压力太老的版本可能有算法兼容问题等真遇到再说。2.2 Xshell 7.0客户端准备Xshell是我用过的Windows下最顺手的SSH客户端之一7.0版本支持RSA、ECDSA、ED25519等多种密钥算法生成密钥、管理会话都很方便。如果你用的还是5.0、6.0这类老版本也建议升级到7.x因为新版默认推荐更强的算法兼容性和稳定性都更好。安装过程没什么好说的一路下一步即可。装完之后打开工具菜单你会看到一个新建用户密钥生成向导这就是我们生成密钥的地方。具体操作流程下一节细说这里先提醒一件事生成密钥之前先想好这把密钥给谁用、用在什么机器上别一把密钥走天下。我见过有人偷懒所有服务器共用一对密钥结果私钥泄露一次所有机器全完蛋。合理的做法是按应用场景或安全等级分几把不同的密钥比如个人电脑到办公服务器用一把到生产服务器用另一把。后面我会在第5章讲多密钥管理的具体方法。2.3 密钥算法选型建议生成密钥时算法和位数是第一个要做的决定。Xshell 7.0里通常提供RSA和ECDSA和ED25519三种选项我直接给结论ED25519当前最推荐的选择。密钥短、生成快、安全性高OpenSSH 6.5以上就支持了。CentOS7自带的OpenSSH版本通常在7.4左右完全没问题。RSA 3072或4096位如果你的服务器或中间设备比较老对ED25519支持不好那就用RSA。位数至少选30722048虽然在技术上还够用但安全边际越来越小能上4096就上4096。ECDSA能用但没必要优先选个别环境下有兼容性坑。一句话总结没有特殊兼容性要求就选ED25519省事又安全。不要因为大家都在用RSA就无脑跟风算法选型跟追风没关系适合你的环境才是对的。3. 密钥生成与部署全流程实操3.1 在Xshell中生成密钥对打开Xshell 7.0点击菜单栏的工具→新建用户密钥生成向导。第一步会让你选密钥类型和位数按刚才的建议类型选ED25519或者RSA位数选4096。点击下一步之后向导会提示你生成完毕并要求填写密钥名称和密码。这里有个关键选择密钥名称建议起得有意义比如你的用户名加服务器用途方便以后辨认。加密密码passphrase这是私钥文件的保护口令。你可以在这一步留空实现完全免输密码也可以设一个每次首次连接时Xshell会要求输入一次这个口令。这俩看似二选一其实是安全性和便利性的权衡。我个人的做法是个人开发测试机的密钥不设passphrase生产环境的密钥一定要设并且用Xshell的安全Shell登录功能把passphrase记住。这样既不牺牲太多便利性又保住了私钥裸奔时那最后一道防线。生成完之后向导会自动跳到公钥保存环节。你可以把公钥保存成一个文件也可以直接复制它的内容。建议两种都做文件留档内容用来贴到服务器上。公钥泄露问题不大随便存。3.2 把公钥安全地放到服务器上公钥最终要写进服务器上目标用户家目录的~/.ssh/authorized_keys文件里。这一步的路径不对、权限不对后面必出问题所以每一步都要说清楚。标准做法是用ssh-copy-id可惜CentOS7自带的openssh-clients里不一定有这个工具。没关系手动操作也一样可靠先用当前密码登录服务器然后执行mkdir -p ~/.ssh chmod 700 ~/.ssh echo 粘贴你的公钥内容 ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys三条命令的含义要啰嗦一遍mkdir -p确保.ssh目录存在chmod 700让这个目录只有你自己能读写进入追加公钥到authorized_keys最后把authorized_keys权限收紧为600。权限是密钥认证里最容易被忽视、也最容易出问题的环节很多Permission denied都是因为权限太宽松导致的。如果你是root用户给对方账号配置或者帮别的同事配置务必注意要写进的是对方的家目录不是你自己的。用su - 目标用户名切过去再操作避免把公钥装错地方。这一步错了我见过太多回了装完之后怎么测都登不上最后发现公钥躺在root的authorized_keys里。3.3 在Xshell里配置会话并测试登录公钥部署完之后回到Xshell配置会话。打开文件→新建会话或者右键已有会话→属性在连接属性里找到用户身份验证选项卡把认证方法选为Public Key然后在用户密钥下拉框里选中你刚生成的那把密钥。用户名栏填服务器上的用户名确认无误后保存。注意这里有个容易踩的坑——Xshell的会话属性底部有一个单点登录或者使用SSH代理之类的选项某些版本里会自动套用额外的认证机制如果你没配相关内容反而会导致连接异常。正常情况下不用管它保持默认就行。点击连接开始测试。如果一切顺利你将直接进入服务器不会再被要求输密码。如果弹出来让你输入私钥的passphrase说明你生成密钥时设置了加密口令输入一次即可。如果你希望在当前会话中不再重复输入Xshell的安全Shell登录功能可以帮你缓存这个口令具体在哪开启我放到最后一章讲。我第一次配成功的时候还特意断开重连了几次确认真的不用输密码了才算放心。那种感觉确实比想象中爽。4. 常见故障排查与避坑实录4.1 Permission denied的几类典型原因Permission denied (publickey)应该是我见到最多的报错没有之一。新手遇到这个提示第一反应往往是我的密钥是不是没粘对但实际原因通常有四种第一种是公钥没写对地方。检查服务器上~/.ssh/authorized_keys的内容确认最后一行的换行符是正常的没有意外截断。我见过有人用echo粘贴公钥时公钥内容还没粘贴完就按了回车结果只存了半个公钥。第二种是权限不对。SSH服务对密钥相关文件的权限极其敏感~/.ssh目录必须是700authorized_keys必须是600用户家目录本身不能是组可写或全局可写。如果家目录权限是755甚至更大SSH会直接拒绝读取authorized_keys。修复方式chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chmod 755 ~ # 家目录权限也要确认不能是775/777第三种是用了错误的用户登录。你在A用户下了公钥却用B用户登录服务器当然找不到对应的公钥。这种情况排查起来很迷惑因为密钥看起来明明配好了。第四种是客户端选错了密钥。Xshell里配了多把密钥时会话可能默认用了第一把而不是你部署公钥的那把。检查会话属性里的用户密钥下拉框确保选中的是你刚刚生成并部署的那一把。排查顺序建议先看服务端日志。执行journalctl -u sshd -f或者tail -f /var/log/secure然后重新发起一次连接日志里会明确告诉你失败发生在哪一步。比如bad permissions会直接提示权限问题No more authentication methods to try说明认证方法耗尽。看日志永远是排查SSH问题的第一动作比瞎猜快十倍。4.2 SELinux和防火墙的影响CentOS7/RHEL7上SELinux默认是Enforcing状态很多人配置密钥登录失败问题其实出在这里。最常见的情况是因为某些操作导致.ssh目录的安全上下文SELinux context不对SSH服务虽然能读到密钥但被SELinux拦了。先看安全上下文是否正确ls -Z ~/.ssh/authorized_keys正常输出里应该包含ssh_home_t这个类型标签。如果显示的是user_home_t或其他类型说明上下文被改乱了。修复方法restorecon -Rv ~/.ssh这条命令会把.ssh目录及里面文件的安全上下文恢复成默认值绝大多数SELinux引起的密钥登录问题就解决了。如果连restorecon都懒得记更粗暴的方案是临时把SELinux设为Permissive看看问题是否消失——但注意这只是排查手段不要在生产上长期关闭SELinux。防火墙方面确认22端口对来源IP开放。执行firewall-cmd --state看防火墙状态用firewall-cmd --list-all查看当前开放的服务。如果没放行firewall-cmd --permanent --add-servicessh firewall-cmd --reload顺带说一句如果你的服务器前面还有云安全组之类的东西那也要一并确认安全规则放行了22端口。这个不在本机防火墙排查范围内但很常见。4.3 Xshell端的几个隐藏坑Xshell的坑不多但每个都挺让人抓狂的。第一个是公钥格式问题。Xshell生成的公钥粘贴到authorized_keys之前要确认是OpenSSH兼容格式以ssh-ed25519 AAAA...或者ssh-rsa AAAA...开头。如果粘贴后出现invalid format之类的报错多半是复制的时候把换行符也带进去了或者文本被编辑器自动折行折坏了。遇到这种情况用记事本或VS Code重新打开公钥文件全选复制时留意是否完整。第二个是用户密钥文件被移动或丢失。Xshell生成的密钥文件存在用户目录下默认在文档里的NetSarang Computer文件夹如果你重装系统、清理文档时把它删了那就真的找不回来了——因为私钥没有被打包进Xshell的配置里。所以新密钥生成后我强烈建议第一时间备份私钥文件到安全的地方离线U盘或密码管理器都行。第三个是会话配置保存问题。修改了会话属性后记得点确定再重连。有个小技巧如果改了密钥但重连还是要求输密码大概率是会话属性没生效。直接在Xshell的主界面上重新开一次连接让它重新读取配置很多时候就好了。5. 安全加固与多机管理进阶5.1 关闭密码登录最后一步别急着做密钥登录验证没问题之后你就可以考虑关闭密码登录了。这一步是安全加固的关键但必须在确认密钥登录完全稳定之后再进行——别把唯一入口给锁死。修改SSH服务端配置vim /etc/ssh/sshd_config找到或者添加以下几项PasswordAuthentication no PubkeyAuthentication yes ChallengeResponseAuthentication no UsePAM no说明一下每一项的作用PasswordAuthentication no表示禁止密码登录PubkeyAuthentication yes确保公钥认证开启后面两项是关闭其他非必要的认证通道。保留UsePAM no能减少一些不必要的PAM干扰但在某些特殊配置下PAM还是需要的如果改完发现登录异常先把这一项恢复为yes再排查。改完之后检查配置有没有语法错误sshd -t然后平滑重载SSH服务。在CentOS7/RHEL7上systemctl reload sshd关键提醒改配置前先开一个新的SSH连接窗口测试确认新窗口能正常密钥登录后再重载服务或者关掉旧窗口。这样即使配置有问题你还有一个活着的会话可以用来回滚。我见过最惨的翻车现场管理员在办公室里改完配置直接重启sshd结果密钥认证因为权限问题失败密码登录又被自己关了人还被塞在办公室里只能大老远跑机房接显示器救场。这种低级错误只要多留一个活会话就完全能避免。5.2 密钥备份、轮换与清理密钥配置完成后日常运维还得养成几个习惯。备份私钥本体要备份这是唯一能登录服务器的凭证。新生成密钥后立即备份并测试从备份恢复出来的私钥能否正常登录。别等哪天电脑硬盘坏了才想起来备份——到那时候你连测试恢复的机会都没有。轮换私钥不是永久有效的。人员离职、私钥可能泄露或者时间超过一年都建议换一把新密钥。轮换的操作流程跟首次配置完全一样生成新密钥→部署公钥→用新密钥确认登录→关闭密码登录如果之前关了的话→从服务器authorized_keys里移除旧公钥。这个顺序很重要先确保新密钥可用再清理旧的避免把自己关在门外。清理偶尔检查一下每台服务器上的authorized_keys文件确认里面每一行公钥都是当前在用的人。我已经不止一次在客户的服务器上发现离职员工残留的公钥还躺在里面——这意味着那个离职员工随时都能登录这台机器是实打实的安全隐患。5.3 多台服务器的密钥管理技巧如果你手里有多台服务器逐个配置密钥会让人崩溃。这里分享我整理出来的几个省力技巧。最简单的方案是按用途生成多把密钥在Xshell会话属性里分别绑定。比如开发环境用devkey生产环境用prodkey。这个方案最直观也最适合服务器数量不多的场景。第二个方案是用ssh-agent管理。如果你设了passphrase首次连接会让你输一次之后Xshell会在会话存活期间缓存这个口令后续连接免输。这个功能在Xshell里叫安全Shell登录在工具→安全Shell登录里设置把密钥加载进去即可。它的原理就是把私钥口令缓存在内存中下次连接直接使用。第三个方案是脚本化批量部署。给一批新服务器配公钥时手动一台台来太慢。如果这些服务器已经支持密码登录可以写个简单的expect脚本或者用Ansible跑一遍。但要注意批量部署的前提是你对这批机器有完全的控制权别在生产环境上乱跑脚本。最后无论用哪种方案我都建议在Xshell会话管理器里给每个会话明确标注使用了哪把密钥。时间久了你会忘记标注清楚能少踩很多坑。5.4 关于passphrase的个人经验写到最后想聊聊我对passphrase的态度。刚接触密钥登录那会儿我觉得反正是密钥认证了干嘛还要设个口令多此一举直接留空最方便。后来有一次测试U盘丢了虽然那把私钥只用于测试环境而且发现得早及时轮换了但那几天心里一直不踏实。自那以后我的原则变成了生产相关的密钥一律设置passphrase配合Xshell的缓存机制使用。这样日常连接不麻烦私钥就算被人拷走也没有直接价值。代价只是首次加载时多输一次口令这点成本换来的是私钥泄露时还能兜底的安心感我认为非常值得。这个选择没有正确答案完全取决于你对便利性和安全性的权衡。但至少你要明白不设passphrase的私钥等同于一把掉在地上谁都能捡起来用的钥匙。想清楚这一点再决定要不要省掉那些口令。我在实际使用中还有一个习惯每次配置完密钥登录都会顺手做一遍新会话→连接→断开→重连的完整验证确认所有环节都稳定后再离开。这套流程跑下来遇到过的绝大多数问题都挡在了前面。你按这篇文章从头到尾走一遍配置密钥登录这件事大概率也是一次过的。 
长河君 · 2026/10/20 18:18:24 · 阅读 1.2k SSH密钥登录配置全攻略：从原理到Xshell实操与安全加固
1. 为什么要专门配置SSH密钥登录1.1 密码输入的日常痛点做过Linux运维或者经常连服务器的人应该都有这种体验手里管着三五台甚至十几台机器每次登录都要输一遍用户名和密码。密码短了不安全长了记不住有的机器密码还不一样记混了就得翻笔记隔三差五还要按公司安全规范强制改密码改完又是一轮手忙脚乱。这还只是麻烦层面的事。更实际的问题是密码在网络上传输虽然SSH协议本身做了加密但密码一旦被暴力破解工具盯上弱口令就是分分钟的事。我见过不少服务器日志里每天有几百上千次失败的SSH登录尝试全是扫描器在猜密码。如果你的密码落在了一个常用字典里被撞开只是时间问题。密钥登录解决的就是这两件事把每次输密码变成一次配置、永久免输同时把认证方式从你知道什么变成你拥有什么——没有私钥光知道用户名也进不来。严格来说密钥认证的强度也远高于密码认证因为私钥本身的复杂度远超人类能记住的密码。1.2 密钥登录原理一对钥匙的故事理解SSH密钥登录可以用一个很生活化的类比公钥和私钥就像一把锁和一把钥匙。你把锁公钥挂在服务器门上自己手里攥着钥匙私钥。每次登录服务器用锁来验证你是不是持有匹配的钥匙。具体流程是这样的客户端发起连接时服务器会生成一段随机数据用公钥加密后发给客户端客户端收到后用私钥解密再返回给服务器比对。如果对得上服务器就知道你确实持有对应的私钥认证通过。这个过程叫作挑战-应答认证整个过程中私钥始终不离开你的本地机器也不在网络上传送所以比密码更安全。还有一个容易混淆的概念要讲清楚密钥登录和免密登录SSH Agent转发不是一回事。密钥登录只是不输密码如果你配置了私钥口令passphrase第一次加载私钥时还是要输一次口令的。后面我会讲到怎么在Xshell里把这个口令也省掉实现真正的全自动登录。1.3 这套方案适合谁这篇文章的完整流程是围绕Xshell 7.0客户端和RHEL7/CentOS7服务端来写的。如果你满足下面任一场景直接照着做就行日常用Xshell管理一台或多台Linux服务器受够了反复输密码公司有安全合规要求需要关闭SSH密码登录、强制使用密钥认证自己维护的机器被人暴力扫描过想把登录方式彻底加固一遍刚接触Linux不久想系统搞清楚密钥登录到底是什么、怎么配。有一点要提前说明RHEL7和CentOS7的SSH服务端配置逻辑基本一致以下所有操作在两个系统上都适用。如果你用的是更新的RHEL8/9或者Rocky Linux步骤也不会有太大变化只是个别配置项的位置可能略有调整。2. 准备工作环境确认与工具选型2.1 服务器端检查清单动手之前先把服务器的底摸清楚。你至少需要确认三件事第一SSH服务是否正常运行。执行systemctl status sshd看到active (running)就说明服务是好的。如果没装用yum install -y openssh-server装上再启动。第二你当前登录的账号是否有sudo权限。因为后面要改sshd_config文件、重启sshd服务这些都需要root权限。如果你只有一个普通用户先确认它能不能sudo。第三确认SELinux的状态。CentOS7/RHEL7默认SELinux是Enforcing模式。很多人在密钥登录上翻车其实不是密钥配置错而是SELinux拦了。后面我会专门讲怎么处理这里你先运行getenforce看一眼心里有个数。另外建议顺手敲一下ssh -V确认OpenSSH版本。7.x以上版本对这个流程毫无压力太老的版本可能有算法兼容问题等真遇到再说。2.2 Xshell 7.0客户端准备Xshell是我用过的Windows下最顺手的SSH客户端之一7.0版本支持RSA、ECDSA、ED25519等多种密钥算法生成密钥、管理会话都很方便。如果你用的还是5.0、6.0这类老版本也建议升级到7.x因为新版默认推荐更强的算法兼容性和稳定性都更好。安装过程没什么好说的一路下一步即可。装完之后打开工具菜单你会看到一个新建用户密钥生成向导这就是我们生成密钥的地方。具体操作流程下一节细说这里先提醒一件事生成密钥之前先想好这把密钥给谁用、用在什么机器上别一把密钥走天下。我见过有人偷懒所有服务器共用一对密钥结果私钥泄露一次所有机器全完蛋。合理的做法是按应用场景或安全等级分几把不同的密钥比如个人电脑到办公服务器用一把到生产服务器用另一把。后面我会在第5章讲多密钥管理的具体方法。2.3 密钥算法选型建议生成密钥时算法和位数是第一个要做的决定。Xshell 7.0里通常提供RSA和ECDSA和ED25519三种选项我直接给结论ED25519当前最推荐的选择。密钥短、生成快、安全性高OpenSSH 6.5以上就支持了。CentOS7自带的OpenSSH版本通常在7.4左右完全没问题。RSA 3072或4096位如果你的服务器或中间设备比较老对ED25519支持不好那就用RSA。位数至少选30722048虽然在技术上还够用但安全边际越来越小能上4096就上4096。ECDSA能用但没必要优先选个别环境下有兼容性坑。一句话总结没有特殊兼容性要求就选ED25519省事又安全。不要因为大家都在用RSA就无脑跟风算法选型跟追风没关系适合你的环境才是对的。3. 密钥生成与部署全流程实操3.1 在Xshell中生成密钥对打开Xshell 7.0点击菜单栏的工具→新建用户密钥生成向导。第一步会让你选密钥类型和位数按刚才的建议类型选ED25519或者RSA位数选4096。点击下一步之后向导会提示你生成完毕并要求填写密钥名称和密码。这里有个关键选择密钥名称建议起得有意义比如你的用户名加服务器用途方便以后辨认。加密密码passphrase这是私钥文件的保护口令。你可以在这一步留空实现完全免输密码也可以设一个每次首次连接时Xshell会要求输入一次这个口令。这俩看似二选一其实是安全性和便利性的权衡。我个人的做法是个人开发测试机的密钥不设passphrase生产环境的密钥一定要设并且用Xshell的安全Shell登录功能把passphrase记住。这样既不牺牲太多便利性又保住了私钥裸奔时那最后一道防线。生成完之后向导会自动跳到公钥保存环节。你可以把公钥保存成一个文件也可以直接复制它的内容。建议两种都做文件留档内容用来贴到服务器上。公钥泄露问题不大随便存。3.2 把公钥安全地放到服务器上公钥最终要写进服务器上目标用户家目录的~/.ssh/authorized_keys文件里。这一步的路径不对、权限不对后面必出问题所以每一步都要说清楚。标准做法是用ssh-copy-id可惜CentOS7自带的openssh-clients里不一定有这个工具。没关系手动操作也一样可靠先用当前密码登录服务器然后执行mkdir -p ~/.ssh chmod 700 ~/.ssh echo 粘贴你的公钥内容 ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys三条命令的含义要啰嗦一遍mkdir -p确保.ssh目录存在chmod 700让这个目录只有你自己能读写进入追加公钥到authorized_keys最后把authorized_keys权限收紧为600。权限是密钥认证里最容易被忽视、也最容易出问题的环节很多Permission denied都是因为权限太宽松导致的。如果你是root用户给对方账号配置或者帮别的同事配置务必注意要写进的是对方的家目录不是你自己的。用su - 目标用户名切过去再操作避免把公钥装错地方。这一步错了我见过太多回了装完之后怎么测都登不上最后发现公钥躺在root的authorized_keys里。3.3 在Xshell里配置会话并测试登录公钥部署完之后回到Xshell配置会话。打开文件→新建会话或者右键已有会话→属性在连接属性里找到用户身份验证选项卡把认证方法选为Public Key然后在用户密钥下拉框里选中你刚生成的那把密钥。用户名栏填服务器上的用户名确认无误后保存。注意这里有个容易踩的坑——Xshell的会话属性底部有一个单点登录或者使用SSH代理之类的选项某些版本里会自动套用额外的认证机制如果你没配相关内容反而会导致连接异常。正常情况下不用管它保持默认就行。点击连接开始测试。如果一切顺利你将直接进入服务器不会再被要求输密码。如果弹出来让你输入私钥的passphrase说明你生成密钥时设置了加密口令输入一次即可。如果你希望在当前会话中不再重复输入Xshell的安全Shell登录功能可以帮你缓存这个口令具体在哪开启我放到最后一章讲。我第一次配成功的时候还特意断开重连了几次确认真的不用输密码了才算放心。那种感觉确实比想象中爽。4. 常见故障排查与避坑实录4.1 Permission denied的几类典型原因Permission denied (publickey)应该是我见到最多的报错没有之一。新手遇到这个提示第一反应往往是我的密钥是不是没粘对但实际原因通常有四种第一种是公钥没写对地方。检查服务器上~/.ssh/authorized_keys的内容确认最后一行的换行符是正常的没有意外截断。我见过有人用echo粘贴公钥时公钥内容还没粘贴完就按了回车结果只存了半个公钥。第二种是权限不对。SSH服务对密钥相关文件的权限极其敏感~/.ssh目录必须是700authorized_keys必须是600用户家目录本身不能是组可写或全局可写。如果家目录权限是755甚至更大SSH会直接拒绝读取authorized_keys。修复方式chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chmod 755 ~ # 家目录权限也要确认不能是775/777第三种是用了错误的用户登录。你在A用户下了公钥却用B用户登录服务器当然找不到对应的公钥。这种情况排查起来很迷惑因为密钥看起来明明配好了。第四种是客户端选错了密钥。Xshell里配了多把密钥时会话可能默认用了第一把而不是你部署公钥的那把。检查会话属性里的用户密钥下拉框确保选中的是你刚刚生成并部署的那一把。排查顺序建议先看服务端日志。执行journalctl -u sshd -f或者tail -f /var/log/secure然后重新发起一次连接日志里会明确告诉你失败发生在哪一步。比如bad permissions会直接提示权限问题No more authentication methods to try说明认证方法耗尽。看日志永远是排查SSH问题的第一动作比瞎猜快十倍。4.2 SELinux和防火墙的影响CentOS7/RHEL7上SELinux默认是Enforcing状态很多人配置密钥登录失败问题其实出在这里。最常见的情况是因为某些操作导致.ssh目录的安全上下文SELinux context不对SSH服务虽然能读到密钥但被SELinux拦了。先看安全上下文是否正确ls -Z ~/.ssh/authorized_keys正常输出里应该包含ssh_home_t这个类型标签。如果显示的是user_home_t或其他类型说明上下文被改乱了。修复方法restorecon -Rv ~/.ssh这条命令会把.ssh目录及里面文件的安全上下文恢复成默认值绝大多数SELinux引起的密钥登录问题就解决了。如果连restorecon都懒得记更粗暴的方案是临时把SELinux设为Permissive看看问题是否消失——但注意这只是排查手段不要在生产上长期关闭SELinux。防火墙方面确认22端口对来源IP开放。执行firewall-cmd --state看防火墙状态用firewall-cmd --list-all查看当前开放的服务。如果没放行firewall-cmd --permanent --add-servicessh firewall-cmd --reload顺带说一句如果你的服务器前面还有云安全组之类的东西那也要一并确认安全规则放行了22端口。这个不在本机防火墙排查范围内但很常见。4.3 Xshell端的几个隐藏坑Xshell的坑不多但每个都挺让人抓狂的。第一个是公钥格式问题。Xshell生成的公钥粘贴到authorized_keys之前要确认是OpenSSH兼容格式以ssh-ed25519 AAAA...或者ssh-rsa AAAA...开头。如果粘贴后出现invalid format之类的报错多半是复制的时候把换行符也带进去了或者文本被编辑器自动折行折坏了。遇到这种情况用记事本或VS Code重新打开公钥文件全选复制时留意是否完整。第二个是用户密钥文件被移动或丢失。Xshell生成的密钥文件存在用户目录下默认在文档里的NetSarang Computer文件夹如果你重装系统、清理文档时把它删了那就真的找不回来了——因为私钥没有被打包进Xshell的配置里。所以新密钥生成后我强烈建议第一时间备份私钥文件到安全的地方离线U盘或密码管理器都行。第三个是会话配置保存问题。修改了会话属性后记得点确定再重连。有个小技巧如果改了密钥但重连还是要求输密码大概率是会话属性没生效。直接在Xshell的主界面上重新开一次连接让它重新读取配置很多时候就好了。5. 安全加固与多机管理进阶5.1 关闭密码登录最后一步别急着做密钥登录验证没问题之后你就可以考虑关闭密码登录了。这一步是安全加固的关键但必须在确认密钥登录完全稳定之后再进行——别把唯一入口给锁死。修改SSH服务端配置vim /etc/ssh/sshd_config找到或者添加以下几项PasswordAuthentication no PubkeyAuthentication yes ChallengeResponseAuthentication no UsePAM no说明一下每一项的作用PasswordAuthentication no表示禁止密码登录PubkeyAuthentication yes确保公钥认证开启后面两项是关闭其他非必要的认证通道。保留UsePAM no能减少一些不必要的PAM干扰但在某些特殊配置下PAM还是需要的如果改完发现登录异常先把这一项恢复为yes再排查。改完之后检查配置有没有语法错误sshd -t然后平滑重载SSH服务。在CentOS7/RHEL7上systemctl reload sshd关键提醒改配置前先开一个新的SSH连接窗口测试确认新窗口能正常密钥登录后再重载服务或者关掉旧窗口。这样即使配置有问题你还有一个活着的会话可以用来回滚。我见过最惨的翻车现场管理员在办公室里改完配置直接重启sshd结果密钥认证因为权限问题失败密码登录又被自己关了人还被塞在办公室里只能大老远跑机房接显示器救场。这种低级错误只要多留一个活会话就完全能避免。5.2 密钥备份、轮换与清理密钥配置完成后日常运维还得养成几个习惯。备份私钥本体要备份这是唯一能登录服务器的凭证。新生成密钥后立即备份并测试从备份恢复出来的私钥能否正常登录。别等哪天电脑硬盘坏了才想起来备份——到那时候你连测试恢复的机会都没有。轮换私钥不是永久有效的。人员离职、私钥可能泄露或者时间超过一年都建议换一把新密钥。轮换的操作流程跟首次配置完全一样生成新密钥→部署公钥→用新密钥确认登录→关闭密码登录如果之前关了的话→从服务器authorized_keys里移除旧公钥。这个顺序很重要先确保新密钥可用再清理旧的避免把自己关在门外。清理偶尔检查一下每台服务器上的authorized_keys文件确认里面每一行公钥都是当前在用的人。我已经不止一次在客户的服务器上发现离职员工残留的公钥还躺在里面——这意味着那个离职员工随时都能登录这台机器是实打实的安全隐患。5.3 多台服务器的密钥管理技巧如果你手里有多台服务器逐个配置密钥会让人崩溃。这里分享我整理出来的几个省力技巧。最简单的方案是按用途生成多把密钥在Xshell会话属性里分别绑定。比如开发环境用devkey生产环境用prodkey。这个方案最直观也最适合服务器数量不多的场景。第二个方案是用ssh-agent管理。如果你设了passphrase首次连接会让你输一次之后Xshell会在会话存活期间缓存这个口令后续连接免输。这个功能在Xshell里叫安全Shell登录在工具→安全Shell登录里设置把密钥加载进去即可。它的原理就是把私钥口令缓存在内存中下次连接直接使用。第三个方案是脚本化批量部署。给一批新服务器配公钥时手动一台台来太慢。如果这些服务器已经支持密码登录可以写个简单的expect脚本或者用Ansible跑一遍。但要注意批量部署的前提是你对这批机器有完全的控制权别在生产环境上乱跑脚本。最后无论用哪种方案我都建议在Xshell会话管理器里给每个会话明确标注使用了哪把密钥。时间久了你会忘记标注清楚能少踩很多坑。5.4 关于passphrase的个人经验写到最后想聊聊我对passphrase的态度。刚接触密钥登录那会儿我觉得反正是密钥认证了干嘛还要设个口令多此一举直接留空最方便。后来有一次测试U盘丢了虽然那把私钥只用于测试环境而且发现得早及时轮换了但那几天心里一直不踏实。自那以后我的原则变成了生产相关的密钥一律设置passphrase配合Xshell的缓存机制使用。这样日常连接不麻烦私钥就算被人拷走也没有直接价值。代价只是首次加载时多输一次口令这点成本换来的是私钥泄露时还能兜底的安心感我认为非常值得。这个选择没有正确答案完全取决于你对便利性和安全性的权衡。但至少你要明白不设passphrase的私钥等同于一把掉在地上谁都能捡起来用的钥匙。想清楚这一点再决定要不要省掉那些口令。我在实际使用中还有一个习惯每次配置完密钥登录都会顺手做一遍新会话→连接→断开→重连的完整验证确认所有环节都稳定后再离开。这套流程跑下来遇到过的绝大多数问题都挡在了前面。你按这篇文章从头到尾走一遍配置密钥登录这件事大概率也是一次过的。