Briefly:
- Set up a guest account on your computer. Write a small script containing "tmux attach-session -S /tmp/guest-session -t guest". Make this shell script the login shell for the guest account (make sure you are patched against heartbleed ;-) )
- Create a guest group and add your user and the guest user to it
- Write a script for you that contains "tmux -S /tmp/guest-session -t guest new"
- Configure ssh for RSA login
- Whenever you want to work with someone, add their ssh key to the guest account's .ssh/authorized_keys. Then run your script to start the tmux session.
- They still won't be able to log in until you give read and write permissions to the tmux socket (which allows you to have some control over when people can log in). To allow them to log in: "sudo chgrp guest /tmp/guest-session"
Note that you still have to trust the person because they will be sharing your session. However, you will be able to see everything they are doing. When they ssh in, they will immediately join your tmux session (unfortunately without any notification -- need to see if there are some hooks you can use to notify when people attach to the session).
Having a shell script as a login shell is obviously a potential security hole, so you should make sure that authorized_keys only contains keys when you want people to log in.
There is a project somewhere that contains a lot of scripts for doing this kind of thing (I forget what it is called), but I think it is better to learn how to do it yourself ;-)
Just to add: tmux provides a read-only switch that guest (students, support, colleagues) won't interfere with the session, but can give advices/ask questions through another channel e.g. phone, irc, ...
tmux a -r -t ${SESSION_NAME} -S ${SESSION_SOCKET}
I would be happy to pay for the product or just pay someone to build it if it isn't hard.
Here are my assumptions: 1. I could enable this on a cheap cloud server to expose a terminal that will work with tmux and vim. 2. I could create an account for my friend(s) so that they could access the server securely from within thier browser. 3. There is no clientside install or config needed.
Let me know if you are willing to wire it together.
It's also perfectly performant on desktop (chrome with os x, air 2013), though still unusably slow on my phone (chrome on original motox).
This may be more of a testament to https://github.com/macton/hterm though! (apparently what gotty is using)
Considering Emacs is already thought of as a decent OS ("lacking a good editor"), I can only think:
"We have to go deeper."
Thanks for sharing.
You would need to set up gotty ahead of time with the specific demos, and embed requests for those iframes in slides or parts of slides.
We were going to use tmate, but having to compile manually on OS X caused issues. Pro tip, if you only include instructions on how to install you tool with homebrew, at least make sure your makefile works on OS X. Not everyone has drunk or wants to drink the homebrew cool-aid. I currently use macports and grow ever tempted with the passage of time to switch over to PkgSrc or even a Gentoo Prefix install. Gentoo probably would have won by now if it was better able to integrate with the native shell, path vs entering prefix wise.
^ Those are the key lines really.
It's running the command in a pseudo-terminal, capturing the output (as text) and sending it over a web socket.
(silent tears of joy)
It would still be wise to put some sort of auth or other security in front of it if you're not trying to share with the whole world. I think I would be cool if there was some basic mechanism built in.
Gotty + Pagekite (or ngrok) = remote happiness.
nice.
