企业官网建设流程全解析

1. 新手选 SSH 客户端，不是挑软件，而是搭第一座安全通信桥

刚接触服务器运维、嵌入式开发、或者只是想连上自己家的树莓派、群晖NAS、甚至华为交换机做配置，你大概率会遇到第一个实操门槛：怎么把本地电脑和远程设备“通上话”？这时候，“SSH 客户端”四个字就跳出来了。它不是个 fancy 的图形工具，而是一条加密隧道的入口——所有命令、文件传输、甚至整个远程桌面，都得从这儿钻过去。Xterminal、Xshell、PuTTY、系统终端……这些名字背后，其实是四类完全不同的“隧道施工队”，它们用的材料、施工标准、操作手册、甚至工人培训时长，全都不一样。新手常犯的错，就是盯着图标大小、界面颜色、有没有中文菜单去选，结果装完发现：PuTTY 连不上华为交换机因为缺 SSHv2 支持，Xshell 免费版突然弹窗说“已过期”，Xterminal 在 macOS 上默认不支持密钥自动加载，而系统终端——那个黑乎乎的 Terminal.app 或 gnome-terminal——明明就在那儿，却没人教你怎么配密钥、怎么保存会话、怎么避免输错密码十次被锁。

我带过三十多个零基础学员从 SSH 入门，最深的体会是：选客户端的本质，是在选你和远程世界建立信任关系的第一套动作规范。它决定了你第一次输入ssh user@192.168.1.100时，是看到欢迎信息，还是卡在Permission denied (publickey)；决定了你配置好免密登录后，是能一键连上群晖并自动挂载 NAS 目录，还是每次都要手动ssh-add；更决定了你在调试 Ubuntu 无法连接时，是能快速比对日志里sshd[1234]: Failed password for root和客户端报错是否一致，还是对着黑屏干瞪眼。这四个选项里，没有“最好”，只有“最适合你现在这张工单”。Xshell 对 Windows 用户友好得像开箱即用的家电，但它的免费策略早已收紧；PuTTY 是开源界的活化石，轻量到能塞进 U 盘随身带，可它的会话管理、日志归档、密钥转换全靠手动拼凑；Xterminal 是 macOS 生态里少有的深度整合者，原生支持 Touch ID 解锁私钥、iCloud 同步会话，但国内用户常被“Xterminal 收费吗”这个问题困住——它确实收费，但收费逻辑和 Xshell 完全不同；而系统终端，它不卖授权、不弹广告、不收集数据，但它要求你亲手拧紧每一颗螺丝：从生成ed25519密钥对，到修改~/.ssh/config配置别名，再到用scp -i ~/.ssh/id_ed25519指定密钥上传文件。这不是门槛，而是地基。我建议所有新手，哪怕最终主力用 Xshell，也务必花 20 分钟，在系统终端里完整走一遍密钥生成→公钥部署→免密登录全流程。这一步做完，你才真正理解 SSH 不是“连一下”，而是“认证+加密+通道复用”三位一体的协议落地。

2. 四大客户端核心能力拆解：功能不是越多越好，而是刚好够用

2.1 Xshell：Windows 平台的“全能型老司机”，但免费版已成历史标本

Xshell 由 NetSarang 公司开发，2002 年诞生至今，几乎定义了 Windows 下 SSH 客户端的交互范式。它的核心优势在于对复杂企业环境的深度适配：支持 SSH1/SSH2、Telnet、Rlogin、Serial 多种协议；内置 SFTP 图形化文件传输面板，拖拽即可上传下载；会话管理器能分组保存上百个主机配置，每个会话可独立设置字体、颜色、编码、日志路径；最关键是它对中文显示的支持极为成熟——无论是 CentOS 7 的zh_CN.UTF-8环境变量，还是华为交换机 CLI 中的中文提示符，Xshell 都能准确渲染，不像某些客户端一遇到ls列出的中文文件名就显示乱码方块。但必须直面现实：Xshell 7 及以后版本，个人免费授权已彻底取消。官网明确标注：“Home & School License is no longer available.”（家庭与学校授权已停止提供）。目前仅剩两种合法使用方式：一是购买商业授权（单用户约 70 美元/年），二是使用 Xshell 6 的最后一个免费版本（v6.0.0150），但该版本已于 2021 年停止更新，存在已知漏洞（如 CVE-2021-43803），且不支持现代加密算法（如curve25519-sha256）。我实测过，用 Xshell 6 连接启用了KexAlgorithms curve25519-sha256,ecdh-sha2-nistp256的 Ubuntu 22.04 服务器，会直接报错no matching key exchange method found。这意味着，如果你的服务器管理员遵循 CIS 基准加固了 SSH 配置，Xshell 6 就连不上。所以现在谈 Xshell，本质是在谈一个“功能完备但授权受限”的方案。它的价值不在免费，而在稳定性和生态兼容性——当你需要同时管理 20 台不同厂商的网络设备（思科、华为、H3C），且每台设备的 Telnet/SSH 端口、认证方式、超时策略都不同，Xshell 的会话模板和宏脚本功能，能帮你省下每天半小时的重复操作。但对纯 Linux 服务器运维的新手，它的学习成本远高于收益。

2.2 PuTTY：开源界的“瑞士军刀”，轻量到极致，复杂到骨髓

PuTTY 是 Simon Tatham 于 1997 年编写的开源项目，其设计哲学是“只做一件事，并做到极致”：建立安全的终端连接。它不内置文件传输（需额外搭配 PSFTP 或 PSCP），不提供图形化会话管理（所有配置靠.reg注册表或putty.exe -load "session_name"命令行调用），甚至连密钥格式都只认.ppk（PuTTY Private Key）。这种极简主义带来了无与伦比的轻量性：主程序putty.exe仅 700KB，无需安装，双击即用，U 盘拷贝就能带走。但代价是，所有高级功能都得靠“手工焊接”。比如实现免密登录：你需要先用 PuTTYgen 工具将 OpenSSH 格式的id_rsa私钥转换为.ppk格式；再在 PuTTY 配置窗口的 Connection → SSH → Auth 中，指定.ppk文件路径；最后在 Connection → Data 中填入用户名。三步缺一不可，且任何一步出错（如 PuTTYgen 保存时未勾选“Save private key”），连接就会失败。又比如保存会话日志：PuTTY 默认不记录，必须手动进入 Logging 设置页，选择“Printable output”并指定日志文件路径，否则所有ls -la输出都随窗口关闭而消失。它的最大优势在于对老旧设备的兼容性——我曾用 PuTTY 成功连接一台运行 VRP5.7 的华为 S5700 交换机，该设备仅支持 SSHv1 协议，而 Xshell 7 和 Xterminal 均已弃用 SSHv1。但它的致命短板是跨平台体验割裂：Windows 版本功能完整，macOS/Linux 版本（PuTTY-CAC）则长期停滞，社区维护乏力。对于新手，PuTTY 是一把锋利的手术刀，适合精准解决单一问题（如紧急修复某台服务器），但不适合作为日常主力工具——因为每一次新会话的配置，都是对耐心的消耗。

2.3 Xterminal：macOS 的“原生级玩家”，无缝融入系统，但付费模式易误解

Xterminal 是专为 macOS 设计的 SSH 客户端，由开发者 Alexey Kuznetsov 开发。它最大的特点是深度绑定 macOS 系统能力：会话配置存储在~/Library/Application Support/Xterminal/，与系统钥匙串（Keychain）集成，私钥密码可由 Touch ID 自动填充；支持 iCloud 同步会话列表，换 Mac 无需重新导入；终端窗口可设置为“画中画”模式悬浮在其他应用之上；甚至能通过快捷键Cmd+Shift+T快速新建标签页并自动连接预设主机。这些体验，是 Xshell 或 PuTTY 在 macOS 上永远无法复制的。关于“Xterminal 收费吗”的疑问，答案很明确：它采用一次性买断制，当前版本（v5.x）售价 19.99 美元，无订阅、无隐藏费用、无功能阉割。这和 Xshell 的年费模式、VS Code 的免费开源模式形成鲜明对比。很多用户误以为“收费=不划算”，实则不然。我对比过 Xterminal 与 macOS 自带 Terminal 的密钥管理效率：在 Terminal 中，每次重启后ssh-add -K ~/.ssh/id_ed25519都需手动执行，且密码需反复输入；而 Xterminal 首次添加私钥时，会自动将其存入钥匙串，并勾选“始终允许”，后续所有会话均自动解锁。这个细节节省的，是每天数十次的重复操作。它的局限性在于生态封闭：仅支持 macOS（最低版本 12.0 Monterey），无 Windows/Linux 版本；不支持 SFTP 图形界面，文件传输需依赖命令行scp或rsync；对非 UTF-8 编码的旧系统（如部分嵌入式设备）中文显示偶尔有偏移。但对于主力使用 Mac 的开发者、运维工程师，Xterminal 不是“另一个 SSH 工具”，而是 Terminal.app 的增强插件——它让你在保持命令行纯粹性的同时，获得图形化工具的便利。

2.4 系统终端：操作系统自带的“裸金属引擎”，零成本，高自由度，但需亲手组装

Windows 的 PowerShell / Command Prompt、macOS 的 Terminal.app、Linux 的 gnome-terminal / konsole，这些系统终端不是“SSH 客户端”，而是承载 SSH 协议的通用外壳（Shell）。它们本身不提供 SSH 功能，但通过调用系统内置的 OpenSSH 客户端（Windows 10 1809+、macOS 10.14+、主流 Linux 发行版均已预装），实现了最底层的连接能力。这意味着：它没有 GUI 配置界面，所有参数都通过命令行传递；它不保存会话历史（除非你手动配置~/.bash_history）；它不提供一键日志导出，但可通过script命令或重定向>实现更灵活的日志控制。它的核心价值在于绝对可控与零依赖。例如，当你的服务器因磁盘满导致sshd服务崩溃，唯一能救场的，往往是另一台机器上干净的系统终端——因为你不需担心客户端软件版本、许可证、或图形库缺失。我处理过一次 Ubuntu 20.04 服务器 SSH 无法连接的故障，排查发现是/var/log分区 100% 占用，sshd进程因无法写日志而退出。此时，用 PuTTY 连接只会显示Connection refused，毫无线索；而用系统终端执行ssh -vvv user@server，详细日志会明确指出debug1: connect to address 192.168.1.100 port 22: Connection refused，结合telnet 192.168.1.100 22测试端口不通，就能快速锁定是服务未运行而非网络问题。新手畏惧系统终端，往往源于对命令行的陌生。其实只需掌握三个命令，就能覆盖 80% 场景：ssh -i ~/.ssh/id_rsa user@host（指定密钥连接）、scp -i ~/.ssh/id_rsa local_file user@host:/remote/path（上传文件）、ssh -L 8080:localhost:80 user@host（本地端口转发）。这些命令的参数逻辑高度统一，学会一个，其余触类旁通。它不提供捷径，但铺就了通往深度运维的唯一正道。

3. 实操决策树：按场景匹配，拒绝盲目跟风

3.1 场景一：Windows 用户 + 管理多品牌网络设备（华为/思科/H3C）

如果你的工作日常是登录十几台不同型号的交换机、路由器做配置备份、批量升级、故障排查，那么Xshell 是现阶段最务实的选择，但必须接受其商业授权前提。原因在于：网络设备厂商的 CLI（Command Line Interface）存在大量非标实现。例如华为设备的display current-configuration命令输出含中文，且分页符为--- Press ENTER to continue ---；思科设备的show running-config则使用--More--；H3C 设备又可能用Space to continue, Q to quit。Xshell 内置的“回车发送”、“自动换行”、“分页识别”等高级会话选项，能自动适配这些差异，确保Ctrl+C能中断分页，Enter能继续翻页。而 PuTTY 需要手动在 Terminal → Keyboard 中勾选“Auto wrap mode on initial terminal size”，再在 Connection → Data 中设置“Terminal-type string”为xterm-256color，稍有不慎就会卡在分页提示符不动。实操步骤如下：

1. 从官网下载 Xshell 7 安装包（注意：勿从第三方下载站获取，存在捆绑软件风险）；
2. 安装时取消勾选“Install additional software”；
3. 启动后，点击左上角“文件”→“新建”，在“连接”页填写主机 IP、端口（通常 22）、协议（SSH）；
4. 在“用户身份验证”页，选择“Public Key”，点击“浏览”选择.ppk或 OpenSSH 格式私钥；
5. 关键一步：点击“连接”前，进入“终端”→“高级”页，勾选“Enable xterm mouse reporting”（启用鼠标报告），这能让tmux或vim的鼠标操作正常工作；
6. 保存会话名为Huawei_S5700_Core，后续可一键连接。

提示：Xshell 的“宏”功能可自动化备份操作。例如，创建宏命令display current-configuration | include sysname，绑定到快捷键F5，每次按下即自动执行并保存输出到本地文件。这是 PuTTY 或系统终端无法原生实现的效率提升。

3.2 场景二：macOS 用户 + 主力开发/运维 Linux 服务器

对于 MacBook 用户，Xterminal 是最优解，但必须配合系统终端打基础。Xterminal 的优势在于无缝整合，但它的“智能”依赖于你对底层 SSH 机制的理解。例如，Xterminal 的“自动密钥加载”功能，实际是调用ssh-add -K命令并将密码存入钥匙串。如果你从未在系统终端中执行过ssh-keygen -t ed25519 -C "your_email@example.com"生成密钥，Xterminal 就无法加载任何密钥。因此，我的建议是两步走：

• 第一周：强制使用系统终端完成所有操作。生成密钥ssh-keygen -t ed25519，将公钥cat ~/.ssh/id_ed25519.pub复制到服务器~/.ssh/authorized_keys，测试ssh -i ~/.ssh/id_ed25519 user@server；
• 第二周起：切换至 Xterminal，导入已生成的密钥，开启“自动解锁”选项，享受 Touch ID 便捷性。 Xterminal 的独有能力在此场景下凸显：它支持“会话分组”，可将生产环境、测试环境、本地虚拟机分组管理；支持“窗口布局”，一个窗口内并排打开 3 个标签页，分别连接web-server、db-server、cache-server，用Cmd+Option+方向键快速切换；更关键的是，它能正确解析~/.ssh/config文件。例如，在~/.ssh/config中写入：

Host prod-web HostName 192.168.10.100 User admin IdentityFile ~/.ssh/id_ed25519 ForwardAgent yes

Xterminal 会自动识别prod-web别名，无需在 UI 中重复填写 IP 和用户。而 PuTTY 在 macOS 上无法读取此文件，Xshell 则需手动导入配置。这种与 OpenSSH 标准的深度兼容，让 Xterminal 成为 macOS 生态中真正的“第一公民”。

3.3 场景三：Linux 用户 / 极简主义者 / 安全敏感型用户

如果你使用 Ubuntu、Fedora 或 Arch Linux，或你信奉“越少的软件，越少的攻击面”，那么系统终端 + OpenSSH 原生命令，是唯一推荐方案。Linux 发行版预装的 OpenSSH 客户端，版本通常与系统内核深度绑定，安全性更新及时。例如 Ubuntu 22.04 的openssh-client包，会随apt upgrade自动更新，修复如CVE-2023-25136（SSH 连接拒绝服务漏洞）等高危问题。而第三方客户端如 Xshell，其更新节奏取决于厂商，存在安全滞后风险。实操中，我推荐构建一套最小化但高效的命令集：

• 连接：ssh -o ConnectTimeout=10 -o ServerAliveInterval=60 user@host（设置连接超时 10 秒，心跳间隔 60 秒，防假死）；
• 文件传输：rsync -avz -e "ssh -i ~/.ssh/id_ed25519" ./local_dir/ user@host:/remote_dir/（比scp更快，支持断点续传）；
• 端口转发：ssh -N -f -L 8080:localhost:3000 user@host（后台静默监听本地 8080，转发到远程 3000 端口，-N表示不执行远程命令，-f表示转入后台）；
• 多路复用：在~/.ssh/config中添加：

Host * ControlMaster auto ControlPath ~/.ssh/sockets/%r@%h:%p ControlPersist 4h

这样，首次ssh host1建立连接后，后续ssh host1、ssh host2会复用同一 TCP 连接，大幅降低延迟。这些能力，全部基于 OpenSSH 标准，无需额外软件，且文档齐全（man ssh_config）。新手常问“Ubuntu 系统打不开终端”，实则是误操作导致gnome-terminal崩溃。解决方案极其简单：按Ctrl+Alt+T快捷键，或在活动概览中搜索 “Terminal”，或执行xterm（备用终端）启动。记住，系统终端不是“备胎”，而是 Linux 世界的原生语言。

3.4 场景四：临时应急 / 教学演示 / 跨平台协作

当你要在朋友的 Windows 电脑上快速调试一台树莓派，或在公司会议室用投影仪演示 SSH 连接过程，或需要向同事分享一个可复现的连接脚本时，PuTTY 是无可替代的“便携式救火队员”。它的.exe文件可直接运行，不依赖 .NET Framework 或 Visual C++ 运行库（Xshell 需要），在老旧 Windows XP 或精简版系统上依然可用。更重要的是，PuTTY 的配置可完全导出为.reg文件，包含所有会话参数、密钥路径、字体设置。例如，导出一个raspberrypi.reg文件，双击导入后，所有配置即刻生效，无需逐项设置。这对于教学场景极为友好：你可以提前配置好raspberrypi会话，包含正确的 IP、端口、用户名、.ppk密钥路径，保存为.reg文件发给学员，他们双击导入就能开始实操，避免在课堂上浪费时间调试连接参数。实操要点：

• 从官网https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html下载putty-64bit-0.79-installer.msi（最新稳定版）；
• 安装时勾选“PuTTY”, “PSFTP”, “PSCP”, “PuTTYgen” 全部组件；
• 用 PuTTYgen 生成密钥时，选择 “Ed25519” 算法（比 RSA 更快更安全），长度 256 bits；
• 保存私钥为raspberrypi.ppk，公钥复制到树莓派~/.ssh/authorized_keys；
• 在 PuTTY 配置中，Connection → Data → Auto-login username 填pi，Connection → SSH → Auth → Private key file for authentication 选raspberrypi.ppk；
• 点击 “Save” 保存会话名为RaspberryPi，后续双击putty.exe即可加载。

注意：PuTTY 的日志功能需手动开启。进入 Session → Logging，选择 “All session output”，指定日志路径（如C:\logs\pi.log），否则所有操作痕迹不会留存。这是新手最容易忽略的排查依据。

4. 避坑指南：那些官方文档不会告诉你的实战陷阱

4.1 密钥格式陷阱：OpenSSH 与 PuTTY 的“方言”不通

OpenSSH（系统终端、Xterminal、Xshell 7+）默认使用PEM或OpenSSH格式私钥（如id_rsa），而 PuTTY 只认.ppk格式。新手常犯的错误是：用ssh-keygen生成id_rsa，直接拖进 PuTTY 的 Auth 设置，结果连接失败。根本原因是 PuTTY 无法解析 PEM 格式。解决方案必须经过 PuTTYgen 转换：

1. 打开 PuTTYgen；
2. 点击 “Load”，选择id_rsa文件（注意文件类型下拉框需选 “All Files”）；
3. PuTTYgen 会提示 “This is not a PuTTY private key file” —— 这是正常提示，点击 “Yes” 强制加载；
4. 加载成功后，点击 “Save private key”，保存为id_rsa.ppk；
5. 在 PuTTY 的 Auth 设置中，指定此.ppk文件。 反向转换（.ppk→ OpenSSH）同样可行，但需借助 PuTTYgen：加载.ppk后，点击 “Conversions” → “Export OpenSSH key”，保存为id_rsa_openssh。这个转换过程不是简单的文件重命名，而是密钥格式的重新编码，涉及 ASN.1 结构解析，手动编辑必然失败。

4.2 中文显示乱码：字符集与终端类型的双重校验

在 Windows 上用 Xshell 连接 CentOS 服务器，ls列出的中文文件名显示为??，这是典型字符集不匹配。根源在于：服务器端locale设置为zh_CN.UTF-8，但 Xshell 的终端类型（Terminal-type）未正确声明。解决方案分两步：

• 服务器端确认：执行locale，确保LANG=zh_CN.UTF-8；若为en_US.UTF-8，执行localectl set-locale LANG=zh_CN.UTF-8并重启sshd；
• Xshell 端设置：进入会话属性 → 终端 → 高级 → Terminal-type string，改为xterm-256color（而非默认的xterm）。因为xterm-256color明确声明支持 256 色和 UTF-8，而旧版xterm可能回退到 ISO-8859-1 编码。 同理，macOS 系统终端连接 Ubuntu 时乱码，需检查~/.bashrc中是否设置了export LANG=en_US.UTF-8，应改为export LANG=zh_CN.UTF-8。PuTTY 则需在 Window → Translation → Remote character set 中选择 “UTF-8”。这是一个典型的“两端协同”问题，单改一端无效。

4.3 免密登录失效：权限设置比密码还严格

配置好公钥后，ssh user@host仍提示输入密码，常见原因并非密钥错误，而是权限问题。OpenSSH 对~/.ssh目录及文件权限有硬性要求：

• ~/.ssh目录权限必须为700（即drwx------）；
• ~/.ssh/authorized_keys文件权限必须为600（即-rw-------）；
• 私钥文件~/.ssh/id_rsa权限也必须为600。 执行ls -ld ~/.ssh和ls -l ~/.ssh/authorized_keys即可验证。若权限过宽（如755或644），OpenSSH 会主动忽略该密钥，日志中显示Authentication refused: bad ownership or modes for directory /home/user/.ssh。修复命令：

chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chmod 600 ~/.ssh/id_rsa

这个规则适用于所有客户端（Xshell、Xterminal、系统终端），是 OpenSSH 协议层的安全强制措施，无法绕过。

4.4 连接超时与拒绝：从网络层到应用层的逐级排查

当ssh user@host报错Connection timed out或Connection refused，新手常直接怀疑客户端。实则需按 OSI 模型自下而上排查：

1. 物理层：ping host_ip，若不通，检查网线、Wi-Fi、防火墙是否拦截 ICMP；
2. 网络层：telnet host_ip 22或nc -zv host_ip 22，若提示Connection refused，说明目标端口无服务监听；若超时，说明网络可达但端口被防火墙屏蔽；
3. 传输层：在目标服务器执行sudo ss -tlnp | grep :22，确认sshd进程是否监听0.0.0.0:22（而非127.0.0.1:22）；
4. 应用层：检查/etc/ssh/sshd_config，确认Port 22、ListenAddress 0.0.0.0、PermitRootLogin yes（若需 root 登录）、PubkeyAuthentication yes均启用，最后执行sudo systemctl restart sshd。 Xshell 的“连接诊断”功能（右键会话 → “诊断”）可自动执行ping和telnet测试，但无法替代服务器端的ss和sshd_config检查。PuTTY 则完全不提供此类辅助，一切需手动。

5. 终极建议：从“选工具”到“建体系”的认知升级

选 SSH 客户端，不该是入门的第一课，而应是入门后的第一份作业。我见过太多人，花三天研究 Xshell 和 PuTTY 哪个更好，却没花十分钟搞懂~/.ssh/config的Host别名怎么写。真正的效率提升，从来不在 GUI 美观度，而在工作流的原子化封装。我的终极建议是：以系统终端为基石，用 Xshell/Xterminal/PuTTY 作为特定场景的加速器，而非替代品。具体执行路径如下：

• 第 1-3 天：只用系统终端。完成ssh-keygen、ssh-copy-id、~/.ssh/config配置、scp文件传输、ssh -L端口转发。目标是脱离 GUI，用命令行解决 100% 的连接需求；
• 第 4-7 天：根据主操作系统，引入一款 GUI 客户端。Windows 用户装 Xshell（接受商业授权现实），macOS 用户装 Xterminal（买断制一次投入），Linux 用户保持系统终端，仅在需要图形化 SFTP 时用filezilla或nautilus的sftp://协议；
• 第 2 周起：构建个人 SSH 工作流。例如，创建~/bin/ssh-prod脚本：

#!/bin/bash ssh -F ~/.ssh/config -J jump-host prod-web

实现跳板机连接；或用tmux创建会话模板，一键打开 Web/DB/Cache 三窗口。这些能力，GUI 客户端永远无法提供，因为它们是命令行生态的原生产物。 最后分享一个真实教训：我曾为一家金融客户部署监控系统，要求所有服务器禁用密码登录，仅允许密钥。当时团队全员使用 Xshell，但未统一密钥格式。结果上线后，3 台服务器因私钥为.ppk格式，sshd无法解析，导致监控 agent 无法推送数据。故障持续 4 小时，根源竟是客户端与服务端的格式鸿沟。这件事让我坚信：工具可以换，但协议标准和操作规范，必须成为团队肌肉记忆。所以，别急着下载 Xshell，先打开你的系统终端，敲下ssh-keygen -t ed25519。这行命令，才是你 SSH 之旅真正的起点。