read only sessions

[ObiWahn]

Hi Nicolas,

i think it would be cool if a client could request to create a remote read only tmux server. I think it goes in the direction of the 3rd crossed out point in the future work section.

Maybe a "bool allow_read_only" could be added to tmate_session for the "server/demon role". Is that correct place for such information?

Regards

Jan

[nviennot]

Hi Jan Christoph, how is your suggestion different from the current readonly implementation?

[ObiWahn]

Ah is it already implemented? I was under the impression that always both types are created in the slave. So that you can connect to a read write session if you have or guess a valid key, is this not the case?
I would love to launch tmate with tmate--read-only and only the client that launched the session will have write access.

[nviennot]

I would love to launch tmate with tmate--read-only and only the client that launched the session will have write access.

I'm not sure what's the benefit compared to the current implementation where you can pick the r/w or read-only connection string.

[nviennot]

So that you can connect to a read write session if you have or guess a valid key, is this not the case?

Assuming an attacker can try a million tokens per second (which will hardly go unnoticed),
and assuming there's one billion sessions on the tmate.io servers, it would take him on average 10231884636185826482 centuries to guess a single session token.

So I wouldn't worry about someone guessing a valid key.

[ObiWahn]

Maybe the user gives out the wrong key because he has a bad day. An alias tmate="tmate --read-only" could save the day. I tend to do stuff like that on some systems really often. And be it so nobody powers down a server when he is about to shutdown his laptop to go home. The ability to modify such behavior is really useful.

[nviennot]

I see. I'll think about it in how to address the issue.

[AbdelElrafa]

Hi @nviennot Can you add this feature? It would be great to be able to launch readonly mode.

[eminence]

In the past I've given out read-only connection strings only to have someone discover the read-write string was visible in the terminal. Having a read-only mode that doesn't provide/show a read-write connection string would be useful to prevent these types of mistakes.

[nviennot]

Good point. Will add to the wish list.

[DustVoice]

For me one thing would even be sufficient: Having a --read-only flag, that just doesn't print the non read-only session keys!

I'm live streaming programming sessions and am using tmate, because one can't read sh*t at 480p. That means that I always have to launch a new tmate session on my 2nd monitor, as a viewer would be able to see the non read-only key for a brief amount of time. This is a big hassle for me and I would argue that just removing the output will be sufficient for me, because as you mentioned, brute-forcing the token would probably be harder than some kind of ip-based attack.

Thanks in advance for you SUPERB work. You have made my life so much easier. I really do appreciate it

[jonasstein]

default should be --read-only only if the user starts with --read-write it should be possible to get write access. A program should fall back to the safe condition if a parameter is missing or misunderstood.

[nviennot]

I agree, but I won't fix this anytime soon.

As a workaround, one can run:

$ tmate -F -S /tmp/tmate.sock | egrep 'locally|(read only)'
To connect to the session locally, run: tmate -S /tmp/tmate.sock attach
web session read only: https://tmate.io/t/ro-ML5bu8wsGZvsSwWqwxsH3eZcb
ssh session read only: ssh ro-ML5bu8wsGZvsSwWqwxsH3eZcb@nyc1.tmate.io

And then run tmate -S /tmp/tmate.sock attach to get onto the terminal. The read-write access token will not be shown on the display.