But most of the time you can't directly SSH into your laptop at home because it's behind NAT, so you need an SSH bastion, and we figured it's not expensive to host, why not put one out there for free.
And the code is all on github. Teleport (https://github.com/gravitational/teleport) is the server/proxy part.
It's the first thing I do when setting up a new router.
I also like having a public IP on my desktop (and laptop) at work.
I mean in theory that would be just a few simple firewall rules that I wouldn't need to change, but on long enough time I would screw something up exposing myself, so the more layers the better.
Only a couple of developers use it, and only to run Apache or similar.
I work on an overlay network solution called Wormhole: http://wormhole.network
We've been using Teleconsole internally quite a bit as we have a distributed team of developers and ops folks. Now we hope you'll enjoy it too! :)
It has a web site too: https://www.teleconsole.com
Nice work. The explanatory GIF is actually quite helpful. I appreciate there's info for people who are uncomfortable with a hosted solution.
Reminds me bit of Vault unsealing protocol: https://www.vaultproject.io/docs/concepts/seal.html
$ echo 'multiuser on' > .screenrc
$ screen -x ID_OF_SCREEN
Teleconsole is made for situations when you can't SSH into another machine directly (it's behind NAT) - it will work on a laptop when you're in the internet cafe, or on the Raspbery Pi at home which you don't forward SSH connections to.
Also it creates single-use disposable SSH credentials for your guests: there's no need to create temporary users or share your own SSH credentials with anybody.
Finally, you can join using just a browser, which can be helpful in some situations.
I hope this helps!
We believe we made the session IDs sufficiently hard to guess...
Here is the where the session ID is picked: https://github.com/gravitational/teleconsole/blob/54c8bddb47...
Here is the source of that helper function: https://github.com/gravitational/teleport/blob/9bde8462f272e...
And at this depth, we can stop; https://golang.org/pkg/crypto/rand/ is documented as "a cryptographically secure pseudorandom number generator". If you would like to audit that, I commend you, but would also attest that the Go standard library, when it declares cryptographically secure, is about as reliable as it gets.
Total time to verify: about two minutes. I would understand if it's slightly slower for someone not previously experienced with golang and thus not knowing to grep for "crypto" in "crypto/rand", and I do not wish to make light of your (valid) desire that we all take these matters seriously. But sometimes things are simply correct. This, joyously, is one of those times.
Note my only complaint is they don't identify their assertion as a belief.
> Did you verify that this one is not stubbed out at this time, on your platform, in your particular jurisdiction? No?
I did, in fact. I've performed full diverse double compilation on the golang compiler and standard library using different toolchains and different versions of the toolchains and verified the binary results. I am indeed quite confident that this random method is not stubbed out in any place on earth you or I are likely to find it. Reconsider your presumptuous dismissal.
The layer below this in the golang standard library is documented as follows:
// On Linux, Reader uses getrandom(2) if available, /dev/urandom otherwise.
// On OpenBSD, Reader uses getentropy(2).
// On other Unix-like systems, Reader reads from /dev/urandom.
// On Windows systems, Reader uses the CryptGenRandom API.
I also believe the universe is made of four dimensions, one of which is time and moves almost entirely forwards, if you'd like to carry out any more attacks on things that are "faith-based" because they're insufficiently sussed out here. Might be a little out-of-scope on whether or not Teleconsole got their session IDs right, though.
Couldn't you say that about most any secret?
(I believe my ssh key is sufficiently hard to guess...)
The only thing that concerns me is the ease with which somebody can join a session maliciously. Have you considered adding an additional form of verification for joining sessions?
I understand that the assumption is that the first person I trust is you ;)
Whereas for a binary, they might go verify a signature or something more severe.
BTW typo on https://www.teleconsole.com - "on-premise infrastructue" near the bottom.
You could just use a VPN service between your two machines.
Another poor (paranoid) man solution is 1/ to rely on Tor to expose your local SSH server through NAT/firewalls, 2/ to use ephemeral classic SSH keys to allow the guest to login on the host 3/ to share the session with screen -x.
Much more secure IMHO, but probably slower and also a bit more complex to setup as the host and the guest must have Tor installed.
Never ever, ever curl redirect to bash.