ssh reverse port forward to mobile device

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 开发者_JS百科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,

1. 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.

2. port resources. there are a finite number of ports on the server. maybe not a problem when things are scaled across multiple servers.

3. tunnel management. tunnels may not always go down nicely, so there's the problem of "cleaning up" tunnels that go down unexpectedly (see #1).

4. 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.

5. scalability. how expensive (resource-wise) is it to have perhaps thousands of SSH tunnels open? is it realistic?

6. 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.

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.