Sharing your local terminal with trusted peers.

Published on Sep 23, 2020

Over the past few years I worked different remote setups. I often miss the pair programming fun from my time at Thoughtworks. There are numerous tools you can use for remote pair programming, or a quick get together to work on an issue that is better investigated together. A colleague of mine wrote a blog post how to use a remote tmux session for pair programming a while ago. I recommed this article because it covers most of the basics of what I would need to elaborate here. This is great if you meet together on a dedicated, remote server (with ssh and tmux installed), but what if you just want to share your beloved local dev environment, which your favorite text editor, shell aliases and more with your colleague(s) ? There no place like localhost !


That’s where tmate comes to the rescue. Tmate is a fork of tmux which lets you invite others to join your terminal, just like a remote tmux session but on your very own device. It consist of a tmate binary which is used as the client to connect to a shared session, and tmate-ssh-server, which connects the clients together. runs a free service which you can use to easily share your terminal. However, it’s a centralized service and I don’t feel too comfortable sharing one server with possibly hundreds of others while sharing my terminal.

History of tmate-ssh-server

But tmate-ssh-server is free software so you can host it yourself! Another colleague of mine added support for limiting trusted ssh client via an authorized keys file, so you could self-host tmate-ssh-server in a controlled and trusted environment. Unfortunatly, this feature was taken out again during a refactoring, and there is a pending feature request to re-add it. If you want to continue running your own tmate-ssh-server you need to compile a particular version of it. On top of that, you also need to use tmate 2.3.1 (static binaries are linked as assets in the github release page).

That’s a pretty nasty state because you can’t easily patch security issues etc. However, I still prefer this over the centralized service of

Helm chart

I maintain a custom tmate-ssh-server docker image which is build from the last commit before authorized_keys support was removed. And I am running it on kubernetes using my tmate-ssh-server helm chart. See for how to install my chart repo. Both lack proper documentation, I know, but if you are familiar with docker and helm you will find your way around.

So far I’m super happy with it and use it regularly to pair with others. Enjoy !