ssh 反向端口转发到移动设备
我们需要能够访问移动设备上的资源。移动设备必须充当服务器。无论手机如何连接（wifi、3g、防火墙后等），它都必须可用。我知道这可以通过启动从手机到云可访问服务器的 ssh 反向端口转发来完成。希望访问手机上资源的客户端现在可以通过某个随机端口连接到云服务器，并将连接通过隧道传输到移动设备。美好的。
我的问题涉及这个想法作为可扩展、强大、安全的解决方案的可行性。使用此方案部署到数万台设备的移动应用程序使设备本地资源可访问。设备本地资源的安全性不是很高。建议使用 ssh 主要是因为它使建立隧道变得更容易。
这是我的一些担忧，
端口分配。每个隧道都需要云服务器上的唯一端口。我相信这需要设备和云服务器在启动隧道之前协商 IP。这当然是可能的，但这意味着某处有一个有点复杂的服务，它不断探测端口以确定其可用性。
端口资源。服务器上的端口数量是有限的。当事物跨多个服务器扩展时，也许不是问题。
隧道管理。隧道可能并不总是能很好地下降，因此存在“清理”意外下降的隧道的问题（参见#1）。
安全。每个设备都需要公钥来匹配云服务器上的秘密。如果它在设备上，则可以从中取出。现在，只要帐户被锁定，就不会发生太多事情，但它确实会打开另一个攻击媒介。
此外，简单地打开服务器的所有唯一端口也是另一种攻击媒介。
可扩展性。打开数千个 SSH 隧道的成本（资源方面）有多高？现实吗？
防火墙。云服务器端口不会是“80”或“8080”，而是一些随机数。对于某些可能限制标准端口的出站连接的防火墙来说，这是一个问题吗？
正如你所看到的，安全不是我的强项，所以请小心对待我。如果您没有猜到，我对这种方法持极端保留态度，因此我正在寻找证据来寻找其他解决方案来解决一般问题。
We have a requirement to be able to access resources on a mobile device. the mobile device must act as a server. it must be available no matter how the phone is connected (wifi, 3g, behind firewall, etc). i understand this can be accomplished by initiating an ssh reverse port forward from the phone to a cloud-accessible server. clients wishing to access resources on the phone can now connect to the cloud server at some random port, and have the connection tunneled to the mobile device. fine.
my question concerns the feasibility of this idea as a scalable, robust, secure solution. a mobile application deployed to tens of thousands of devices using this scheme to make device-local resources accessible. the device-local resources are not ultra-high security. ssh was suggested mainly because it makes setting up the tunnel easier.
here are some of my concerns,
port allocation. every tunnel requires a unique port on the cloud server. i believe this will require the device and the cloud server to negotiate an IP before initiating the tunnel. this is certainly possible, but it means there's a somewhat complex service somewhere that is constantly probing ports to determine their availability.
port resources. there are a finite number of ports on the server. maybe not a problem when things are scaled across multiple servers.
tunnel management. tunnels may not always go down nicely, so there's the problem of "cleaning up" tunnels that go down unexpectedly (see #1).
security. each device would require the public key to match the secret on the cloud server. if it's on the device, it can be taken from it. now, as long as the account is locked down, there's not much that can happen, but it does open another vector of attack.
also, simply having all of the unique ports open of the server is another attack vector.
scalability. how expensive (resource-wise) is it to have perhaps thousands of SSH tunnels open? is it realistic?
firewalling. the cloud server ports will not be "80" or "8080", but some random number. is this a problem for some firewalls that may restrict outbound connections to standard ports?
As you can see security isn't my forte, so treat me with kid gloves. If you haven't guessed, I have extreme reservations about this approach so I'm looking for evidence to look at other solutions to solve the general problem.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
此处可能需要一些自定义代码，或者专用于该概念的协议上的隧道会话。 IPSEC over UDP 可能是一个不错的提名。如果可能的话，让移动设备像常规服务器一样监听并在地址更改时发送 ping，这样您就可以避免很多挑战。这将取决于手机的行为以及运营商是否执行过滤传入 TCP 连接等烦人的操作。无论如何，要解决具体问题：
1）不，每个连接都需要一个唯一的套接字。这是端口号和 IP 地址的组合。即使两部电话位于同一 NAT 后面，NAT 设备也会为连接分配不同的端口。您可以在服务器计算机的一个端口上运行一项服务。
2) 见上文
3) 这将作为一种规则而不是例外发生。他们超时并关闭。实际上，这可能没有您想象的那么困难。
4) 如何解决这个问题将取决于您的安全需求。您可以尝试识别手机上的底层 ID，以使事情变得更具挑战性，要求输入用户密码以使其成为两个因素，等等。这当然会与易用性竞争，因此权衡考虑留给您。
1a) 没有线索...但这应该不是不可能的。
2a) 你会在某些地方遇到这种情况，但很难预测在哪里。也就是说，您也可以通过 HTTPS 执行这些功能。
Some custom code would be in order here, or a tunneling session over a protocol dedicated to that concept. IPSEC over UDP could be a good nomination. If at all possible, having the mobile device listen like a regular server and send out pings whenever it changes addresses may spare you much of the challenge. This will depend on the phone's behavior and whether the carrier does annoying things like filter incoming TCP connections. Anyway, to address specific questions:
1) No, each connection will require a unique socket. That's a combination of port number and IP address. Even with two phones behind the same NAT, the NAT device would assign different ports to the connections. You can run one service on one port of your server machine.
2) See above
3) That will happen as a rule rather than an exception. They timeout and close. This may actually be less of a challenge than you expect.
4) How you address this will be based on your security needs. You could attempt to identify underlying ids on the phone to make things more challenging, require a user password entry to make it two factor, etc. That of course competes with ease-of-use, so the trade-off consideration is left to you.
1a) No clue... but it shouldn't be impossible.
2a) You will encounter that in some places, and where is hard to predict. That said, you perform these functions over HTTPS just as well.