SSH密钥认证完全指南：从原理、配置到免密登录实战

直接开始写正文。我会以一位长期和Linux服务器打交道的运维/开发博主口吻来写这篇文章，全面覆盖SSH密钥认证从原理、配置到排查的完整链路，结合搜索热词中真实的高频场景（Windows 10连Ubuntu 22.04、MobaXterm、VSCode、虚拟机互通、SSH服务重启、连接被关闭等），输出一篇有实操、有原理、有坑点的高密度博文。

1. 为什么要配密钥认证：告别密码登录的三个真实理由

我先说结论：SSH 密钥认证不是"选配功能"，而是管理 Linux 服务器的基本素养。无论你是维护一台云服务器、几台虚拟机，还是在 Windows 笔记本上远程连接 Ubuntu 22.04 写代码，只要涉及远程登录，密钥认证都应该是你最先配好的那层基础设施。

我见过太多人一开始觉得"输密码也没什么"，直到遇到下面三种情况才开始后悔：

第一，密码本身扛不住暴力破解。如果你的服务器有公网 IP，你去看一眼/var/log/auth.log，大概率能看到一堆来自各个 IP 的 SSH 爆破记录。攻击者用脚本不停地试常见用户名和弱口令，root、admin、ubuntu这类用户名是重点爆破对象。密码哪怕稍弱一点，被撞库只是时间问题。换成密钥认证之后，对方连私钥都没有，暴力破解直接失去意义。

第二，密码认证在传输链路里存在被截获的风险。虽然 SSH 协议本身是加密的，但密码认证需要一个交互过程，你每次连接都要输入一次。而密钥认证是"持证入场"——私钥平时就安静地躺在你的客户端里，连接时自动参与握手，整个过程你不需要手动输入任何敏感信息，从根源上掐断了密码泄露的可能性。

第三，日常效率的提升非常明显。我自己的机器上管着十几台服务器，如果用密码登录，每连一台都要输一次密码，连完还要想着密码分别是啥。配置好密钥之后，ssh root@192.168.1.10一行命令直接进 shell，配合 VSCode Remote-SSH 还能直接在本地写代码、远程编译、远程调试，跟操作本地文件一样顺滑。这种体验用过了就回不去。

这篇博文适合这几类人看：刚接触 Linux 的初学者、需要在 Windows / macOS 笔记本上远程连接服务器的开发者和运维人员、以及在虚拟机里装 Linux 和宿主机互通文件或做实验的学生。我会从密钥的原理讲起，然后给出 Windows、MobaXterm、VSCode 三种客户端配置方式，最后把最容易踩的坑全部列出来。你跟着操作一遍，基本不会再被 SSH 登录折磨。

2. 密钥认证到底在做什么：一次性理清服务器端和客户端的角色

2.1 非对称加密在 SSH 里的实际作用

密钥认证背后是非对称加密，通俗讲就是一对钥匙干两件不同的活：

• 公钥（public key）：可以随便给别人看，它负责加密数据。在 SSH 的场景里，公钥要放到服务器上，给服务器用来"验明正身"。
• 私钥（private key）：必须留在你自己的客户端，绝对不能发给任何人。它负责解密数据，是你身份的最终证明。

我习惯用一个门禁卡来类比：公钥就是门禁系统的读卡器，它只负责识别卡片；私钥才是你手里那张卡。你把读卡器（公钥）装到服务器上，访问时刷一下卡（私钥参与握手），服务器校验通过就放行。整个过程里你的"卡"不需要交出去，所以安全性很高。

一次完整的密钥认证登录，流程大概是这样的：

1. 客户端发起 SSH 连接请求，告诉服务器"我想用密钥认证"。
2. 服务器从authorized_keys文件里找出你预先放好的公钥，用它加密一串随机数据作为"挑战码"，发回给客户端。
3. 客户端收到后，用本地私钥解密这串数据，再把结果返回服务器。
4. 服务器用公钥验证返回的结果是否匹配。匹配，就放行；不匹配，就拒绝。整个过程私钥从未离开客户端。

这个流程解释了一个关键问题：为什么你只要把公钥放到服务器上，别人拿不到你的私钥就不可能登录你的账号。

2.2 密钥生成前必须了解的细节

在动手之前，有几个概念需要先对齐：

• 密钥对分两种常见类型：RSA和Ed25519。几年前的主流选择是RSA 4096，但现在我更推荐Ed25519。它的密钥更短、生成速度更快、安全性更强，而且 OpenSSH 从 6.5 版本就开始支持，绝大多数现代 Linux 发行版都没问题。如果你要连接的服务器是十年前的老系统，再考虑 RSA 不迟。
• 密钥对的默认存放位置：Linux 和 macOS 在~/.ssh/，Windows 在C:\Users\你的用户名\.ssh\。文件名默认是id_ed25519（私钥）和id_ed25519.pub（公钥）。
• ~/.ssh/known_hosts的作用：它记录的是服务器的"指纹"，防止你连接时遭遇中间人攻击。首次连接某台服务器时，SSH 会提示你确认指纹，确认后会写入这个文件，之后再连接就不会再问。

多说一句，密钥认证解决的是"免密登录"的问题，但它和sudo的密码不是一回事。你通过密钥登录服务器后，执行sudo命令时如果系统要求输入当前用户的密码，那还是要输的。这是两个层面的认证，别混了。

3. 服务器端初始化：从生成密钥对到部署公钥

3.1 检查现有密钥，避免生成一堆垃圾文件

很多人上手就是ssh-keygen连续回车，结果~/.ssh/里堆了好几个id_rsa、id_ed25519，自己都搞不清哪个对应哪台服务器。我的习惯是：先检查，再生成。

ls -la ~/.ssh/

如果看到id_ed25519和id_ed25519.pub已经存在，而你又明确知道它的用途，就不用重新生成。如果你不确定这把密钥是什么时候建的、是否泄露过，那就果断删掉重新生成，别留着不明确的私钥。

3.2 用 ssh-keygen 生成一对新密钥

确认没有旧密钥之后，执行生成命令：

ssh-keygen -t ed25519 -C "my-laptop-2024"

参数说明：

• -t ed25519：指定密钥类型。如果服务器比较老，可以换成-t rsa -b 4096。
• -C "my-laptop-2024"：加一个备注信息，通常写"这是哪台机器上的密钥"。这个备注会写到公钥文件末尾，方便你在服务器的authorized_keys里区分不同客户端的公钥。

执行后系统会问你要把密钥保存在哪里，默认是/home/你的用户名/.ssh/id_ed25519，直接回车即可。接着会提示你输入 passphrase（口令），这里我单独强调一下：

passphrase 可以不设，直接回车跳过。如果你设了口令，每次连接 SSH 都要手动输入一次，就失去了"免密"的体验。但如果是放在公用电脑上的密钥，我建议你设一个，牺牲一点便利换来安全性。我自己的做法是：个人笔记本上的密钥不设 passphrase，家里台式机上的设了，反正那台机器用得少，多输一次无所谓。另外，配置好 passphrase 之后可以用ssh-agent临时缓存口令，第一次手动输入后，后续连接就不用再输了。

3.3 把公钥部署到服务器：两种方法都给你

生成密钥对之后，公钥文件id_ed25519.pub的内容需要追加到服务器的~/.ssh/authorized_keys里。这步做不对，后面全白搭。

方法一：用 ssh-copy-id（Linux 和 macOS 首选）

如果你本机是 Linux 或 macOS，或者 Windows 自带的 OpenSSH 客户端里也有这个命令，直接执行：

ssh-copy-id -i ~/.ssh/id_ed25519.pub 用户名@服务器IP

如果服务器用的不是默认 22 端口，加-p参数：

ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 22022 用户名@服务器IP

这个命令会自动把公钥追加到服务器的authorized_keys文件里，全过程只需要你输一次远程服务器的登录密码，之后就再也不用了。

方法二：手动追加（Windows 上没有 ssh-copy-id 时的通用做法）

这个方法更通用，也更能帮你理解背后的原理。首先在本地查看公钥内容：

cat ~/.ssh/id_ed25519.pub

记下整行内容，它的格式大概是这样：

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJa123... my-laptop-2024

然后用 SSH 登录服务器，依次执行：

mkdir -p ~/.ssh chmod 700 ~/.ssh echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJa123... my-laptop-2024" >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys

我见过很多人在这步偷懒，直接把公钥内容粘到authorized_keys里就完事，结果权限不对（比如目录是 755、文件是 644），SSH 服务会出于安全考虑直接忽略这个文件，表现就是"明明配好了还是让输密码"。

3.4 验证是否配置成功

部署完成后不要立刻关掉当前连接，先在另一个终端窗口试一下：

ssh 用户名@服务器IP

如果直接进入了 shell 而没让你输密码，说明公钥部署成功。这个时候再想关闭密码登录才有底气。千万不要在确认密钥能登录之前就去改 sshd 配置，否则你很可能把自己锁在外面。

3.5 批量服务器场景的经验

如果你管理的服务器不止一台，手动重复上面的操作会非常痛苦。我的做法是先在自己笔记本上配好密钥，然后用一台跳板机配合ssh-copy-id循环脚本或 Ansible 批量分发公钥。简单场景下，一个for循环就够用：

for ip in 192.168.1.10 192.168.1.11 192.168.1.12; do ssh-copy-id -i ~/.ssh/id_ed25519.pub root@$ip done

搜索热词里有个"ssh批量登录"，说的就是这个场景。批量分发的核心仍然是"先把公钥安全地放到目标机上"，脚本只是帮你省了重复劳动。注意第一次分发时仍然需要输密码，这是无法绕过的——你总得通过某种方式把公钥首次放到服务器上。

4. 客户端实操：Windows、MobaXterm、VSCode 三种最常用的免密登录方案

密钥配置成功之后，真正的挑战在于"从不同的客户端工具去用它"。下面是我自己在实际工作中用过的几种方案，挨个说。

4.1 方案A：Windows 自带 OpenSSH + PowerShell（最轻量）

Windows 10 和 Windows 11 都内置了 OpenSSH 客户端，不需要装任何额外软件。打开 PowerShell 或 CMD，直接尝试连接：

ssh 用户名@服务器IP

如果你的密钥文件名是默认的id_ed25519，且放在C:\Users\你的用户名\.ssh\下，SSH 会自动加载，无需额外指定。如果你用了自定义文件名，比如id_ed25519_company，需要手动指定：

ssh -i C:\Users\你的用户名\.ssh\id_ed25519_company 用户名@服务器IP

这里有个 Windows 特有的小坑：私钥文件的权限。Windows 自带 OpenSSH 对私钥文件的 ACL 权限非常敏感，如果你从别处拷贝了一个私钥文件到.ssh目录，它可能会报 "Permissions for 'id_ed25519' are too open" 的错误。解决办法是在文件属性里把除了当前用户之外的所有用户权限都删掉，或者在 PowerShell 里用icacls命令处理。我自己更推荐直接用ssh-keygen在 Windows 上生成密钥，而不是从别的机器拷贝，能少踩一个坑。

4.2 方案B：MobaXterm 图形化配置

MobaXterm 是 Windows 上非常好用的 SSH 客户端，界面直观，支持会话保存。第一次用 MobaXterm 连接服务器时，它会要求你输入密码。登录后，MobaXterm 也能配置密钥。

有两条路可以走：

路线一：让 MobaXterm 使用你已经在 Windows 上生成好的密钥。打开 MobaXterm 的 Settings --> SSH，在 "SSH key" 一栏选择你已经存在的私钥文件路径，保存后再新建会话连接，就能免密登录。

路线二：在 MobaXterm 里直接生成密钥。打开 Tools --> MobaKeyGen，点击 Generate 生成一对密钥，把公钥部署到服务器后，再回到 SSH settings 里加载私钥。

我个人的经验是：如果你平时 Windows 下开发为主、也会用到命令行工具，不如直接用系统自带 OpenSSH 生成密钥，这样 MobaXterm、VSCode、Git 都能共用同一把密钥，不用每把钥匙重新弄一次。MobaXterm 适合那些喜欢图形界面、需要管理很多会话的人，但密钥最好还是"一套密钥走天下"。

4.3 方案C：VSCode Remote-SSH，把远程服务器当本地用

VSCode 的 Remote-SSH 插件是开发者的神器，装好插件后，打开 VSCode，按F1输入 "Remote-SSH: Connect to Host"，输入用户名@服务器IP，VSCode 就会在远程服务器上启动一个 VSCode Server，你写代码、看日志、跑命令全在服务器上完成，体验和本地开发几乎一致。

要让 Remote-SSH 免密连接，前提仍然是你本机能用密钥免密登录服务器。VSCode 会调用你系统里的 SSH 客户端和密钥，所以只要你的命令行ssh能免密连上，VSCode 就能免密连上。

遇到 Remote-SSH 连不上时，先回到命令行验证一下 SSH 本身是否通，不要直接怀疑是 VSCode 的问题。我见过太多人 VSCode 报错就到处查，结果发现是服务器端 SSH 服务挂了或者 IP 变了。

4.4 方案D：PuTTY + Pageant（老牌工具的特殊处理）

如果你用 PuTTY，有一点必须注意：PuTTY 不认 OpenSSH 的私钥格式，它要求.ppk格式的私钥。你需要先用 PuTTYgen（PuTTY 安装包自带）导入 OpenSSH 私钥，再导出为.ppk格式，才能被 PuTTY 使用。

另外，PuTTY 可以通过 Pageant（一个后台密钥代理程序）来加载密钥，加载之后所有 PuTTY 会话都能自动使用这把钥匙。这种"代理"模式的好处是私钥只加载一次，不用每个会话都指定文件。

不过如果你不是非 PuTTY 不可，我建议尽量用 Windows 自带 OpenSSH 或 MobaXterm，省去格式转换的麻烦。

5. 加固服务器：关闭密码登录前后的安全边界

密钥认证配好后，要不要关闭密码登录？我的答案永远是：要关，但要在正确的时间关。

5.1 关闭密码登录的完整步骤

登录服务器后，编辑 SSH 配置文件：

sudo vim /etc/ssh/sshd_config

核心要改或确认这几个参数：

PubkeyAuthentication yes PasswordAuthentication no PermitRootLogin prohibit-password ChallengeResponseAuthentication no UsePAM no

逐条说一下我的理解：

• PubkeyAuthentication yes：开启公钥认证。默认就是 yes，但显式写出来更清楚。
• PasswordAuthentication no：关闭密码认证。这是"禁止密码登录"的关键开关。
• PermitRootLogin prohibit-password：允许 root 通过密钥登录，但禁止 root 用密码登录。这个比完全禁止 root 登录安全很多，也方便管理。
• ChallengeResponseAuthentication no：关闭挑战响应认证，防止某些细节上绕过了密码策略。
• UsePAM no：这个要小心。PAM 可能会干扰密钥认证流程，但某些系统上关闭 PAM 可能导致其他问题。我建议第一次配置时先不动它，等基础功能稳定后再按需调整。

改完之后先检查语法：

sudo sshd -t

没有任何输出就说明语法没问题。然后重启 SSH 服务：

sudo systemctl restart sshd # CentOS / RHEL / Rocky sudo systemctl restart ssh # Ubuntu / Debian

搜索热词里有人问 "sudo systemctl restart ssh" 到底对不对，其实两者都行，区别在于你的系统把服务名注册成了sshd还是ssh。Ubuntu 系通常是ssh，RedHat 系通常是sshd。你可以用systemctl status ssh或systemctl status sshd去看哪个是存在的，再重启对应的服务。

5.2 我踩过的坑：改完配置后把自己锁在门外

这是几乎所有运维都经历过的惨痛教训。我自己最少遇到过三次，原因各不相同：

第一次，我在一台 CentOS 8 服务器上把PasswordAuthentication改成 no，然后重启了 sshd，但当时我用的连接就是密码登录，而且密钥还没在 authorized_keys 里。重启完我试着再连，直接拒绝。好在当时云服务商有网页版的 VNC 控制台，我从控制台进去把配置改回来的。你要是没有这种"后门"，就等着重装系统吧。

第二次，我在 Ubuntu 上用sudo systemctl restart ssh把服务重启了，结果 SSH 直接卡死，新连接全超时。排查下来发现原因是当时/etc/ssh/sshd_config里有个不知什么时候加进去的ListenAddress配错 IP，sshd 启动失败。从那以后，我每次改配置都会先sudo sshd -t检查一遍，再重启，而且永远保留着一个已登录的会话窗口，万一新连接失败还能补救。

第三次教训是千万别把PermitRootLogin设成 no 之前不确认自己有一个普通用户的密钥能登录。root 登录被禁了，你手里只有 root 的密钥，普通用户又没配置，结果就是谁也登不上去。

5.3 关于安全加固的一句话总结

关闭密码登录之前，请你务必逐项确认：

1. 你现在至少有一个用户能用密钥免密登录。
2. 你已经验证过重启 SSH 服务后密钥登录依然有效。
3. 你有服务器控制台的访问权限，可以作为最后的后路。
4. 改配置只改一次，每改一个关键项都重启一次并测试一次，别攒一堆改动再重启，出问题都不好定位。

6. 常见问题排查实录：从原理入手，别瞎猜

搜索热词里关于 SSH 的问题非常多，我把最典型、最高频的几个集中整理在这里，每一条都是我自己或身边人实际遇到过的。

6.1 公钥已经部署到 authorized_keys，为什么还是要输密码？

这是出现频率最高的问题。按这个顺序排查：

1. 先确认你用的是不是正确的那把私钥。如果你在 Windows 上有多套密钥，可能连接时用了默认密钥，而你部署到服务器的公钥是另一套。用ssh -v连接，会在日志里看到 "Offering public key: ..." 之类的信息，确认它尝试的私钥是哪一把。
2. 检查服务器上的权限。~目录权限不能超过 755，~/.ssh目录必须是 700，~/.ssh/authorized_keys必须是 600。执行：

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

3. 检查公钥内容是否完整。把id_ed25519.pub里的内容复制到 authorized_keys 时，保证是一整行，没有换行、没有多余空格。
4. 看 SSH 服务端日志。执行sudo journalctl -u ssh -f或sudo tail -f /var/log/auth.log，再发起一次连接，日志里会明确告诉你公钥认证失败还是被忽略。这是最直接的定位手段。

6.2 重启服务器后密钥登录失效了，报 "Permission denied (publickey)"

如果你确认 authorized_keys 里公钥还在，权限也没问题，那多半是服务器上的 SSH 服务没有正确读到 authorized_keys。常见原因有两个：

第一，SELinux 上下文被重置。这主要发生在 CentOS / RHEL / Rocky 等带 SELinux 的系统上，你把authorized_keys文件从别处复制过来，或者文件是手动创建的，SELinux 的上下文类型不对，sshd 会拒绝读取。检查并修复：

restorecon -Rv ~/.ssh

第二，StrictModes导致的问题。sshd 默认开启StrictModes yes，即检查~、~/.ssh、~/.ssh/authorized_keys是否是"该用户自己的"，所有权不对也会拒绝。确保这些文件 owner 是当前用户，而不是 root。

6.3 连接报错 "connection closed by 127.0.0.1" 或直接断连

这类报错很常见于你使用了端口转发、内网穿透或跳板机。搜索热词里有一条ssh -p 12062 [e-mail] ... connection closed by 127.0.0.1，这种场景多半是通过内网穿透工具（比如 cpolar、frp 之类）映射到内网服务器时，连接被隧道端关闭。

排查思路：

• 先确认穿透服务本身在线，隧道两端配置是否匹配。
• 再用ssh -v看是哪一步断的。是在端口转发阶段断的，还是到了目标服务器才断的，区别很大。
• 有些内网穿透工具的免费隧道会限制连接时长或流量，连接建立后很快被切断也是常事。

这种情况下密钥认证本身可能没问题，是网络链路的问题。我的建议是先把穿透服务排障做好，再去怀疑 SSH 配置。

6.4 提示 "the ssh or sshd service is unavailable"

这个报错一般出现在 Windows 上，因为 Windows 的 OpenSSH 既有客户端也有服务端，报错信息里的 "sshd service" 通常是指 Windows 的 sshd 服务。如果你只是远程连接 Linux 服务器，不需要在 Windows 上启动 sshd 服务，这个报错不影响你的客户端连接。

如果是你在一台 Linux 服务器上看到类似提示，那就是 SSH 服务没起来或启动失败。检查：

systemctl status sshd sudo systemctl start sshd journalctl -u sshd -n 50

一个常见原因是/etc/ssh/下的 host key 文件权限不对或丢失，sshd 启动报错。此时可以重新生成 host key：

sudo ssh-keygen -A sudo systemctl restart sshd

6.5 Git 仓库提示 SSH 认证失败

很多 Windows 开发者在把代码推到 GitHub / GitLab 时也会用到 SSH 密钥，但这里有一个概念要分清：SSH 密钥认证解决的是"连接"层面的认证，Git 平台还要知道你是"谁"。以 GitHub 为例，你连接时用的用户名固定是git：

ssh -T [e-mail]

如果返回 "Hi xxx! You've successfully authenticated"，说明密钥生效。如果失败，检查你当前正在使用哪把私钥连接到 GitHub。Git 客户端默认用~/.ssh/id_ed25519，如果你生成密钥时名字不是默认的，需要在~/.ssh/config里单独指定：

Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github

热词里的 "ssh认证失败 git" 和 "windows笔记本给代码仓配置ssh密钥" 说的就是这个场景。注意：Git 平台验证的是你的 SSH 公钥是否绑定到账号，和你 Linux 服务器的 authorized_keys 是两回事，别把公钥搞混了。

6.6 虚拟机里装的 Ubuntu，宿主机怎么 SSH 连不上？

这个问题在热词里出现了好几次，典型原因是网络模式没选对。VMware 或 VirtualBox 里装好 Ubuntu 后，宿主机要连它，有两条路：

• 虚拟机网络模式选桥接模式（Bridge），虚拟机就像局域网里的一台独立设备，宿主机直接ssh 用户名@虚拟机IP即可。
• 选NAT 模式，宿主机需要通过虚拟网卡地址访问虚拟机，或者配置端口转发。

还有一个容易忽略的点：Ubuntu 22.04 默认没装 OpenSSH Server。你在虚拟机里可能能上网，但ssh localhost都提示没有服务。先安装：

sudo apt update sudo apt install openssh-server -y sudo systemctl enable --now ssh

然后确认虚拟机的防火墙放行 22 端口：

sudo ufw allow 22/tcp sudo ufw enable

一切正常后，宿主机执行ssh 用户名@虚拟机IP，就能连上。

6.7 密钥配好了，但 VSCode Remote-SSH 还是每次都要输口令

如果你给密钥设置了 passphrase，又没有加载到 ssh-agent 里，那么即使公钥部署正确，每次连接时 VSCode 也会让你输入私钥口令。解决办法是把私钥加载进 ssh-agent：

eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519

加载时输入一次 passphrase，之后当前会话内都不再要求。如果你希望 Windows 重启后也能自动加载，可以把ssh-add放进启动脚本，或者在 VSCode 设置里开启 Remote-SSH 的 ssh-agent 支持。

7. 快速自查清单：配置完成后一次检查到位

最后给一张清单，帮你把配置流程从头到尾捋一遍。跟着打勾，基本不会漏。

检查项	正确状态	排查手段
本地私钥存在	~/.ssh/id_ed25519存在且权限正确（Windows/Linux/macOS 都适用）	ls -la ~/.ssh/
本地公钥存在	~/.ssh/id_ed25519.pub存在	cat ~/.ssh/id_ed25519.pub
服务器公钥部署	~/.ssh/authorized_keys包含公钥内容	cat ~/.ssh/authorized_keys
服务器目录权限	~/.ssh为 700，authorized_keys为 600	ls -ld ~/.ssh && ls -l ~/.ssh/authorized_keys
服务器 SSH 服务运行	服务 active 状态	systemctl status ssh或sshd
sshd_config 配置	PubkeyAuthentication yes	`sudo grep -E "Pubkey
密钥登录验证	新终端执行ssh 用户@IP直接进入 shell	不输入密码即成功
密码登录关闭（可选）	PasswordAuthentication no，且已验证密钥登录 OK	重启 sshd 后再测试

根据我个人经验，配置过程中最核心的一件事就是：永远在验证新方案成功之后再撤掉旧方案。这和改数据库表结构、更新生产配置是一个道理——先建好逃生通道，再断原来的路。

8. 最后分享一个小技巧：用 ssh config 管理多台服务器

内容聊到这里，我再安利一个常被忽略但很好用的功能：在本地配置~/.ssh/config文件，给每台服务器起个别名。有了密钥认证之后，每次登录输入ssh root@192.168.1.10 -p 2222这种长命令很烦，但在~/.ssh/config里写好之后，只需要ssh web1就进去了。

Host web1 HostName 192.168.1.10 User root Port 2222 IdentityFile ~/.ssh/id_ed25519 Host dev-ubuntu HostName 192.168.1.15 User ubuntu IdentityFile ~/.ssh/id_ed25519

这个配置文件同时适用于系统自带 SSH 客户端、VSCode Remote-SSH、MobaXterm 等大部分工具，配好后免密的体验会再上一个台阶。我自己管理这些服务器时，对每一台服务器的连接参数、密钥对应关系都写在这个 config 文件里，比记在笔记软件里方便得多，换新电脑迁移时直接拷贝整个.ssh目录就行，注意保护好私钥文件即可。