Restric access to self-hosted tty-proxy

[varac]

First of all: Thanks for this awesome project!
I want to host my own tty-proxy but would like to restrict access to it to trusted people/clients.
tmate once used an authorized_keys file which checked connecting ssh clients for authorization.
How could this look like for tty-proxy ? Could a nginx instance running in front of tty-proxy handle authorization, and how would the clients deal with it ?

[elisescu]

Hey, @varac ! Sorry for the late reply.

I don't think there's an easy answer to this in its current state, unless you start using an ssh tunnel for each tty-share connection, but that would not restrict the web clients side anyway.
But I'll leave this open and when I'll get some time, I'll think more about it.
Would be super helpful if you described a bit more in details which part of the connections (see below) you'd like to be restricted, and also what concerns you have in mind that this restriction would solve.

There are overall 2 connections of a session:
1: tty-share <--TLS--> tty-proxy
2: tty-proxy <--WSS--> web browser

[varac]

Hi @elisescu, I'd like to restrict my tty-proxy to a known group of people, similar to an ssh server where users authenticate agains a known_hosts file.
And so far I'm only interested in the first option. A shared secret would be fine!

[elisescu]

Hi @varac ! Got it. Unfortunately I don't see an easy solution that doesn't involve convoluted ssh tunnels.
I thought of adding something like this a while back, but didn't prioritise it - I thought that unless I add end-to-end encryption, the secret URl should be enough for security as long as the tty-proxy is trusted. Out of curiosity, what concerns you have if people outside that group would use your tty-proxy instance?

[varac]

I just want to limit any attack surface/possible abuse option. I haven't looked into the code and I don't want to imply any security concern, but I like to default to authentication whenever possible.

[elisescu]

Yeah, makes sense. I'll leave this open, and hopefully I'll have some time to look into something along these lines.

If you don't mind, could you tell me a bit more about how you use it, and in what context (personal/professional, etc)? Also, what other features do you think would be useful to have? What have you used before (if any), and why did you give tty-share a try?
I was thinking about adding end-to-end encryption (so tty-proxy wouldn't have access to the proxied data) - would that be something useful for your use-case, and would you use a 3rd party tty-proxy in that case, or you'd still prefer to use your own instance?
I was also thinking to add some "permanent" sessions (in which case ofc you'd need an authentication system, since the secret URL won't suffice) - so you could for example have tty-share run on a machine "permanently" and you could always have access to it, without having to start every-time a new tty-share. Have you needed anything like this?

I should put in place a better way to ask for feedback like this, but for now if you have a few mins to share your thoughts here, would be great. Thanks a lot :)

[varac]

E2E encryption would be a huge win in terms of trusting a 3rd party installation. However, I still would prefer self-hosting with restricting the user base with some kind of authentication.
Before I used a self-hosted instance of tmate-slave once it still had support for authorized keys (unfortunately it got removed later).

[liam-bilich]

Hi

We also started using the TTY-PROXY, the simplicity is very appealing and it works great!

Now we also need to be able to AUTH requests to both layers:

1. access to proxy server itself from the tty-share client
2. access to the web url that is produced to connect to the machine running the client.

Layer 1 being the most important as we don't want to allow external users
to abuse our proxy-server.

Theoretically anyone with knowledge to our proxy URL can initiate endless sessions
with no restriction.

One of the ideas that come to mind is to provide the tty-share client with an --auth argument
that will pass an API key (string) to the tty-proxy.

The proxy can use a hook, GET or POST to connect to an external API
and validate if to allow this token or not.

As such you will not need to provision the authentication, but just pass it along
and make a webhook (api call) from the tty-proxy to provided endpoint.

This will basically allow us to:

1. generate a token that we can validate
2. pass the token to the command tty-share --auth {mytoken}
3. before you establish the tunnel connection, tty-share will utilize the webhook
   and check  if token is valid, if not, don't open session.

hope it makes sense, would love to hear what you think.

[elisescu]

Hey @liam-bilich,

I think it depends on what you want to achieve in the end, and how many users you expect.

If you have only a handful of users, another option (besides your suggestion) is maybe using ssh keys for layer 1 authentication. So the tty-proxy would have access to a list of authorized keys and use that identity to authenticate the tty-share client, very similar to how ssh does it (I'd imagine the users in this case most likely already have ssh keys generated, so tty-share client could already default to the main key, if none is passed as an argument). And the management of the authorized keys can be either manual - you'd add them manually to the proxy server side, or have a simple server where the users could upload them.

For layer 2, I believe the simplest would be to have the tty-share choose a password and prevent the browser client access unless the password is correct (the password would be set as a command line argument).
This feels to me the most suited solution given the current design and "philosophy" behind the architecture and the responsibilities of both the proxy and tty-share command.

But of course, it very much depends on what you have in mind as the end goal, which btw I would be super happy and curios to hear more about (either here, or in a private chat). I'm always super interested in hearing more about how this is being used.

Let me know what you think :)

[liam-bilich]

Hi @elisescu

Thanks for the indepth reply.
We are basically using TTY-PROXY as a replacement of tmate (Self-hosted).
Our most basic use case is to allow users connect to their robotic edge devices
for debugging and doing system work.

We already have JWT token based security model for our users (humans)
so basically a JWT token that we can validate will simply conform to current
measures and will not require too much further development but a mechanism
for Authenticating this JWT.

The password mechanism you suggest is better then none of course,
but the password is easily transferable to other users once user sees it in the browser so it's not something
to rely on.

I think that a webhook for JWT is perhaps the simplest solution which should satisfy
many uses cases and can be considered a good practice.

let know if have other thoughts...

[elisescu]

Yeah, I think that's reasonable. I have in mind a simple idea of how it can be done without "polluting" the tty-share and tty-proxy with knowledge about the outside. I'll try to find some time this period to write it down, and would be happy to hear some feedback on it