如何通过 Tor 连接你的 VPS
Anonymity · 8 分钟阅读
两个不同的问题,都被称为'SSH over Tor'
搜索 tor vps access 的人通常在试图解决两个截然不同的问题之一,具体做法取决于你面对的是哪一个。第一个是客户端侧:你想对服务器、对监视你本地网络的任何人、以及对日后可能传票索取 VPS 服务商连接日志的任何人隐藏你自己的 IP 地址。第二个是服务器侧:你想让 VPS 本身在公网上完全没有可访问的 SSH 端口,这样它就无法被端口扫描发现,不会被撞库机器人针对,也无法通过其监听服务被地理定位。
这两者并不互斥。关于 ssh over tor 的论坛讨论中很多困惑,都来自把'我想隐藏是谁在连接'和'我想隐藏连接的对象是什么'混为一谈。本指南两者都会涵盖:先从更简单的客户端设置开始,再介绍面向服务器的洋葱服务方案,然后讲解如何加固最终结果,以及实际应该预期怎样的性能表现。
- 客户端匿名性:你的 SSH 客户端通过 Tor 路由,因此服务器(以及任何记录其入站连接的人)看到的是一个 Tor 出口节点或中继,而不是你的真实 IP
- 服务器端匿名性:sshd 只能通过 Tor 洋葱地址访问,因此根本不存在公开的 SSH IP:端口
方法一:让 SSH 客户端通过 Tor 的 SOCKS 代理
运行中的 Tor 客户端(指 Tor 守护进程,不一定是 Tor 浏览器)会在本地暴露一个 SOCKS5 代理,默认地址为 127.0.0.1:9050。任何支持 SOCKS 的应用都可以指向它,但 SSH 本身并不原生支持 SOCKS,所以你需要一个小的桥接工具。两种常见做法是 torsocks(它包裹某个命令,强制其 TCP 连接走代理)和在 SSH 配置中使用 ProxyCommand 条目,通过一个支持 SOCKS 的 netcat 转发连接。
最快的测试方法很简单:安装 tor,确认它正在运行,然后执行 torsocks ssh user@your-vps-ip。如果能连上,你的 SSH 会话现在就走的是三跳 Tor 电路。如果你打算每天都用这种方式,不必每次都手打 torsocks,而是在 ~/.ssh/config 中添加一个 Host 区块,使用类似 nc -X 5 -x 127.0.0.1:9050 %h %p(配合 OpenBSD netcat)或 connect -S 127.0.0.1:9050 %h %p(配合 connect-proxy 工具)的 ProxyCommand 行。这样,直接输入 ssh myhost 就能始终自动走 Tor,无需记住那层包装。
- 在排查 SSH 本身之前,先确认 Tor 确实在运行并监听 9050 端口
- torsocks ssh user@host 是测试的最快方式;~/.ssh/config 中的 ProxyCommand 是日常使用的持久方式
- 这种方法能对 VPS 及查看其认证日志的任何人隐藏你的 IP,但 SSH 端口本身在公网上依旧是开放的
方法二:在 VPS 上把 SSH 发布为 Tor 洋葱服务
如果目标是让 VPS 自身的 IP 地址在管理访问中完全不出现,服务器就需要运行 Tor,并且只把 sshd 作为隐藏服务对外暴露。在 VPS 上安装 tor,然后在 torrc 中加两行:HiddenServiceDir 指向一个 Tor 可写入的目录,以及 HiddenServicePort 22 127.0.0.1:22,告诉 Tor 把到达洋葱地址 22 端口的连接转发给本地监听的 sshd。重启 Tor,它首次启动时会在那个目录里生成一个很长的随机 .onion 主机名。
关键在于,只有当 sshd 也被设置为绑定到 127.0.0.1 而不是 VPS 的公网接口时(在 sshd_config 中设置 ListenAddress 127.0.0.1,然后重启 sshd),这一步才能真正消除暴露。跳过这一步会让 SSH 同时可以通过洋葱地址和公网 IP 直接访问,那就失去了意义。完成后,从客户端用 torsocks ssh [email protected] 连接——对 VPS 的端口扫描将永远不会发现任何公网 IPv4 或 IPv6 的 SSH 地址。
- 在 torrc 中添加 HiddenServiceDir 和 HiddenServicePort 22 127.0.0.1:22,然后重启 Tor
- 把 sshd 本身绑定到仅 127.0.0.1——在依旧公开的端口前面套一层洋葱服务什么也隐藏不了
- 读取 HiddenServiceDir 目录内生成的 hostname 文件,以获取要连接的 .onion 地址
- 使用 torsocks ssh [email protected] 连接;裸 IP 从此彻底无法用于 SSH
一旦 SSH 只在 .onion 上响应,就要锁死认证方式
隐藏端口并不能取代对登录本身的加固。使用 ed25519 密钥对,完全关闭密码认证(PasswordAuthentication no),并禁止 root 通过 SSH 登录(PermitRootLogin no)。如果你用来访问这台 VPS 的密钥,和你日常账户使用的是同一个,那么一旦这个密钥的指纹出现在某次数据泄露或与你姓名相关联的 Shodan/Censys 扫描结果中,洋葱服务带来的匿名性也就随之瓦解——为匿名基础设施生成一个专属密钥。
在这种设置下,有一件事会悄悄失效:基于 IP 的工具,比如 fail2ban。因为连接是通过本地 Tor 进程到达 sshd 的,所以 sshd 记录的每一次登录尝试来源地址,无论成功与否,都是 127.0.0.1——没有攻击者 IP 可供封禁。这不是需要额外方案去弥补的缺口:仅密钥认证、没有密码兜底,本身就已经消除了 fail2ban 原本要缓解的暴力破解风险。只是不要指望它的日志在这种配置下还有实际意义。
- 仅密钥认证,使用 ed25519,不设密码兜底
- 每台匿名服务器使用专属密钥对,绝不复用个人机器上的密钥
- PermitRootLogin no,日常操作使用带 sudo 权限的非 root 账户
- 一旦流量经由 Tor 到达,就不要依赖 fail2ban 或基于 IP 的白名单——日志中的源 IP 永远是回环地址
实际性能表现如何
标准 Tor 电路由三个中继组成,而一次洋葱服务连接会首尾相接叠加两条三跳电路(一条从客户端进入 Tor 网络,一条从 Tor 网络到达隐藏服务),因此往返延迟通常落在几百毫秒到几秒之间,电路重建时偶尔还会出现延迟尖峰。交互式操作——编辑配置文件、查看日志、重启服务——在这种延迟下完全可用。在你的 SSH 配置中设置 ServerAliveInterval,避免空闲会话因为多出的一跳而被断开,并预期 Tor 挑选新电路时偶尔会出现短暂卡顿。
真正表现不佳的是吞吐量。scp、rsync 或任何要传输数 GB 数据的操作,与直连相比都会慢得多,因为 Tor 电路是为大量短生命周期流的低延迟交互而优化的,而不是为持续带宽优化的。对于真正的数据传输——备份、大文件上传——请使用直连的加密通道(经公网 IP 的普通 SSH/rsync,或 WireGuard 隧道),把 Tor 路径专门留给隐藏连接比速度更重要的管理型 shell 访问。
悄悄破坏你想要的匿名性的常见失误
这里的大多数失败并不高深——它们是留下一扇侧门的小配置疏漏。在信任这套设置之前,先留意以下几点:
避免这些问题都不需要高级工具,只需要实际检查一次监听端口和 DNS 行为,而不是想当然地认为 Tor 配置本身就搞定了一切。
- sshd 仍与洋葱服务一起绑定在公网接口上,导致这个'隐藏'端口同样能被普通端口扫描发现
- 在 Tor 之外解析主机名(一次偶然的 DNS 查询,或某个应用忽略了 SOCKS 代理进行 DNS 解析),会在 Tor 连接真正建立之前,就泄露你即将连接的主机是哪一个
- ProxyCommand 在 Tor 未运行时悄悄回退为直连——把它配置为失败即关闭而不是失败即开放,这样 Tor 守护进程挂掉时结果是无法连接,而不是一次意外的明网连接
- 复用了会把这次会话关联回其他地方非匿名身份的 SSH 密钥、终端提示符或 shell 历史记录
| 方式 | 隐藏了什么 | 典型增加延迟 | 配置成本 |
|---|---|---|---|
| 经明网直连 SSH | 除了 SSH 自身加密之外什么都不隐藏 | 无 | 无 |
| 客户端经 Tor 的 SOCKS 代理路由 | 你的 IP 地址,不被服务器及其日志记录 | 中等——大约一条 Tor 电路,约 300ms-1s | 低——torsocks 或一行 ProxyCommand |
| SSH 以 Tor 洋葱服务形式发布 | VPS 的公网 IP;互联网上没有开放的 SSH 端口 | 中到高——增加了服务器侧电路 | 中等——需修改 torrc 与 sshd_config |
| 两者结合:客户端走 Tor,服务器端为洋葱服务 | 连接两端都完全不触碰明网 | 最高——两条独立的三跳电路 | 中等 |