If both machines aren't separated by NAT, you could. Except you'd need to either share you local password or an SSH key with another party, which is pretty inconvenient.
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.
That would be me. I have openvpn setup everywhere, and I would hate to have a public IP on a computer on which I work. Sooner or later I would forget about adding some iptables for redis, database or dev applications that I'm running.
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.
I used to, but ZetoTier[0] has made that a thing of the past. Now, no matter where I am or what sort of connection I have, it's like I have all my devices (and a few other people's) on a local LAN. I use it all the time to SSH into my laptop from my phone when I leave it someplace. I really can't recommend it highly enough.
You could have an overlay network to give full visibility between hosts avoiding NAT completely. Also, inside the overlay network the IP addresses do not necessarily change, as opposed to the public IP address of your laptop when you move it somewhere else :-)
I wouldn't use it, but it's still an improvement over unencrypted data. This requires an active attacker to do anything, whereas unencrypted data allows a passive attacker to eavesdrop.
Ever? For when you need to make your (already encrypted) SSH traffic look like HTTPS because of overly restrictive firewalls. Of course, that's not what the linked script is doing.
Mmm.. I hoped the README covers it, but I'll try again:
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.
Its just a 20 byte random token, not exactly rocket science. Cursory glance on the code shows that its generated using crypto/rand which is exactly how it should be done. Some degree of skepticism is always good especially regarding security, but when verifying something takes like 2 minutes or something, maybe do that before posting disparaging comments on HN
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.
This is faith-based verification. You'd need to get down into the math, and even then, we're talking about stuff where it's not clear where the bleeding edge research ends and the real randomness begins. Worse, library methods can be stubbed out. Did you verify that this one is not stubbed out at this time, on your platform, in your particular jurisdiction? No? I didn't think so.
Note my only complaint is they don't identify their assertion as a belief.
I don't know what to say. I could write you an entire dissertation on the math, my previous formal education in cryptography and randomness, my reading of that code inside the golang standard library, and so forth. But you seem to be stating that you're literally unsatisfiable by any series of words from any other humans on the planet at any level of transitivity at all, even one hop. So it begs the question of why engage in communication at all, when the endgame you're interested in seems be defeat in detail.
> 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.
If you find those APIs to be insufficient on those operating systems... go you. You have some security papers to publish.
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.
Well, fair enough. I do stand by my language quibble for reasons stated, namely that new math research does move the needle from time to time. Understatement about the security of tokens is just courteous. But thanks for putting this in perspective.
Great work! I'm excited to see what people do with this.
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?
Well... yes. Teleconsole itself is just a Teleport (http://gravitational.com/teleport) server configured _without_ extra authentication. But Teleport by default has user accounts with 2nd factor auth and integration with Google Apps.
See also "GoTTY", also hosted on GitHub.com for a similar project that is not associated with a service (i.e., you must host it yourself). It has write support and there is a separate "gotty-client"
I'd imagine you could mitigate some of the risks of making it publicly available by integrating with Keybase and allowing users to specify what Keybase id's should be allowed to access it.
You can share tmux sessions in this manner. The only limitation is screen size in that case - it will always use the smallest screen size that the session is being accessed from.
You missed the 'er' in riskier. Do you seriously think this is more of a threat than executing binaries you have to reverse engineer to know what they do?
Well one could argue that having a shell script invites people to review it, then the article's behaviour could change it. So people might trust it when they otherwise wouldn't have. But... they should just download it locally, verify, and run.
Whereas for a binary, they might go verify a signature or something more severe.
because you can't check the keys to attempt to detect an MITM replacing the binary before you execute it. Often, the shell script then downloads additional binaries, which are installed and executed immediately, making it even harder to check.
Nice for relatively low-security systems you want to share. Also, the Mr. Robot reference is adorable. But I wouldn't trust Darlene if I was Elliot. Even after [REDACTED].
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.
Who are you telling that to? People that will see your comment are HN readers, which in general are aware of the risks of piping the output of a random URL to your shell, they will — if necessary — audit the code before execution. On the other hand, if you are writing that warning for people without skills to audit a shell script or the ability to understand why executing that command is bad, then you are not reaching anyone, there is a discussion about this every time a new website offers this installation method, we get it, it is not safe, whatever, people will use it if they want, and people that understand the insecurity of the process will not.
