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.

Pre-requisites

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.

Follow the instructions on the wemux readme to get setup. I’ll also assume you have, and know how to use tmux.

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. Install the vlock command and add the following to your .tmux.conf.

# 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 database in 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 /usr/bin/wemux_sh;

#!/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 at /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 is the script I wrote as of today, but I may update it in the future.

This should be sourced in whichever way you prefer on login. I use zsh but I don’t think I’ve done anything that’d prevent the same code working for bash. Equally it could probably be written as a standalone script rather than sourced but this is just the way I’ve done it.

Usage

My helpers add a few commands to make enabling and disabling access to wemux easy, and sharing the login information with others.

• wemux_enable scrambles 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_get_password or wemux_get_info.
• wemux_disable will disable further logins to the guest account. This won’t kick off any existing users though!
• wemux_get_info requires an argument and should print out a string that you can send to a guest to let them log in including;
  • username
  • password
  • address
  • expected ssh host keys This information will also be copied to the clipboard if there’s a $DISPLAY variable 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 :-p. Running wemux_get_info hostname should work for everyone though.

Limitations

• 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_disable function 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.

Alternatives

[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.