Buddy/pair programming and mobbing can be a really useful technique to share knowledge and improve code quality.
I prefer to use tmux over SSH to do this, as it’s fast and allows everyone at least some ability to customise their terminal.
It’s possible to use pure tmux to set up an environment to do this but it can be awkward (I always forget myself!) so here’s my setup.
It’s not an exhaustive guide but it should get you going.
wemux is a really handy tool to help manage some of the common tasks so I’ve built my approach around this.
It’s just a wrapper for tmux so doesn’t mess too much with the enviroment.
You’ll need GPG setup and pass too for my scripts, but you could probably make modifications to avoid either.
It’s also wise to setup locking in your tmux configuration.
vlock command and add the following to your
# Enable locking set -g lock-command vlock set -g lock-after-time 300 # Seconds;
Setup - Guest User Account
Create a new user account with a random username. I store this in a pass
nx6/$(hostname)/wemux_username so it can be accessed by my
script but is still relatively hidden.
Setup - Login Shell for Guest
Create a script to be used as the login shell for guest. It should be simple but
prevent the guest breaking out and accessing the normal shell.
I use the following under
#!/bin/bash source /etc/profile select mode in "mirror" "pair" "rogue"; do exec wemux $mode; done exit 1
You’ll need to add the path, in this case
/usr/bin/wemux_sh to the shells file
/etc/shells to allow it to be used as a login shell.
Then update the user to use this login shell;
sudo usermod RANDOM_USERNAME --shell /usr/bin/wemux_sh
Setup - Install Helpers
I’ve written a number of helper functions to help me manage access to my wemux.
This should be sourced in whichever way you prefer on login. I use
I don’t think I’ve done anything that’d prevent the same code working for
Equally it could probably be written as a standalone script rather than sourced
but this is just the way I’ve done it.
My helpers add a few commands to make enabling and disabling access to wemux easy, and sharing the login information with others.
wemux_enablescrambles the login password and reactivates the guest account if it’s been disabled by
wemux_disable. The password is stored encrypted and can be viewed using either
wemux_disablewill disable further logins to the guest account. This won’t kick off any existing users though!
wemux_get_inforequires an argument and should print out a string that you can send to a guest to let them log in including;
- expected ssh host keys
This information will also be copied to the clipboard if there’s a
$DISPLAYvariable available. The argument is meant to specify the interface you want the guest to connect on but it’s a bit “custom” to my environment
wemux_get_info hostnameshould work for everyone though.
- At the moment I can only have one session at a time for sharing.
- I often use pure tmux and there’s no easy way to promote my normal tmux session to wemux.
- All remote users are treated equally.
- It’d be nice to scramble the username as well as the password.
- In general it’d be nice to make the whole thing slightly more secure.
The password scrambling and
wemux_disablefunction help a little, but I still double check users are really gone when I’m done and I’m sure there’s a million vulnerabilities.
[tmate] provides one alternative. By using a central server as a middleman it doesn’t require direct connection between participants but I don’t like having to trust that central server and hosting one myself, even with a conveniant docker container negates much of that conveniance.
I also found it slightly more limiting. I couldn’t seem to kick participants with normal tmux commands, and there’s not a proper way to reattach to your own session yet.Go Top