Shared Tmux Operations Sessions on a Bastion Host: An Architecture Note

The Problem: Shared Shells That Survive Disconnects

When several operators need to work on the same bastion host—a hardened server that acts as the controlled entry point into a private network—the default approach of independent SSH sessions breaks down. Long-running commands die when a laptop lid closes or a network drops. Two engineers cannot watch the same output or debug the same deployment in real time. The goal is a single, persistent shell environment that multiple people can attach to and detach from without killing the work inside.

The smallest suitable design is one tmux server per bastion host, bound to a dedicated UNIX socket, running a single named session. No extra daemon, plugin, or proxy is required. In tmux terminology, each split region is a pane; the server owns those panes, and clients are thin terminals that connect, display output, and forward keystrokes.

Requirements for a Bastion Operations Session

Before choosing a design, define what the session must do:

• Persistence: Work survives operator disconnects and network failures.
• Sharing: Multiple operators attach from independent SSH sessions and see the same pane content, scrollback, and environment.
• Simplicity: The solution should not introduce a new daemon, database, or web service to maintain.
• Access control: The mechanism must not silently widen access to the host.

The Smallest Suitable Design

Run one tmux server per bastion host with a custom socket path, for example /run/tmux-ops/tmux-ops.sock, and a single session named ops. Clients attach using:

tmux -S /run/tmux-ops/tmux-ops.sock attach -t ops

This requires no extra daemon or plugin. The tmux server process owns the panes; clients are thin terminals that connect, display output, and forward keystrokes.

Server and Socket Layout

Create a dedicated directory for the socket with restrictive permissions. Do not use /tmp or another world-writable directory.

# Run as root or via configuration management
sudo mkdir -p /run/tmux-ops
sudo chown root:ops-group /run/tmux-ops
sudo chmod 750 /run/tmux-ops

Start the server as a dedicated service account, not as root:

# Run as the ops service account
tmux -S /run/tmux-ops/tmux-ops.sock new-session -d -s ops

The -d flag starts the session detached. The -S flag specifies the socket path. The -s ops names the session.

Client Attachment

Operators attach from their own SSH sessions. Because the socket is group-writable, membership in ops-group is the access control mechanism.

Trust and Data Boundaries

The UNIX Socket Is the Security Boundary

The UNIX socket is the primary trust boundary. A UNIX socket is a special file that processes on the same host use to communicate. Any process with write access to the socket can inject keystrokes into panes. The default per-user socket in /tmp/tmux-$UID is private to each user, but a shared socket requires explicit directory and file permission management.

Output Visibility and Read-Only Limits

All attached clients see the same pane content, scrollback, and environment. tmux does not provide per-pane ACLs. An ACL, or access control list, would restrict which users can read or write specific panes; tmux has no such feature. Read-only clients (attach -r) reduce input risk but are advisory and do not hide output. A determined user with socket write access can still send keys.

Operational Checks

Verify the server and socket state before and after changes:

# Check that the server is running and the session exists
tmux -S /run/tmux-ops/tmux-ops.sock list-sessions

# Inspect socket ownership and permissions
ls -l /run/tmux-ops/tmux-ops.sock

# Enumerate active attached terminals
tmux -S /run/tmux-ops/tmux-ops.sock list-clients

# Confirm the server process
pgrep -a tmux

Expected checks: list-sessions reports the named session and its window count. ls -l shows the socket owned by the service account and group with a restrictive mode. list-clients reports each attached terminal. pgrep shows the server process.

Failure Modes

A tmux server crash terminates all panes and session state. Deleting the socket while the server runs creates orphaned processes. Very different client terminal sizes cause display artifacts. Permission drift on the socket directory blocks new attachments.

Failure	Effect	Mitigation
Server crash	All panes and session state terminate	Run critical work with external checkpoints; accept single point of failure
Socket deleted while server runs	Orphaned server process; new clients cannot attach	Kill the server process and restart; do not recreate the socket file
Permission drift on socket directory	New attachments fail	Monitor ownership and mode on /run/tmux-ops
Terminal size mismatch	Display artifacts	Configure window-size and aggressive-resize behavior

Conditions That Would Change the Design

Switch away from this design if you need immutable audit logging, strict read-only enforcement, browser or cross-host access, or high availability. tmux alone does not provide these. Adding a proxy, logging wrapper, or different tool becomes necessary.

Immutable audit logging requires tamper-proof records that operators cannot alter; tmux scrollback is mutable. Strict read-only enforcement requires kernel- or cryptographic-level guarantees, not a client flag. Browser access requires an HTTP or WebSocket gateway. High availability requires failover between hosts, which a single tmux server cannot offer.

A Practical Verification

This design assumes a standard tmux release with UNIX socket support, which has been stable across major distributions for years. Verify your local tmux version with tmux -V if you rely on newer options.

To confirm the design works before deploying it, create a test socket and start a throwaway session:

tmux -S /tmp/test.sock new-session -d -s test

Attach from a second terminal:

tmux -S /tmp/test.sock attach -t test

Confirm both clients see the same pane. Run tmux -S /tmp/test.sock list-clients to verify attached terminals, then detach and re-attach to confirm session persistence. Inspect the socket with ls -l /tmp/test.sock and stat to confirm ownership and permissions match the intended group access model. Clean up by killing the test server and removing the socket.