从任何地方连回自己的机器

如果实在没有别的办法

有些网络环境搭不起 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。「先 SSH 到跳板机再跳一次」这件事， 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）。连接表单里显示同一份，只读。起始端口不在合法范围内时，Moshpit 会整个去掉-p，mosh-server 用自己的默认范围；结束端口不可用时，会话只钉在起始那一个端口上。

Moshpit 启动的是 mosh-server new -s。这个参数就是 mosh 的--bind-server=ssh，从 mosh 1.4 起是上游默认：服务端只绑定 SSH 连接进来的那个地址。 这是有意的设计：数据报走的路，和你刚才登录走的路一样。

后果是：

• 在家里连 192.168.1.30 建的会话，mosh-server 绑在192.168.1.30 上。从 mesh 那边，这个服务端够不着。
• 从 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 地址的流量走隧道那块虚拟网卡，不受它管。但只要你有可能用局域网地址连这台机器，就把它打开。它造成的故障和防火墙问题长得一样，你会在错的那一头耗掉一个晚上。

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，而你现在就需要一个能用的终端：点横幅上的Switch to SSH，或者点顶栏的 MOSH 标签，确认 "Switch to SSH?"。 SSH 走 TCP，能穿过那条丢数据报的路。横幅可以关掉，也从不挡住终端。你敲的键其实一直都到了服务器，只是画面没回来。

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

   Switch to SSH                                    ×