Show HN: Share your Unix shell with people you trust | Hacker News Reader

Show HN: Share your Unix shell with people you trust

github.com

87 pointsold-gregg56 comments

You can do this with screen/tmux too...no need to connect to some server where you can't audit their code.

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.

And the code is all on github. Teleport (https://github.com/gravitational/teleport) is the server/proxy part.

https://samy.pl/pwnat/

That's really cool, can't wait to play with it, thanks!

Are there people with SSH running on their laptop at home who haven't set up port forwarding?

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.

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.

There is a firewall between the work network and the outside world. You'd need to ask the sysadmin (me) to open a port.

Only a couple of developers use it, and only to run Apache or similar.

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.

[0]: https://www.zerotier.com

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 work on an overlay network solution called Wormhole: http://wormhole.network

Hello HN,

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

No fair; Mr. Robot references unduly prevents me from having a skeptical look at the product :)

Nice work. The explanatory GIF is actually quite helpful. I appreciate there's info for people who are uncomfortable with a hosted solution.

The poor man solution: https://gist.github.com/cyrus-and/713391cbc342f069c149

verify=0 on both sides? Yeah... how about nope. Why even bother with openssl without authentication?

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.

I've used https://tmate.io/

I use tmate almost daily for my remote consultancy gigs.

As an aside, Solaris can enforce a "two-man rule" for system access via its Role-Based Access Control system:

https://blogs.oracle.com/gbrunett/entry/enforcing_a_two_man_...

That looks really cool. Is there something similar for Linux?

Reminds me bit of Vault unsealing protocol: https://www.vaultproject.io/docs/concepts/seal.html

What's the benefit for that? Why can't you just give ssh key / pass to the other party and share a multiuser screen?

    $ echo 'multiuser on' > .screenrc
    $ screen

Another tty

    $ screen -x ID_OF_SCREEN

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.

I hope this helps!

>We made the session IDs sufficiently hard to guess...

We believe we made the session IDs sufficiently hard to guess...

FTFY

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

Verifying randomness is not a 2 minute task.

It... really is sometimes. GP did so. I just verified.

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.

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.

> We believe we made the session IDs sufficiently hard to guess...

Couldn't you say that about most any secret?

(I believe my ssh key is sufficiently hard to guess...)

It's not hard to make things hard to guess.

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.

I would simply recommend to use full solution https://www.gravitational.com/teleport if you want to have proper auth

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.

> curl https://www.teleconsole.com/get.sh | sh

I understand that the assumption is that the first person I trust is you ;)

Why do you think a curling auditable shell code into an executable pipe is riskier than executing a compiled binary?

Just as an example, out of many reasons:

https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

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.

Looks handy. Any chance of Windows support?

BTW typo on https://www.teleconsole.com - "on-premise infrastructue" near the bottom.

Thanks for the heads up. Unfortunately, we don't currently have Windows on the near term roadmap.

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

This would be great when you need to hire a freelancer to help with a 40 minute configuration fix on a server.

Someone also mentioned it as a possible tool to use during practical Devops interviews - e.g. "Set up this MySQL instance"

I've done this with screen using shared terminals.

You could just use a VPN service between your two machines.

Nice tool.

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.

How is this different from ngrok?

Is the server software available?

https://github.com/gravitational/teleconsole#support-for-pri...

does this go over corporate firewall?

it does outbound SSH and HTTPS connections to teleconsole.com so if those are allowed, then the answer is yes

Their quick install method makes me very sad.

Never ever, ever curl redirect to bash.

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.

Reply on news.ycombinator.com