路只有两条。一条是在路由器上做端口转发，然后祈祷。另一条是把两台设备拉进同一张 私有 mesh 网络：手机拿到这台机器的一个固定地址，而公网上一个监听端口都没有。这篇讲第二条， 因为第一条是大多数人丢掉服务器的方式。

如果确实别无选择

有些网络环境就是搭不起 mesh。真要暴露 SSH，最低限度是只留公钥认证——注意这是 下限，不是推荐做法：

# /etc/ssh/sshd_config.d/moshpit.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AuthenticationMethods publickey
# 改完先验证再重载：sudo sshd -t && sudo systemctl reload ssh

在你按这套方案设计之前，Moshpit 有三件事得先知道：

• 只有两种认证方式，没有第三种。密码和公钥。不支持 keyboard-interactive， 所以配了 TOTP 二次验证提示的 sshd，Moshpit 是登不上去的。
• 没有 ProxyJump、没有跳板机、没有 agent forwarding。「先连堡垒机再跳过去」这件事 App 做不到。jumpHost 和 forwardAgent 字段在模型里存着， 但没有任何代码读它们。
• 带 passphrase 加密的私钥用不了。加载私钥时没有传解密密钥，加密过的 PEM 会直接认证失败。 改成在 Moshpit 里生成密钥（Settings → SSH Keys → ＋）、把公钥放到服务器上——那样的密钥可以放进 Secure Enclave，每次签名都过 Face ID。

PATH="$PATH:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/local/sbin:$HOME/.local/bin" \
  mosh-server new -s -c 256 -p 60000:61000 -l LANG=en_US.UTF-8

MOSH CONNECT 60001 <22 个 base64 字符 = 一把 16 字节的 AES-128 密钥>

到底要开什么、开在哪

走 mesh 的时候，「服务器入站」指的是在 mesh 这块网卡上入站。主机防火墙照样管得着： ufw、firewalld、云上的安全组，都夹在隧道和 mosh-server 中间。 在 tailscale0 上放开这段范围，跟对公网放开完全是两回事——而这一步恰恰是最常被跳过的。

范围在 Settings → MOSH · ROAMING → UDP port range 里改（From / To， 校验 1–65535 且 From ≤ To）。连接表单里显示的是同一份，只读。起始端口不合法时会整个丢掉 -p，让 mosh-server 用它自己的默认范围；结束端口不合法则退化成只钉在起始那一个端口上。

Moshpit 起的是 mosh-server new -s。这个参数就是 mosh 的 --bind-server=ssh，也是 mosh 1.4 起的上游默认行为：server 只绑 SSH 连接进来的 那一个地址。这是有意的设计——数据报因此会走你刚刚登录时走过的同一条路。

于是就有了：

• 在家连 192.168.1.30 建起来的会话，它的 mosh-server 绑在 192.168.1.30 上。从 mesh 那一侧，这个 server 根本够不着。
• 反过来也一样：从 mesh 建的会话绑的是 mesh 地址，回到家用局域网就连不上。
• 这两件事都不是 Moshpit 做错了什么，这就是 --bind-server=ssh 的字面含义。

所以：连接里就存 mesh 的名字，在家也用它。反正 mesh 到自己局域网内的流量本来 就会走本地直连。一个地址、一条连接、走出办公室的时候不会突然出事。

孤儿 mosh-server 会越攒越多

每次连接都会起一个新的 mosh-server。链路断掉时，旧的那个不会退出—— 它就杵在那占着自己的 UDP 端口。反复重连几周下来就攒了一堆。Moshpit 目前不回收它们， 这是实打实的缺口，不是什么设计取舍。

pgrep -fl mosh-server                 # 还活着几个
lsof -nP -iUDP | grep mosh-server     # 以及每个分别绑在哪个地址上
pkill -f mosh-server                  # 粗暴解决；活着的会话也会一起被杀

第二条命令里的绑定地址本身就是诊断信息：它告诉你每个会话当初是从哪张网建的， 通常这一条就足够解释「为什么其中一个不响应了」。

说清楚它管的范围：这个权限管的是局域网地址——192.168.x.x、 10.x.x.x 这些。发往 mesh 地址的流量走的是 VPN 隧道那块虚拟网卡。 但只要你有可能用局域网地址连这台机器，就顺手把它打开：它造成的故障和防火墙问题长得一模一样， 而你会在错误的那一头耗掉一整晚。

1 · 对端在线吗，是直连还是中继？

tailscale status          # 对端那一行末尾是 direct 还是某个中继名
tailscale ip -4           # 这个地址就是要填进 Host 的

走中继也能用，只是慢；运气差的时候，这就是「能用」和「没法用」的区别。

2 · 同一张 mesh 上的电脑，裸 SSH 通吗？

ssh -v user@m1-pro.your-tailnet.ts.net

这一步不通就别往下走了。上面所有东西都建立在它之上——mosh 没有独立模式， Moshpit 首先是个 SSH 客户端。

3 · UDP 真的能双向跑通吗？

这一步几乎没人做，而它恰恰是最容易揪出问题的一步。在范围里挑一个端口， 服务端监听，用一台和手机在同一张网上的电脑发：

# 服务器上
echo REPLY | nc -u -l 60005 > /tmp/udp-in

# 和手机同一个 Wi-Fi 的电脑上
echo PING | nc -u -w3 m1-pro.your-tailnet.ts.net 60005

两边都得看到对方那个词。服务端收到了 PING、客户端却始终等不到 REPLY，就是回程死了——这正是 mosh 黑屏的成因。这是网络的答案，不是 App 的答案。

4 · 范围在「流量真正进来的那块网卡」上放开了吗？

sudo ufw status verbose                       # Debian / Ubuntu
sudo firewall-cmd --list-all                  # Fedora / RHEL
sudo ufw allow in on tailscale0 to any port 60000:61000 proto udp

然后云上的安全组要单独再看一遍。另外确认放开的是 Moshpit 配置的同一段范围—— 默认是 60000–61000，但它是可改的。

5 · 问 App 自己看到了什么

在 mosh 会话里长按终端顶栏的传输标记，会弹出 MOSH DIAGNOSTICS： datagrams、applied、parse fails、gaps。 最有价值的那一行反而不是数字：

MOSH DIAGNOSTICS
   No datagrams yet.

它的意思是：一个包都没回来过——这个计数器在任何解密和解析之前就已经加过了。 回程是死的。别再查 Moshpit 了，回到第 3 步。

6 · 用逃生口

如果这张网就是在吃你的 UDP，而你现在就要一个能用的终端：点 banner 上的 Switch to SSH，或者点顶栏的 MOSH 标记确认 "Switch to SSH?"。 SSH 走 TCP，能穿过那条把数据报吃掉的路径。banner 可以直接叉掉，它从不挡住终端—— 你的击键其实一直都送到了服务器，被饿死的只是画面。

⚠  Mosh isn't receiving data — your network may be
   blocking UDP (VPN, proxy, or firewall).

   Switch to SSH                                    ×