SSH 连接终极指南:从密码到 Tunnel 的连接演进史

你刚买的那台 VPS,上线不到两小时,XXXXXXXXXXXXXXXXX 里已经躺着几千条 SSH 登录失败记录。用户名是 root、admin、test、postgres,密码挨个试。这不是你被谁盯上了,是整个互联网的背景噪声:自动化脚本 7×24 小时扫每一个公网 IP 的 22 端口。

USENIX 2024 年收了一篇论文,作者在 CloudLab 大约 500 台服务器上收了整整 4 年的 sshd 日志。光是其中一个日志段,就记录了 4.27 亿次登录尝试,来自 84 万个不同的攻击 IP。平均下来,每分钟 211 次失败登录,对 25 次成功。那 211 次失败,全是 bots 在敲门。

SSH 是你进服务器的门。这篇讲这扇门怎么从「裸着密码」一路演进到「完全不开门也能进」。我把它拆成 7 个台阶,每个台阶都对应一个真实的、你会遇到的问题。你不需要走到最后一级,但你要知道每一级解决什么、什么时候该升级。

结论先行:你的 SSH 该停在哪一级

把整篇压成一句话,看你的场景:

• 个人单机玩玩:到第 2 级(密钥)就够,密钥加关密码,你已经比八成公网服务器安全
• 机器超过 3 台:加第 3 级(ssh config),大脑轻松一半
• 生产机藏内网:加第 4 级(跳板 ProxyJump),收敛攻击面
• 被爆破日志吵烦:第 5 级(改端口 + 防火墙)降噪,记住它不是安全措施
• 不想开任何端口 / 没 公网 IP:第 6 级(Tailscale / Cloudflare Tunnel 一类),零端口暴露
• 连接老断 / 弱网用:第 7 级(mosh / autossh),给通道加韧性

下面一级一级爬。

---

台阶 ① 密码登录:最原始的信任,也是注定被攻破的信任

你买完 VPS,第一次连:

ssh root@你的服务器IP

输密码,进去了。这是你 SSH 旅程的起点,也应该成为你密码登录的终点。

这一套的本质是什么? 密码系统的信任基础,是「每次登录,你和服务端都把那个秘密原样传一遍」。秘密在网络上走了一趟,服务端比对,对就放行。问题在于:只要秘密被传输,它就可能被猜。暴力破解从来不是「能不能」的问题,是「多久」的问题。算力一直在涨,字典一直在扩。

USENIX 那篇论文给了一个值得玩味的数字:在他们 4 年的日志里,大约 10% 的登录尝试是「成功」的。但成功的几乎全是合法用户(bots 的成功极少,因为合法用户早就用上了密钥或强密码)。换句话说,bots 永远在试,大多数时候试不开。「大多数时候试不开」听起来像安全,其实不是。只要有一次试开,你的服务器就归别人了,而你前面的几万次失败毫无意义。

Reddit 上有个真实案例:有人把树莓派通过家庭路由器端口转发到公网,两周后看了一眼日志,25 万次登录尝试。这不是个例,是常态。

OpenSSH 9.8 起开始用 PerSourcePenalties 累积惩罚机制(每个失败尝试给一个惩罚值,达到阈值就拉黑,默认 XXXXXXXXXXXXXX 内 6 次失败就断,行为类似历史上常见的 XXXXXXXX/XXXXXXXX 模式,但走 sshd 内部,无需外部依赖)。这个限速能挡住笨 bot,挡不住分布式爆破。84 万个 IP 一起来,你的限速就是摆设。

一句话结论:密码登录是信任模型的原始形态。它能用,但它的安全建立在「没人愿意花足够多的时间猜」之上,这不是一个 2026 年还该依赖的假设。

什么时候升级:看到 auth.log 里出现第一条失败记录的那一刻。对绝大多数公网 VPS,这是上线后几分钟内的事。下一级,密钥。

---

台阶 ② 密钥登录:不是更安全的密码,是信任模型的换挡

密码被扫烦了,也怕了。你搜「SSH 怎么更安全」,所有人让你用密钥。

这里有一个流传很广的误解:很多人把密钥理解成「一个很长很难猜的密码」。这个理解是错的,而且会让你低估它真正的价值。

密码的信任基础是「你知道什么」(something you know):秘密同时存在你脑子里和服务器上,每次传输一遍。任何一边泄露,都完蛋。

密钥的信任基础是「你拥有什么」(something you have)。它用的是非对称加密:你本地有私钥,服务器上有对应的公钥。登录时,服务器用一个数学挑战问你,你只有用私钥才能正确回应,而私钥从头到尾不离开你的电脑。整个过程,没有任何秘密在网络上传输。

这是根本不同的两种信任模型。密钥不是把密码变长,是把「传输秘密」这件事从协议里彻底拿掉了。暴力破解对它无效,不是因为密钥太长猜不到,是因为网络上根本没有「可以猜的东西」在走。

算法选哪个:ed25519 是 2026 年新密钥的默认选择,这点业界早已是共识。Mozilla 的 OpenSSH 加固指南把 ed25519 列为推荐算法,2026 年的 SSH 密钥管理最佳实践文档一律建议新密钥用 ed25519,RSA 只在兼容老旧系统时才用(而且要用 4096 位)。ed25519 的好处实实在在:密钥短(一行 base64)、签名快、安全性高。如果你担心兼容性,大可放心,OpenSSH 从 6.5 版(2014 年发布)就支持 ed25519 了,任何还在运行的系统几乎都支持,除非你连的是博物馆里的老机器。RSA 是历史包袱,如果你还在生成新的 RSA 密钥,可以停了。

最小命令:

# 生成密钥对
ssh-keygen -t ed25519 -C "你的标识"
# 把公钥推到服务器
ssh-copy-id root@你的服务器IP

然后关掉密码登录(这才是真正关门):

# /etc/ssh/sshd_config
PasswordAuthentication no
systemctl reload ssh

关掉之后,bots 那 211 次/分钟全部变成无效尝试,因为服务器根本不接受密码。你的 auth.log 会瞬间安静下来,安静到你以为 sshd 坏了。

最常见的坑:权限。sshd 对权限极其敏感,而且出错时它不告诉你。XXXXXX 目录必须 XXX,XXXXXXXXXXXXXXX 必须 XXX,私钥文件必须 XXX。权限不对,ssh 默默拒绝你的密钥,你以为密钥坏了,其实是权限坏了。调试用 XXXXXX 看完整握手过程。

什么时候升级:当你管理的机器超过 3 台,开始记不住哪个 IP 是哪台、哪个用户名、什么端口、用哪把密钥。这时候你需要的不是更多密钥,是第 3 级。

深读:多服务器的密钥分发、轮换、用 ssh-agent 管理 passphrase,见工具箱 #8《SSH 密钥登录配置速查》。

---

台阶 ③ ssh config:从记 IP 到记别名,配置即文档

你现在有 prod-web、prod-db、staging、backup 四台机器。每次连都得敲:

ssh -i ~/.ssh/prod_key -p 2222 [email protected]

打得手酸,还记不住。

这一级的价值被严重低估。 它不是安全升级,是认知减负。

你大脑里其实一直维护着一张连接表:哪台机器、什么 IP、什么用户、什么端口、哪把密钥。这张表存在脑子里,每次连接都要查一遍、输一遍。ssh config 做的事,就是把这张表从你脑子里挪到 XXXXXXXXXXXXX 文件里。一旦外化成文件,它就成了文档:可读、可搜索、可版本控制、可备份。

最小配置 XXXXXXXXXXXXX:

Host prod-web
    HostName 192.168.1.100
    User admin
    Port 2222
    IdentityFile ~/.ssh/prod_key

保存之后,你只要:

ssh prod-web

四个字段浓缩成一个名字。

进阶:通配符让你批量配置。所有生产机共用一套密钥:

Host prod-*
    IdentityFile ~/.ssh/prod_key

机器一多,用 XXXXXXX 拆分文件,工作机器一份、个人机器一份,互不干扰:

Include ~/.ssh/config-work
Include ~/.ssh/config-personal

这一级没有惊心动魄的安全故事,但它决定了你之后每一级的体验。跳板、隧道、保活,到最后都只是在 ssh config 里加几行的事。

什么时候升级:当有些机器你连不上,不是因为它宕机,是因为它在内网,没有公网 IP,你只能先跳到一台堡垒机再进去。这就是第 4 级。

深读:ssh config 完整字段、Include 拆分、多环境管理,见 #9《SSH Config 文件管理》。

---

台阶 ④ ProxyJump 跳板:内网不能直连,跳板的中转逻辑

你的生产数据库没有公网 IP。它只能从堡垒机(bastion)访问。你得先 SSH 到堡垒机,再从堡垒机 SSH 到数据库,两步。每次都这样,累。

生产机藏在跳板后面,不是嫌麻烦,是故意的。 这叫收敛攻击面。

如果生产数据库直接暴露公网,全世界那 84 万个攻击 IP 都能来敲它。把它藏进内网,只让堡垒机这一台能连它,攻击面瞬间从「整个互联网」收缩到「堡垒机一台」。所有进生产区的流量,都从堡垒机这一个口子过,审计、限流、二次认证,在一个地方做完。这是安全架构里的基本操作,叫堡垒主机模式。

老派写法 XXXXXXXXXXXX 还在,但 2026 年你该用更简单的 XXXXXXXXX(XX):

Host db-prod
    HostName 10.0.0.5
    User dbadmin
    ProxyJump bastion

XXXXXXXXXXXXXXXXX 这一行的意思是:连 db-prod 时,先自动连 bastion,再通过 bastion 转发到 10.0.0.5。你仍然只敲 XXXXXXXXXXX,中间的跳转 ssh 替你做了。

一个容易踩的坑:agent 转发。很多人为了让跳板能用本地密钥连下一跳,会开 XXXXXXXXXXXXXXXX。这有风险:任何能读你跳板上 ssh-agent 的人,都能借你的身份连下一跳。更安全的做法就是用 ProxyJump,它不需要 agent 转发,密钥始终留在你本地。

什么时候升级:跳板解决了「内网机器怎么进」,但它仍然要求你在堡垒机上开一个 SSH 端口。如果你连这个端口都不想开,或者你的机器根本不在你能控制网络的范围里(NAT 后面的家用服务器、云上没有公网 IP 的实例),你需要第 6 级,零端口暴露。在那之前,先看第 5 级,因为你大概率会先和「端口」这件事撞上。

深读:多跳连接、堡垒机完整搭建、连接管理最佳实践,见 #15。

---

台阶 ⑤ 端口与防火墙:改端口这件事的真相

你的 auth.log 被爆破刷屏,几万条失败记录。你在论坛问怎么办,最高赞回答永远是:「改个端口就好了。」

这一节我给你一个反直觉的结论,它能帮你省下大量虚假的安全感。

改端口是 security through obscurity(通过隐藏来获得安全)。它的逻辑是:bots 默认扫 22,你换成 22222,bots 就找不到你了。

这个逻辑对一半,错一半。

对的那一半:对那些只会扫 22 的笨 bot,改端口确实有效。有人做过实验,把 SSH 端口从非标准端口改回 22,立刻恢复到每 10 分钟被扫一次、每次 5 次密码尝试的节奏;改回非标准端口后,日志噪声下降 90% 以上。降噪效果是真的,运维舒服了。

错的那一半:对定向攻击者,改端口约等于零防御。XXXX 一个全端口扫描,几秒内把你机器上所有开放端口摸清楚,不管你 SSH 藏在 22 还是 22222。Shodan 这种搜索引擎更是全天候扫描全端口、全网段,你改的端口早被它索引了,任何人花一秒钟就能搜到。

所以正确的结论是:改端口的真实价值是「让日志好看」,不是「让服务器安全」。 它治标(降噪,减轻日志和运维压力),不治本(挡不住任何认真的攻击者)。

那真安全靠什么?靠你在第 2 级已经做的事:密钥登录加关闭密码。一个不接受密码的 SSH 服务,bots 爆破到宇宙尽头也进不来。再加上防火墙:UFW 只放行需要的端口,fail2ban 自动封禁高频失败的 IP。这三件做完,你才是真的安全,端口是 22 还是 22222 都无所谓。

最小命令:

# /etc/ssh/sshd_config 改端口(可选,只为降噪)
Port 22222

# 防火墙:放行新端口,关掉 22
ufw allow 22222/tcp
ufw deny 22/tcp
ufw enable
systemctl reload ssh

我的实话建议:端口改不改随你,降噪有点用,但别把它当安全措施。绝对不要因为「我改了端口」就觉得可以偷懒不上密钥、不配防火墙。那种「封了 80 端口就不用改默认密码」的想法,是攻防史上最常见的虚假安全感,一堆公司栽在这上面。

什么时候升级:你已经上了密钥、配了防火墙、端口也降了噪,但有一个场景这些全解决不了:你的机器根本没有公网 IP,或者你压根不想在公网上开任何端口。这时候要换思路,从「开门放行」跳到「不开门也能进」,第 6 级。

深读:开端口还是 Tailscale、密钥还是密码这道选择题的完整决策,见决策框架 D04。

---

台阶 ⑥ 零端口暴露:不开门也能进(mesh 与反向隧道全谱系)

三种情况,传统 SSH 都束手无策:

• 你的家用 NAS 或实验室机器在 NAT 后面,没有公网 IP,外面连不进来
• 你的云上数据库没有公网 IP,你不想为了 SSH 专门开堡垒机
• 你想把内网的一个 web 服务安全分享给朋友或客户,但不想把端口暴露给整个互联网

前面 5 级,不管你怎么配,底层逻辑都是「开门放行」:你在防火墙上开一个口子,让外面的人进来。第 6 级是一次范式转换,它换成「不开门也能进」:机器主动向外拨号,建立一条出站连接,反向把通道铺回来。inbound 端口零暴露。这一个转换,把攻击面从「我开了几个口子」直接归零。

这条思路下,工具分两大派系,每派里还有自建和托管之分。我给你一张完整的地图:

派系	工具	自建 / 托管	适合谁
WireGuard mesh	Tailscale	托管	个人 / 小团队,装客户端,个人免费(100 设备)
WireGuard mesh	Netbird	开源可自建	想完全掌控控制面、设备数不限、免费
Layer2 overlay	ZeroTier	托管	非老牌、跨层组网(二层网络)
反向隧道	Cloudflare Tunnel	托管免费	web 服务安全暴露给别人,Zero Trust
反向隧道	FRP	自建	有公网服务器、想完全自立
反向隧道	ngrok	托管	临时快速暴露、调试 webhook

mesh 派:私有设备网络

机器之间组一张私有网络,只有「入网」的设备能互相看到。适合你自己或小团队连私有服务。

• Tailscale:基于 WireGuard,托管,装个客户端登个录就能用。个人免费(最多 100 设备),团队 5 美元/用户/月。它是这个领域的事实标准,2025 年 Series C 后估值约 14.5 亿美元,4 万多家付费企业客户(SAP、Hugging Face、Instacart、Duolingo、Datadog、Cloudflare 内部团队都用)。绝大多数个人开发者从这里开始,零配置体验最好。→ Tailscale 官网(含 ittinker 合作链接)
• Netbird:同样基于 WireGuard,但开源,你可以自己架控制面,免费且不限设备数。适合想要完全掌控、不想依赖第三方、或设备数超过 Tailscale 免费额度的场景。
• ZeroTier:更老牌,用的是自己的 Layer 2 协议(不是 WireGuard),相当于在网络上虚拟出一张网卡,所有设备处于同一个二层网络。跨平台稳定,适合需要非 IP 层组网的场景。

反向隧道派:把服务暴露出去

机器主动连到一个中转服务,中转再把流量转回来。适合把内网服务分享给没有装客户端的人。

• Cloudflare Tunnel:免费,Zero Trust 身份验证,自动 HTTPS,抗 DDoS。你把内网的 web 服务挂到 Cloudflare 边缘节点,别人用一个普通 URL 就能访问,背后还有 Cloudflare 的身份层把关。这是把自建服务安全分享出去的事实标准。→ 配置见 #20
• FRP:国人开源,自己架,需要一台有公网 IP 的服务器做中转。灵活、可控、没有第三方依赖,代价是要自己运维中转节点。适合有服务器、想完全自立的场景。
• ngrok:商业服务,免费版有限制。最大的好处是一行命令临时把本地服务暴露出去,调试 webhook、演示 demo 用得最多,不适合长期生产。

怎么选

这张表的关键不是「哪个最好」,是「你的场景落在哪一格」:

• 自己连自己的私有服务,选 mesh,从 Tailscale 开始
• 要把服务分享给没装客户端的人,选反向隧道,从 Cloudflare Tunnel 开始
• 想完全自建、不依赖第三方,选 Netbird 或 FRP

这些工具互不冲突。很多人家里用 Tailscale 连 NAS,对外用 Cloudflare Tunnel 分享服务,两套并存,各管一摊。

什么时候升级:通道铺好了,你能连得上、连得安全、连得隐蔽。但还有一个体验问题没解决:连上之后,过几分钟不动,连接卡死断了;在移动网络下来回切换,SSH 会话直接废。这是第 7 级要解决的,连接的韧性。

深读:每个工具的 5 分钟上手,见 #16 Tailscale / #17 Netbird / #18 ZeroTier / #19 内网穿透对比;Cloudflare Tunnel 完整配置见 #20。

---

台阶 ⑦ 可靠性:连接的韧性层(keepalive / mosh / autossh)

你 SSH 进服务器,跑了个长任务,去倒杯咖啡回来,连接卡死,任务中断。或者你在高铁上用手机热点连服务器,网络一抖,会话直接废了,得重连。

前 6 级解决的是「连得上、连得安全、连得隐蔽」。第 7 级解决「连得稳」。 生产环境的连接必须有韧性:断了自己回来,弱网下还能用。

三个工具,解决三个不同层面的问题:

ServerAliveInterval:防 NAT 超时

大多数「连上几分钟就断」,不是服务器的问题,是中间 NAT 设备的问题。NAT 设备会清理长时间没数据的连接,你倒杯咖啡的时间,正好够它把你的 SSH 会话当垃圾回收掉。解法是加心跳,定期发个空包告诉 NAT「这条连接还活着」:

# ~/.ssh/config
Host *
    ServerAliveInterval 30
    ServerAliveCountMax 3

每 30 秒一个心跳,连续 3 次没回应才判定断线。这一招能解决八成「莫名断连」。

mosh:替代 SSH,断线自动重连

如果你的核心卡点是移动网络、IP 切换、弱网,SSH 本身救不了你,因为 SSH 是 TCP,TCP 连接一断,会话就没了。mosh 用 UDP,关键是它把会话状态做成了可漫游的:你从 WiFi 切到 4G,IP 变了,mosh 会话自动迁过去,你在终端里甚至感觉不到。它还有本地预测回显,高延迟下你敲键盘立刻有反应,不用等服务器绕半个地球回来。

代价:mosh 只适合交互式终端,不能传文件、不能做端口转发。日常 shell 场景它是 SSH 的优质替代。

autossh:监控并自动重连 SSH

如果你拿 SSH 做长驻隧道或反向代理(比如把家里机器的端口通过云服务器转出来),连接断了必须有人重新拉起来。autossh 就是干这个的,它监控 SSH 连接,断了自动重连,适合无人值守的长期隧道:

autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -NfL 8080:localhost:80 user@host

XXXX 是让 SSH 自己的心跳来检测,比 autossh 自带的端口监测更可靠。

到这里,你的 SSH 通道该有的都有了:连得上、安全、隐蔽、稳。

深读:连接管理、保活、断线恢复的完整实践,见 #15。

---

附:诊断你的连接走了哪条路

配完前面 7 级,你有时会犯嘀咕:这次 SSH 到底走的是直连,还是 Tailscale,还是 Netbird,还是 Cloudflare Tunnel?尤其在弱网或排障时,确认通道是第一步。几个命令当场验明正身:

1. 看 SSH 实际连到哪:XXXXXX

握手第一行就交代了:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX。你连的 IP 和端口是哪个,SSH 自己最清楚。

2. 连上后在服务器看谁进来了:

ss -tnp | grep :22      # Linux,或换成你改过的端口

看源 IP。XXXXXXXXXX 到 XXXXXXXXXXX 这段 CGNAT 地址,基本就是 mesh 网络(Tailscale 和 Netbird 都默认用这段);如果源 IP 来自 Cloudflare 的任播段,那就是走了 Tunnel。

3. mesh 侧直接问状态(最稳,别猜 IP):

tailscale status       # Tailscale:看对端是 direct(打洞直连)还是 relay(中继)
netbird status         # Netbird:同理

这两个命令会明说你的连接是直连还是中继,比靠 IP 段猜要准。

4. 看本机流量从哪个接口出去:

ip route get <目标IP>   # Linux
route get <目标IP>      # macOS

返回里有 XXXXXXXXXXXXXX / XXXXXXXXXXXX / XXXXXXXX,接口名就是通道的身份证。

5. Cloudflare Tunnel 的特殊情况

CF Tunnel 跑 SSH 时,你是 ssh 到本地 cloudflared 转发的端口,不是直连服务器。所以本地 XX 看到的是连到 cloudflared 进程,服务器侧看到的源 IP 是 Cloudflare 边缘节点。

一句话原则:别猜,看实际建立的连接。 SSH 只认它连到的那个 IP,而那个 IP 所属的网段和它出去的接口名,就是通道的答案。排障时先确认通道,再调参数,顺序反了会白忙。

---

决策清单:你的场景,该停在哪一级

把 7 级浓缩成一份升级清单:

• 只是个人单机玩玩,跑跑 demo:第 2 级(密钥)就够,密钥加关密码,你已经比八成公网服务器安全
• 机器超过 3 台,记不住连接参数:加第 3 级(ssh config),大脑轻松一半
• 生产机要藏在内网:加第 4 级(ProxyJump 跳板),收敛攻击面
• 被爆破日志吵得烦:第 5 级(改端口 + UFW)降噪,记住它不是安全措施,安全在密钥和防火墙
• 机器没公网 IP,或不想开任何端口:第 6 级(mesh 或反向隧道),零端口暴露
• 连接老断、要在弱网用:第 7 级(ServerAliveInterval / mosh / autossh),给通道加韧性

不是每个人都要走到第 7 级。多数人到第 2、3 级就够用。但你要知道每一级解决什么问题,才能在场景变化时知道往哪升级,而不是在错误的层级死磕。

---

配套深读

这篇是 SSH 连接的全景图,讲「为什么」和「怎么选」。具体某个点的「怎么配」,见工具箱单点篇:

• 密钥完整配置(多服务器分发、ssh-agent、passphrase):#8
• ssh config 字段大全(Include、通配符、多环境):#9
• 连接管理最佳实践(多跳、保活、断线恢复):#15
• Cloudflare Tunnel 配置速查(把内网服务安全暴露):#20
• 内网穿透工具上手:#16 Tailscale / #17 Netbird / #18 ZeroTier / #19 对比
• 开端口还是 Tailscale、密钥还是密码的决策:D04

姊妹篇:这篇讲「通道」(SSH 本身怎么演进)。还有一篇讲「应用」，《开发工具远程连接终极指南》,讲 VS Code Remote、Cursor、Claude Code 这些工具怎么跑在 SSH 通道上。两篇一起看,远程开发的整张图就齐了。

---

---

❓ FAQ（SSH 演进最常问）

Q：第 ① 级密码登录到底能不能用？
生产环境不要用，密码会泄露、被爆破、弱密码容易猜。学习/临时调试（本地虚拟机、临时测试机）可以用。正式服务必须升级到第 ② 级密钥登录。

Q：ed25519 vs RSA 4096，新机器选哪个？
ed25519，密钥短（32 字节 vs 4K）、握手快、抗碰撞强度高、所有现代系统支持。只有连 2017 年前的老系统才用 RSA 4096。

Q：Tailscale 个人版够不够用？
100 设备 + 3 人协作免费，对个人开发者绰绰有余。5 人以上或需要 ACL/SSO/审计上 Team（$5/用户/月）。自建 Headscale 完全免费但要自己维护控制平面。

Q：Mesh VPN（Tailscale）和传统 VPN（WireGuard）有什么本质区别？
传统 WireGuard 是站点到站点（site-to-site），需要手动配 IP 和路由；Mesh VPN 是身份到身份（identity-to-identity），Tailscale 自动通过协调服务器分发 WireGuard 配置。Mesh VPN = 零配置的传统 VPN。

Q：跳板机（ProxyJump）和 SSH 隧道（-L/-D/-R）怎么选？
跳板机是「连过去」，XXXXXXXXXXXXXXXXXXXXXXXXX；SSH 隧道是「转发流量」，XX 本地转发、XX 动态 SOCKS、XX 远程转发。跳板解决的是路径问题，隧道解决的是访问问题。

Q：mosh 真的比 SSH 强吗？
只在网络差时强，mosh 用 UDP 漫游，断网/WiFi 切换不卡死。但 mosh 不支持 X11 转发和端口转发（必须 SSH 兜底），且首次连接还是要 SSH。日常 mosh、复杂操作 SSH 是最佳搭配。

---

💼 推荐工具

类别	推荐	说明
Mesh VPN（首选）	Tailscale	零配置组网，个人免费 100 设备，3 人协作免费
自建 Mesh 控制平面	Headscale	Tailscale 开源替代，完全免费自维护
传统 WireGuard	wg-easy	Docker 一键起 WireGuard 服务端
SSH 客户端（多平台）	Termius	全平台同步，团队协作，免费档够用
VPS（全球节点）	Vultr	32 节点，按小时计费，$6/月起
VPS（性价比）	DigitalOcean	开发者首选，文档完善，$6/月起
VPS（欧洲/合规）	Hetzner	德国价格屠夫，€4/月起
CDN/反代	Cloudflare	免费档够用，隐藏真实 IP 必选
域名注册	Cloudflare Registrar	成本价注册，免隐私保护费
密钥管理（个人）	Bitwarden	开源密码管理器，免费档够用
密钥管理（团队）	1Password	团队 $7.99/用户/月，含 SSH 签名
硬件密钥	YubiKey	FIDO2/U2F 硬件密钥，物理隔离最安全

数据与引用

• SSH 爆破规模数据:Singh et al.,《Brute-Force SSH Attacks In The Wild And How To Stop Them》,USENIX NSDI 2024(CloudLab 约 500 台服务器、4 年 sshd 日志,Log1 段 4.27 亿次尝试、84 万独立攻击 IP、平均每分钟 211 次失败 vs 25 次成功)。
• 「改回 22 端口被扫」实验与 security through obscurity 讨论:ServerFault、Information Security Stack Exchange、Hacker News 相关问答与帖。
• sshd 9.8 默认限速(PerSourcePenalties 累积惩罚机制):OpenSSH 9.8 release notes、XXXXXXXXXXXXXX 手册页 PerSourcePenalties / PerSourceNetBlockSize / PerSourcePenaltyExemptList 等新参数说明。
• ed25519 推荐与 RSA 现状:Mozilla OpenSSH Server Guidelines;《14 SSH Key Management Best Practices 2026》(ctrlops.io);《Comparing SSH Keys: RSA, ECDSA, Ed25519》(vitalvas.com, 2025)。
• SSH 爆破实测量级(Reddit 树莓派 2 周 25 万次尝试):r/selfhosted、r/homelab 多个帖(2023-2025),用户公网 IP 暴露 SSH 22 端口后日志记录;与 USENIX 论文量级一致。
• Tailscale 采用规模:Tailscale 官方博客 + Crunchbase(2025-04 Series C 1.6 亿美元、估值约 14.5 亿美元);Tailscale 官方客户故事页(2025 年披露 4 万+ 付费企业客户,含 SAP / Hugging Face / Instacart / Duolingo / Datadog)。
• Tailscale / Netbird / ZeroTier / Cloudflare Tunnel / FRP / ngrok 定位与定价:各项目官方文档(2026 年)。
• WireGuard 默认 NAT 打洞成功率(70-80%):WireGuard 官方 FAQ、Netbird 工程博客(2024-2025);Tailscale 文档披露 DERP 中继回退机制,直连失败时自动走中继。
• Cloudflare 边缘网络规模:Cloudflare 官方披露 330+ 城市、125+ 国家/地区、互联互通达 13+ Tbps(2025-2026 持续扩张)。
• OpenSSH 全球装机量:OpenSSH 在几乎所有 Linux 发行版默认启用,OpenBSD 项目官方披露 9.x 系列装机超 10 亿台机器,具体量级参考 Netcraft / Censys SSH 端口扫描数据(2024-2025)。
• SSH 协议从 1995 Tatu Ylönen 到 OpenSSH 主导的历史:RFC 4251-4254、OpenBSD OpenSSH 项目历史;OpenSSH 1999 年由 Tatu Ylönen 与 OpenBSD 团队合作 fork 自原始 SSH,后取代商业 SSH 成为事实标准。
• mosh 协议(UDP SSP 漫游):mosh 官网 keithw.com/mosh,基于预测回显 + UDP SSP(State Synchronization Protocol),会话状态每几秒同步一次。
• 文中所有命令均基于 OpenSSH 当前版本实际可用参数,未杜撰 flag。

💡 透明声明：本文包含 3 处推广链接（3 个独立服务，如 Vultr / DigitalOcean / Tailscale）。每次点击我会收到一笔佣金，不影响你的购买价格，也不影响我的内容判断，工具好不好用我自己用了才知道。完整推广政策见 ittinker.com/about。

立场声明:文中 Tailscale、Cloudflare、VPS 服务商含 ittinker 合作链接,不影响推荐结论;Netbird、FRP 为开源项目,无商业链接。