This service is being called come-in for this document.
Use casesThe first use case is, to allow a remote friend to login in the machine and do some stuff. The remote friend can use screen / tmux / vnc to share screen with local person, or just some magic command and exit.
The 'Needy' is the person requiring assistance, and 'Friend' is the one who will will remotely login to help out.
- Needy pings Friend on IM or in any other way.
- Friend shares his public key with Needy.
- Needy runs the come-in client, and enters Friend's public key.
- Friend runs come-in client and invokes 'Connect'
- Friend is logged on to Needy's machine.
Another use case is remote access of several machines by a group of person. These will use site logins and registrations of machines. The server data stored will be only for lookup of group of machines to group of people.
Security considerationsThe closed sourced software and services work on the assumption that their servers are impenetrable. And moreover they want users data in plain text on there servers for some evil reasons.
Now as we are not evil, we wouldn't want to have any user data in plain text on our servers. We work on assumption that our servers and storage is vulnerable1, and even in that case, user's machine connected to server should be safe and secure.
ArchitectureThe come-in client is wrapper over ssh client. Several ports will be setup as forward / reverse proxy. Some of these ports will be client to client, where as some may be client to server. The client to server connection is only used for identification. It should be noted that even if the server is malicious, it'll not be able to fool the client into connecting to a non-desired client, because the client to client connection, the data connection, is seprate from this client to server connection, and is encrypted end to end.
The come-in server needs to have extra functionality, of a 'matcher' and of a 'proxy'. It's possible the come-in server is an especially patched ssh server, or just a configuration of ssh server along with separate proxy and matcher program.
The come-in client will be able to wrap screen/tmux/vnc to provide a finished product feeling
Business AngleThe wise folks have told us that the value is discovered by customers, so I don't want to go in there.
The development of basic ssh sharing is about 100 hours of work. Server deployment can be taken as another 50$ per month.
This can work on a freemium model. The 1:1 can be free for upto 1 hour or so. The persistent connection model can be paid for something like 1$ per machine and 1$ per user per month. This will also require to implement MIS like stuff, and some more fanciness which is another 100 hours of work.
So, it should be possible to bring up this service in 1 month flat.
Game for it ?