# Tailscale SSH 被曝安全漏洞：一台设备失守，可获得其他服务器 root 权限｜另外还有11项漏洞

**URL:** <https://meta.appinn.net/t/topic/94490>\
**Category:** 安全情报\
**Created:** [2026 年10 月 26 日 02:42 UTC](https://meta.appinn.net/t/topic/94490 "2026-10-26T02:42:08Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

作者： ![Qingwa](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/qingwa/32/58632_2.png) [@Qingwa](https://meta.appinn.net/u/Qingwa)\
发布日期： [2026 年10 月 26 日 02:42 UTC](https://meta.appinn.net/t/topic/94490/1 "2026-10-26T02:42:08Z")

</div>

原始链接在： [Tailscale SSH 被曝安全漏洞：一台设备失守，可获得其他服务器 root 权限｜另外还有11项漏洞 - 小众软件](https://www.appinn.com/tailscale-ssh-security-vulnerabilities-tailworm/)

> Tailscale SSH 漏洞
> 
> 如果你在使用 Tailscale 管理家里的 NAS、公司的服务器、个人电脑、手机，那么先把 **Tailscale SSH** 关了，目前漏洞还未修复。（2026年10月26日）

安全研究员 Erica Windisch 近日公布了一份名为 **Tailworm** 的安全报告，在 Tailscale 及其相关组件中发现了 **11 项安全问题，分为 5 组** 。

其中最严重的漏洞是 **Tailscale SSH** ：已获准使用 Tailscale SSH 的用户可以通过 Unix 套接字转发 **获取目标主机的 root 权限** 。

 ![](https://h2cdn.appinn.me/original/3X/3/b/3b9a0b1b34d3c791b8ebf7a943211ffd611c7014.jpeg)

Tailscale 是一款基于 WireGuard 的组网工具，可以让不同地点的电脑、服务器、NAS 组成一个私有网络。比如你在家中访问办公室的网络资源，在安装了 Tailscale 之后，最终效果就是家与办公室之间就像在一个局域网之内。

并且还能控制A设备只能访问B，而B只能访问C但不能访问A。非常灵活。

## Tailscale SSH 出了什么问题？

启用 **Tailscale SSH** 后，就可以通过 SSH 连接到每一台设备。

在 Linux 上，Tailscale SSH 服务器运行在 `tailscaled` 后台进程中，而这个进程通常拥有 root 权限。

研究员发现，在特定 SSH 端口转发条件下，攻击者可能利用高权限的 `tailscaled` 访问本来不应该由普通用户访问的 Unix Socket，最终实现权限提升。

测试设备版本：tailscale v1.104.2，headscale v0.29.5

实验室测试中，每攻陷一台设备耗时不到 1 秒，直到所有允许访问的设备都被攻陷，并且会自动传播。

 ![](https://h2cdn.appinn.me/original/3X/c/0/c09e6cedc994901c73afb01cb7ce95ee59e51825.avif)
## 不只有 SSH：涉及 5 类安全问题

报告共列出 11 项发现，涉及：

- **Tailscale SSH：** 权限边界和 SSH 端口转发问题，可能导致 root 权限提升。
- **Tailscale Serve：** 服务暴露与权限隔离相关问题。
- **App Connector：** 应用连接功能中的安全问题。
- **DERP 中继客户端：** 与中继连接处理有关的安全问题。
- **headscale：** 第三方开源控制服务器的 SSH 策略与权限控制问题。

## Tailscale 官方回应

截止目前，尚未有针对这些发现的 CVE 编号、GitHub 安全公告、Tailscale 安全公告或修复版本。

来自 [threatwire](https://www.threatwire.tech/news/tailworm-tailscale-ssh-headscale-11-flaws-what-is-confirmed?utm_source=appinn.com) 的说法，Tailscale 工程副总裁 Mike Shaver 于 2026 年 10 月 25 日 00:41 UTC 在 [r/Tailscale](https://www.reddit.com/r/Tailscale/comments/1xeoj1l/recent_tailscale_vulnerability_reports/) 上发布了一份声明。

 ![](https://h2cdn.appinn.me/original/3X/2/3/2304d7fe6095a56d54d2ae2b2d7494f4e3bc6a18.avif)

要点如下：

- Tailscale 已收到研究人员的报告，目前正在审查中。
- 该公司自己的团队以及外部安全专家此前已经展开调查。这项工作“发现了一些我们正在努力解决的问题”。
- 目前发现的大多数问题都与用户获得连接授权后发生的情况有关，特别是 Unix 权限和 SSH 转发方面的问题。会话“可能能够执行超出已配置本地用户应有权限执行的操作”。
- Tailscale 表示，这“与未经身份验证的攻击者能够连接到任意机器的情况并不相同”。
- 目前仍在验证全部影响范围，包括哪些配置会受到影响。
- “根据我们目前的评估，我们不建议所有人禁用 Tailscale SSH。”
- Tailscale 将发布一份安全公告，其中包含已确认的发现、受影响的配置和补丁，然后发布一份技术说明。

在 Hacker News 上，一位 Tailscale 的工程师也对报告中的一项说法提出了质疑。Windisch 表示，每个节点都可以看到完整的对等节点列表。他指出，这可能是 headscale 架构的差异：Tailscale 自身的控制平面会对网络映射进行精简，因此彼此之间没有 ACL 路径的节点无法看到对方。

目前，公开代码中已经出现部分修复工作，包括 Serve 权限问题，以及将 SSH 端口转发操作隔离到独立特权进程的改动。

## 如何关闭 Tailscale SSH？

在需要关闭 Tailscale SSH 的设备上执行：

```
sudo tailscale set --ssh=false
```

这条命令只会关闭 Tailscale 内置的 SSH 服务器，不会断开 Tailscale 网络连接，也不会关闭系统自带的 OpenSSH 服务。

如果之后需要重新启用：

```
sudo tailscale set --ssh=true
```

另外请在操作远程机器的时候更谨慎一些，青小蛙前两天刚刚遭遇了让AI修机器最终被挡在设备外的以外状况，想去嘲笑的可以围观：[https://meta.appinn.net/t/topic/94203/](https://meta.appinn.net/t/topic/94203/)

* * *

相关链接：

- [Tailworm 安全研究报告](https://www.tailworm.com/)
- [Tailscale 官方安全公告](https://tailscale.com/security-bulletins)（此为发布地址，目前还没有更新）
- [Tailscale SSH 权限隔离修复 PR #21937](https://github.com/tailscale/tailscale/pull/21937)（代码已合并）

原文：https://www.appinn.com/tailscale-ssh-security-vulnerabilities-tailworm/

---

<div class="post-metadata">

作者： ![SmallPackage](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/smallpackage/32/57958_2.png) [@SmallPackage](https://meta.appinn.net/u/SmallPackage)\
发布日期： [2026 年10 月 26 日 03:08 UTC](https://meta.appinn.net/t/topic/94490/2 "2026-10-26T03:08:16Z")

</div>

Tailscale 内置的 SSH 服务器 和 系统自带的 OpenSSH 服务 这两个是什关系？  
搜索了一下，感觉这个是某种企业功能？

* * *

Tailscale 内置的 SSH 服务器（Tailscale SSH）与系统自带的 OpenSSH 服务（`sshd`）是 **两个完全独立、并列运行的 SSH 服务端实现** 。

它们之间的关系和核心区别可以总结为以下几个方面：

### 1. 核心架构与运行关系

- **完全独立的进程与实现** ：

- **互不干涉（共享同一个 22 端口也不会冲突）** ：

### 2. 身份验证与密钥管理

| **特性** | **系统 OpenSSH (sshd)** | **Tailscale SSH** |
| --- | --- | --- |
| **身份认证机制** | 依赖本地 Linux 用户名/密码，或 `~/.ssh/authorized_keys` 中的公钥。 | 依赖你的 **SSO / Identity Provider** （如 Google、Microsoft、Okta）和 Tailscale ACL 策略。 |
| **密钥管理** | 需要手动生成 SSH 密钥对，并将公钥分发/部署到每台服务器上。 | **无密钥（Keyless）** 。客户端连接时，Tailscale 会自动签发短期的公钥证书，无需手动管理密钥。 |
| **访问控制 (ACL)** | 依赖服务器本地的防火墙（`iptables`/`ufw`）和 `sshd_config` 文件。 | 集中在 Tailscale 控制台的 **ACL 规则** 中配置，可以按用户、标签（Tag）、设备细粒度管控。 |

### 3. 连接与登录流程对比

- **使用系统 OpenSSH 时** ：

- **使用 Tailscale SSH 时** ：

### 4. 为什么 Tailscale 要自己实现 SSH？

1. **消除 SSH 密钥泄漏与管理痛点** ：不再需要在数百台服务器上分发、轮换 `authorized_keys`，员工离职时只需在公司 SSO 中禁用账号，即可立刻收回所有 SSH 访问权限。

2. **支持 MFA / 二次认证** ：可以在 SSH 登录时强制触发 Web 浏览器的身份验证或多因素认证（Check Mode）。

3. **集中审计与日志** ：所有 SSH 连接的建立、鉴权记录都会直接上报到 Tailscale 控制台日志中。

### 5. 总结

- 如果你 **没有启用** Tailscale SSH，Tailscale 只是一个纯粹的 VPN 隧道，你用 `ssh user@tailscale-ip` 连上去时，背后干活的仍然是系统的 **OpenSSH** 。

- 如果你 **启用了** Tailscale SSH，通过 Tailscale 连入的 SSH 请求就会被 **Tailscale 自己的 Go 语言 SSH 实现** 拦截并处理，绕过了系统的 `sshd` 和传统密钥认证，改为使用 SSO 身份凭证登录。

---

<div class="post-metadata">

作者： ![Qingwa](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/qingwa/32/58632_2.png) [@Qingwa](https://meta.appinn.net/u/Qingwa)\
发布日期： [2026 年10 月 26 日 03:08 UTC](https://meta.appinn.net/t/topic/94490/3 "2026-10-26T03:08:35Z")

</div>

两套服务，两个SSH

---

<div class="post-metadata">

作者： ![Duah](https://meta-edge.appinn.com/user_avatar/meta.appinn.net/duah/32/51072_2.png) [@Duah](https://meta.appinn.net/u/Duah)\
发布日期： [2026 年10 月 26 日 04:21 UTC](https://meta.appinn.net/t/topic/94490/4 "2026-10-26T04:21:30Z")

</div>

最近剛好刪了 Tailscale

沒想到這個也會爆這麼大的漏洞
