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。位数至少选3072，2048虽然在技术上还够用，但安全边际越来越小，能上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目录必须是700，authorized_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-service=ssh 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的私钥，等同于一把掉在地上谁都能捡起来用的钥匙。想清楚这一点，再决定要不要省掉那些口令。
我在实际使用中还有一个习惯：每次配置完密钥登录，都会顺手做一遍"新会话→连接→断开→重连"的完整验证，确认所有环节都稳定后再离开。这套流程跑下来，遇到过的绝大多数问题都挡在了前面。你按这篇文章从头到尾走一遍，配置密钥登录这件事，大概率也是一次过的。
