Learn Tmux - Security & Hardening Best Practice

#Introduction

In episode 19 we covered multi-server & shared sessions — broadcasting commands to many servers at once, real-time collaboration in shared sessions, and permission governance across clients. The larger your tmux footprint, the larger the surface you must secure: a session anyone can attach to is a terminal anyone can snoop on — every keystroke, every output, every clipboard is wide open.

Security is often dismissed as "not tmux's business", when in fact the opposite is true. tmux sits between your terminal and your applications — the most strategic position in the system. It sees the passwords you type at the sudo prompt, the tokens printed by scripts, and logs carrying sensitive data. If this layer leaks, everything running on top of it is exposed too. Episode 20 is the security baseline: we lock sessions, prevent unauthorized attach, secure the socket, hide secrets from configs, and apply policies that make sense for production servers. All examples refer to tmux 3.7b as the latest stable version.

#Why tmux Session Security Matters

tmux's threat model is this simple: anyone who can reach the socket can attach to the session, and anyone who can attach can read and type inside it. There's no extra authentication — if the socket is reachable, control of that terminal changes hands.

There are four main attack surfaces:

1. The server socket — the Unix socket file that is the entry point. Loose permissions mean other users on the same machine can attach to your sessions.
2. Already-attached clients — read-write attach means commands can be typed on your behalf, including sudo and git push.
3. Config & environment — secrets leaking into a committed ~/.tmux.conf or into the environment tmux snapshots.
4. Input interpretation — misparsed escape sequences can become a keyboard injection vector.

The analogy is a house: locking the door while leaving a window open is pointless. In your digital workspace, a tmux session is the workroom; the door lock is the socket permission; and the alarm is the lock command. In this episode we install all of them.

#Locking Sessions with the Lock Command

#lock-session, lock-client, and lock-server

tmux has three lock commands with different scopes. All three run lock-command and make the screen locked until the user password is entered again:

tmux lock-session -t myname

tmux lock-client -t %0
tmux lock-server

When locked, the screen shows a password prompt and no input is forwarded to the pane until the correct user enters their password. This protects the session from someone walking by the terminal — exactly like a laptop lock screen.

#Auto-lock with lock-after-time

Manual locking only helps if you remember to do it. For shared machines or terminals often left unattended, set up auto-lock: after a number of seconds without activity, tmux locks the client by itself.

set -g lock-after-time 600
set -g lock-command 'clear'

lock-after-time is a server option: the value 600 means 10 minutes without activity, then tmux locks. lock-command 'clear' replaces the default command (usually lock(1) or vlock) with clear — the screen is cleared before the password is requested, so leftover on-screen information isn't visible to others.

#Preventing Unauthorized Attach

#Read-Only Attach: Seeing Without Touching

When someone needs to watch progress without being able to type, don't give them full control. Read-only attach lets a client see all output but forwards not a single keystroke to the pane:

tmux attach -r -t myname
tmux attach -f read-only -t myname

attach -r is shorthand for the read-only client flag (plus ignore-size). A read-only client can still run detach-client and switch-client — e.g. switching sessions — but can't type in the pane. This is very useful for screen sharing: teammates see exactly the same output, with no risk of pressing keys in a production session.

#Removing Unwanted Clients

A shared session (episode 19) can be "hitched onto" by clients you didn't invite. To clean up, detach other clients from the session:

tmux detach-client -s myname
tmux detach-client -a
tmux list-clients -t myname

detach-client -s myname removes all other clients from the myname session — the client running the command stays safe. -a removes all clients except the current one. Check who's connected with tmux list-clients before acting.

#Access Control at the Server Level

For multi-user environments, tmux 3.3+ has an access control list (ACL) via server-access. You can grant access, revoke access, or force a specific user to attach read-only:

tmux server-access -a devnull
tmux server-access -r devnull
tmux server-access -d devnull
tmux server-access -l

#Socket and Environment Security

#Choosing the Right Socket

The tmux server socket by default lives in $TMPDIR (or /tmp if unset) inside a tmux-<UID> directory — e.g. /tmp/tmux-1000/default. Two parameters determine its security: location and umask.

• tmux -L name uses the socket $TMPDIR/tmux-<UID>/name — useful for separating tmux servers per context, e.g. -L work vs -L personal.
• tmux -S /full/path places the socket at an absolute path you choose — flexible but its permissions must be maintained.
• The umask in effect when the server first starts determines the socket directory's permissions. Run tmux with umask 077 so no socket file is accessible by other users.

Socket kustom per konteksPeriksa permission direktori socket

umask 077
tmux -L work new-session -s prod
tmux -L work attach -t prod

ls -ld "$TMPDIR/tmux-$(id -u)/"
ls -la "$TMPDIR/tmux-$(id -u)/"

#Don't Put Secrets in the Config

The most common real-world hole isn't a leaking socket, it's config committed to git. The classic example:

setenv -g DB_PASSWORD 'supersecret'
set -g status-left "DB: #{DB_PASSWORD}"

The setenv line above puts a password in a config that will very likely end up in a public dotfiles repo. Worse: tmux's update-environment copies variables from the shell, so secrets that were once local can "stick" to the tmux server's environment. The rules are simple:

• Never commit secrets. The tmux config only stores structure, not values.
• Send variables via the environment when starting tmux: DB_PASSWORD='secret' tmux new -s prod — the value lives in the process, not in a file.
• Use setenv -h to mark variables hidden so they aren't inherited by panes: tmux setenv -h TOKEN.

DB_PASSWORD='supersecret' tmux new-session -s prod
tmux setenv -h TOKEN
tmux show-environment

#Security in Remote and Production Environments

#escape-time and the Risk of Keyboard Injection

tmux interprets sequences starting with ESC as escape sequences (arrow keys, Alt+key, and so on). The longer tmux holds a byte sequence to decide its interpretation — the escape-time value — the wider the window in which incoming bytes (e.g. program output starting with ESC) can be misinterpreted as keystrokes. That's the basis of the keyboard injection risk: output from one pane can trigger tmux keybindings as if the user typed them.

set -sg escape-time 10

Lowering escape-time to 10 milliseconds narrows that window while also making input feel more responsive — we'll cover that performance side in episode 21. In tmux 3.5+ the default is indeed already 10, but writing it explicitly protects you if you copy a config from a machine with an old tmux still using 500.

#Best Practices on Production Servers

The principle governing all of it is the same as hardening any other layer: give the least access possible, and remove access that's no longer needed. A healthy tmux is one that's rarely noticed — it works quietly in the background and doesn't become a lazy entry point.

#Common Pitfalls

1. Forgetting to lock a shared machine. On a shared office terminal, a session without lock-after-time means anyone can sit down and continue your work — including executing dangerous commands. Set up auto-lock.
2. Putting setenv passwords in ~/.tmux.conf. This config often ends up committed to dotfiles repos. Secrets must live in the process environment, not in a text file.
3. Giving observers read-write attach. "Just a quick look" ends with an accidental keystroke. Use attach -r and tighten further with server-access -r if needed.
4. Forcing socket permission 777. Breaks one of tmux's basic security guarantees. For sharing sessions, use the official shared session mechanism from episode 19.
5. Ignoring a high escape-time. Old configs using escape-time 500 open a wider interpretation window. Lower it to 10.
6. Running the tmux server as root. One typo in a root session affects the whole system. Run as a user with the least privilege possible.

#Conclusion

This episode gave you the security baseline for tmux: locking sessions with lock-session, lock-client, lock-server, and lock-after-time; preventing unauthorized attach via attach -r and detach-client; securing the socket with -L, -S, umask, and the server-access ACL; and keeping secrets from leaking out of committed configs. All of it closes the four attack surfaces we mapped at the start: socket, client, config, and input interpretation.

Key points to take away:

• Locking and auto-lock are habits, not optional features.
• Read-only attach shares information without sharing control.
• Secrets live in the process environment, not in config files.
• The most secure tmux is the one least seen.

In episode 21 we'll cover nested tmux & advanced input handling — handling tmux inside tmux when SSHing into servers, and optimizing mouse, extended keys, focus events, OSC 52 clipboard, and true color end-to-end. After securing the foundation, we'll polish the way you interact with it. See you in episode 21!