当你第一次用Xshell连接一台云上Linux实例时，默认的密码认证和22端口几乎是在向扫描器敞开大门。这篇教程不止于教你填对IP和端口——我们会从连接建立的第一步就引入安全基线思维，让每一次SSH会话都处于可控状态。

建立连接前的安全基线检查

在打开Xshell新建会话之前，先在Linux服务器端完成三项基线配置。第一，编辑 /etc/ssh/sshd_config，将默认端口从22改为一个高位端口（如52222），并设置 PermitRootLogin no 禁止root直接登录。第二，通过 AllowUsers 指令限定可远程登录的账号白名单，避免测试账号或服务账号被暴力破解。第三，确认防火墙（firewalld或iptables）仅放行你指定的SSH端口。完成后执行 systemctl restart sshd 使配置生效。这些操作在CentOS 7/8、Ubuntu 20.04/22.04上均适用，但注意RHEL 9默认使用的是crypto-policies管理加密套件，修改方式略有不同。基线就绪后，再到Xshell侧新建会话，填入自定义端口和受限用户名，从源头降低未授权访问风险。

xshell相关配图

在Xshell中配置SSH密钥认证并禁用密码登录

密码认证始终存在被撞库的风险，密钥认证才是生产环境的推荐做法。在Xshell 7中，点击菜单栏「工具 → 新建用户密钥生成向导」，密钥类型选择ED25519（相比RSA 2048，签名体积更小且抗侧信道攻击能力更强），设置一个高强度Passphrase保护私钥文件。生成后将公钥导出，通过已有的密码会话上传至服务器 ~/.ssh/authorized_keys，权限设为600。随后回到sshd_config，将 PasswordAuthentication 设为 no 并重启服务。此时在Xshell会话属性 → 认证方法中选择「Public Key」，指定刚才生成的私钥文件即可。一个常见的踩坑点：如果authorized_keys文件的属主不是登录用户本身，或者.ssh目录权限不是700，SSH会静默拒绝密钥认证并回退到密码方式——而你已经禁用了密码，连接就会直接报 Permission denied。

xshell相关配图

真实排障：连接超时与Host Key验证失败

场景一：Xshell提示「Could not connect to 'x.x.x.x' (port 52222): Connection timed out」。排查路径依次为——① 在服务器本地执行 ss -tlnp | grep 52222 确认sshd确实监听了该端口；② 检查云厂商安全组（如AWS Security Group或阿里云安全组）的入站规则是否放行了52222/TCP；③ 本地网络是否有出站端口限制，可用 telnet x.x.x.x 52222 快速验证。90%的超时问题出在安全组或本地防火墙上，而非Xshell本身。场景二：重装系统后再次连接，Xshell弹出「Host Key不匹配」警告。这说明服务器指纹已变更，并非中间人攻击，但你必须与运维确认变更事实后，再到Xshell的「主机密钥管理器」中删除旧指纹并重新接受。切勿养成无脑点击「接受」的习惯，这正是中间人攻击的突破口。

xshell相关配图

会话管理与敏感数据清理

长期使用Xshell后，会话文件中会积累大量服务器地址、用户名甚至缓存的密码。Xshell的会话文件默认存储在 %APPDATA%\NetSarang\Xshell\Sessions 目录下，格式为.xsh纯文本。如果你在会话属性中勾选了「记住密码」，密码会以加密形式写入该文件，但本地加密的安全性取决于Windows用户账户的保护强度。建议的做法是：① 不勾选记住密码，改用密钥认证；② 定期审计Sessions目录，删除不再使用的会话文件；③ 在共享电脑或跳板机上使用Xshell时，退出前通过「工具 → 清除历史记录」清除命令日志和地址栏记录。对于有合规要求（如等保三级）的团队，还应在Xshell中开启会话日志审计，将操作记录导出至集中日志平台，确保所有远程操作可追溯。

通过隧道转发保护内网服务访问

很多开发者需要通过跳板机访问内网数据库或管理后台，直接暴露这些服务的端口是高危操作。Xshell内置的SSH隧道转发可以解决这个问题。在会话属性 → 「隧道」面板中，添加一条Local转发规则：将本地127.0.0.1:3307映射到内网数据库服务器192.168.1.100:3306。连接建立后，本地MySQL客户端只需连接127.0.0.1:3307，流量会通过加密的SSH通道到达内网数据库，无需在公网开放3306端口。实际使用中需注意：如果隧道建立后本地端口无法访问，先检查Xshell隧道面板中该规则的状态是否为「Open」，再确认本地是否有其他进程占用了3307端口（Windows下用 netstat -ano | findstr 3307 排查）。这种方式同样适用于转发Redis 6379、Elasticsearch 9200等内网服务端口。

常见问题

Xshell连接Linux时密钥认证一直失败，日志显示"server refused our key"，可能的原因有哪些？

最常见的三个原因：① authorized_keys文件权限不是600，或.ssh目录权限不是700，SSH对权限要求非常严格；② 公钥内容在粘贴时被换行符截断，导致格式损坏，建议用Xshell的导出功能直接生成文件再上传；③ sshd_config中设置了AuthorizedKeysFile指向了非默认路径，而你的公钥放在了默认的~/.ssh/下。可在服务器端执行 sshd -T | grep authorizedkeysfile 确认实际路径。

团队多人共用一台跳板机上的Xshell，如何防止会话凭据被他人获取？

首先，所有人应使用各自的Windows域账号登录跳板机，Xshell的会话文件存储在各自的%APPDATA%路径下，天然隔离。其次，禁止在会话中保存密码，统一使用密钥认证且私钥设置Passphrase。最后，通过组策略限制对其他用户%APPDATA%目录的访问权限，并在跳板机上部署操作审计工具记录所有SSH会话行为。

从Xshell 6升级到Xshell 7后，之前保存的会话和密钥还能直接使用吗？

可以。Xshell 7（2023年发布的Build 0110及后续版本）兼容Xshell 6的会话文件格式，首次启动时会提示导入旧版会话。用户密钥文件同样可以直接在新版本中加载。但建议升级后检查每个会话的加密算法设置，Xshell 7默认禁用了部分老旧算法（如diffie-hellman-group1-sha1），如果目标服务器较老可能需要手动启用或升级服务器端OpenSSH版本。

总结

想获取Xshell最新版本或查阅完整的安全配置手册？访问NetSarang官网下载Xshell 7免费教育/家庭版，或查看官方文档了解更多SSH隧道与密钥管理的进阶用法。

相关阅读：xshell连接linux教程，xshell连接linux教程使用技巧，下一代安全终端Xshell 8