为什么要一刀切禁止监听0.0.0.0？

[dale0525]

我就想在家里局域网多设备访问，连监听0.0.0.0都直接禁止，必须得搞个反代+auth，有病吧？因为小白不会用、把自己的服务暴露了就一刀切禁止局域网访问？头疼医头脚疼医脚啊？那还开什么源呢，做个闭源的不就得了？

[argszero]

理解你的火气——家庭局域网多设备访问是正当需求，而"必须反代+auth"对小白确实像故意刁难。先把代码事实摆清楚（master d347e70），再说为什么这个门不是一刀切。

你的描述在 CLI 层属实。 dsh web 的 --host 0.0.0.0 被硬拒（bundle/web-app/src/startup.ts:74-75，错误原文："intentionally not supported yet for safety: it would expose remote code execution to the network; use 127.0.0.1 instead"）。但配置层并没有禁——webserver 的 host schema 本身就允许 0.0.0.0（host/webserver/src/index.ts:61/:126），CLI 只是便捷命令前的安全门；服务化 profile 直接写配置（不走 --host flag）就能绑内网网卡。这不是"禁局域网访问"，是"命令行不便携地暴露"。

为什么这门存在（不是头疼医头）： dsh 进程不是一个"网页应用"——它是一个带 shell/文件/网络工具的编码 agent。绑 0.0.0.0 意味着内网任何能摸到端口的设备（包括被攻破的 IoT、访客 WiFi 上的设备、恶意网页驱动的浏览器）都能驱动一个能在你宿主机上执行任意命令的 agent。这是 RCE 级风险，不是"别人能看到我的聊天"。浏览器 token/cookie 挡的也不是"人类认证"——树里目前没有 per-user 认证层，token 只是防 drive-by 会话的闸。

今天就能用的局域网路径（按折腾成本排序）：

1. 配置绑 0.0.0.0 + trustedHosts + 每设备一次 token：profile 配置写 host（绕开 CLI 门），connection 配 trustedHosts 声明你家局域网名（client/connection/src/index.ts:88，非 loopback 部署本就要求声明），浏览器每台设备访问一次带 token 的 URL（cookie 30 天）。无反代、无自建 auth。
2. 反代 + 一层真 auth：想要"零 token"体验才需要这个——反代替你认证，dsh 只认反代放行的请求。

体验缺口是真实且已被讨论的： token 每次启动轮换 → 每台设备每 ~30 天要重新取一次，这个痛在 #5828（browserAuth opt-out 提案，含 env 钉定 token 的止痛方案）和 #5829（settings 持久化 loopback-only）里正在被认真讨论——都是多设备/反代运营者的真实场景，不是没人管。

开源的意义恰恰是你能选：CLI 门是默认安全，配置层留了口子给你自己负责。如果你愿意说下具体卡点（token 轮换？还是连配置绑 host 都不会？），我可以给一个能直接用的最小配置片段。

[SnowManKeepsOnForgeting]

不是直接ssh转发端口就可以嘛。。。nginx转发也行，稍微 有一点点门槛

[baotherye]

如果是我负责DSH，我也会在系统不成熟的早期禁止0.0.0.0，否则小白们发生网络安全事故概率太大了，会毁了这个系统发展口碑。

[paopjian]

逆天, 不想用别用, 变肉鸡就老实了

[dale0525]

就你懂肉鸡，我家里公网ip都没有，只是局域网互相访问，这要是还能被入侵那是我自己活该、或者你要是能入侵那是你牛x

[Dave-12138]

因为还没做鉴权，所以掐了，就这么简单。
不过因为社区似乎已经有实现这个功能的插件了，“dsh团队自己加鉴权”估计会无限期推延，除非员工什么时候自己要用