By the way, if you want to share your terminal ephemerally with someone over SSH, I swear by http://tmate.io/. It was something I desperately needed a solution for, and tmate delivers very very well.
One of these days I need to write a blog post on how to do it, but I pair program with my colleagues over ssh and tmux.
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 ;-)
That's pretty much exactly what tmate does (it uses tmux under the hood). However, I was looking at how to do this myself and couldn't figure out how to share my session and only allow people into that, rather than the whole system, so thanks!
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, ...
They're two, really: One is when I want to collaborate with a friend on a project (we both use vim, so we work on the terminal), and I don't want to set up a new account and transfer all the files, set up the environment and give him free rein on it, and the other is to quickly debug some issue on a remote friend's computer while he can see what I'm doing and learn from it.
I'd like to use this to provide a development environment for a friend in Africa trying to learn to program. He has random access to random computers so any client side install is a problem.
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.
I recommend taking a look at CodePicnic, which gives him a fully-functional Linux image front-ended by a JavaScript UI which you can embed anywhere. I have successfully used it from e.g. iPhone Safari.
For historical reasons, it is most popular with Twilio developers. I find it indispensable for doing any sort of development where you need to get asynchronous callbacks from your API of choice.
I wonder if it would be useful to run emacs within a browser based editor like Atom. It even seems plausible to be able to seamlessly switch editors "containers" for particular operations without even leaving a file (using the editors API to replace the pointer in the same place).
How's Emacs doing these days? I know it was really popular a few years ago when everyone was editing files in it, but since I started with linux I only ever see people use Vim.
Very cool! I was always struggling during live presentations switching from browser to console window. Now I can use a browser window on the projector screen for both presentation and console.
Not to be snarky, but what's wrong with Alt+Tab (Or platform-specific equivalent)? You still have to use multiple windows -- that both happen to be in the browser doesn't seem particularly important.
Ideally, you could even have console demos "embedded" within the presentation itself, perhaps even multiple consoles in order to show how changing state in one system affects another system.
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.
Everytime I use a terminal in the browser for a live demo I end up running into horrible keybinding conflicts between the two (hitting C-w to delete backwards word and instead closing the tab).
Damn it, I literally could have used this last night. Ended up using a disposable VM on DIgitalOcean for shared tmux.
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.
I've always thought it'd be interesting to write a display driver for VirtualBox that uses WebGL so you can essentially get a desktop through a web browser...
I can't read much of Go so can anyone explain how does this work at a high-level? The Vim editing example looks really cool! Does it keep taking a snapshot of the running command and send the data via a websocket?
Gotta give this a shot. Very similar to shellinabox -- which also allows https, login shell, etc. On the other hand shellinabox has not been maintained since 2012/13.
I think it comes with all the usual caveats of "don't run super sensitive things on external networks". My guess is the motivation is for presentations and other "one-time" usages like that.
There is a flag to allow/prevent write access, so third parties wouldn't be able to use your terminal unless you allow it (I believe its disabled by default) . I also think (if I'm reading correctly) that it only shares a single process and will terminate the session when that process exits, which gives you a little added security in that someone with write access only has the same level of access as that process (which for some processes could mean a lot).
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.
