Sharing a Terminal Between Users with tmux (and Modern Alternatives)

Blog / Server Management · December 8, 2014 · Updated June 10, 2026 · 10 min read
Sharing a Terminal Between Users with tmux (and Modern Alternatives)

To share a live terminal with tmux, both people attach to the same session. If you share an account, one person runs tmux new -s shared and the other runs tmux attach -t shared — both now see and type into the same screen in real time. If you are on separate user accounts, start the session on a shared socket with tmux -S /tmp/pair new -s pair, grant the other user access to that socket, and they join with tmux -S /tmp/pair attach -t pair.

That is the whole idea: tmux multiplexes one terminal so several clients can render and control it together — ideal for pair programming, walking a teammate through a fix, or two admins debugging a production box side by side. Unlike Teamviewer, AnyDesk, or a remote desktop, you share only the terminal, over plain SSH, with no GUI streaming and almost no bandwidth. The catch is access control: a shared session is a real shell, so who can attach matters as much as how you attach.

Key takeaways

  • Same account: tmux new -s shared, then the other person runs tmux attach -t shared — simplest setup, no extra permissions.
  • Different users: start tmux on a shared socket (tmux -S /tmp/pair new -s pair) and give the other account access to that socket file; they attach with tmux -S /tmp/pair attach -t pair.
  • Security trade-off: whoever can write to the socket gets a full shell as the session owner. Prefer a dedicated Unix group with chmod 770 over a wide-open chmod 777.
  • Read-only viewers: add -r (tmux attach -r) so a teammate can watch without typing.
  • Mirrored vs independent views: plain attach mirrors the same window; grouped sessions (tmux new-session -t) let each person move between windows independently.
  • Modern alternative: for ad-hoc remote help, tmate gives an instant SSH/web link with no firewall changes; the shared-socket method stays best for users already on the same server.

What is tmux and why share a terminal with it?

tmux (terminal multiplexer) runs a persistent server process that holds your sessions, windows, and panes. Your terminal is just a client attached to that server, which is why you can detach, close your laptop, reconnect later, and find everything still running. The same architecture lets more than one client attach to a single session at once — the basis for terminal sharing.

Sharing a terminal this way is text-only and runs straight over SSH, so it is fast, scriptable, and works on headless servers where a remote desktop is not an option. Common uses: pair programming in vim or an editor, mentoring a junior engineer, joint incident response, or demoing a CLI workflow.

How do you install tmux?

tmux ships in every mainstream distro's package repository. On Debian or Ubuntu:

sudo apt update
sudo apt install -y tmux

On RHEL, Rocky, AlmaLinux, or Fedora:

sudo dnf install -y tmux        # macOS: brew install tmux

Confirm the version — anything from tmux 2.x onward supports the sharing commands below, and 3.x is what current distros ship:

tmux -V        # e.g. tmux 3.4

How do two people share a session as the same user?

This is the easiest case: both people log in to the same account (for example, a shared deploy user over SSH). The first person starts a named session:

tmux new -s shared        # full form: tmux new-session -s shared

A bare tmux new-session (no -s) creates a session numbered 0, then 1, and so on — workable, but a name like shared is far easier for the second person to target. Once the session is running, the second person logs in to the same account and attaches:

tmux ls                   # list sessions: shared: 1 windows (created ...)
tmux attach -t shared     # attach by name (or: tmux attach -t 0 by number)

Both terminals now mirror the same window in real time — keystrokes, output, and pane layout are identical for everyone attached. To leave without killing the session, detach with the prefix key followed by d (default prefix is Ctrl-b, so press Ctrl-b then d). The session keeps running for whoever is still attached, and you can re-attach later with the same command.

How do different users share a session via a shared socket?

When the two people use different Unix accounts, they cannot see each other's default tmux server — each user's server listens on a private socket under /tmp/tmux-<uid>/. The fix is to start tmux on an explicit socket path (-S) that both accounts can reach. The session owner runs:

tmux -S /tmp/pair new -s pair      # create the server + session on a shared socket

The socket file /tmp/pair now controls the session, but only its owner can access it. The guest needs read/write permission on that file to attach. The quick-and-dirty way is to open it to everyone:

chmod 777 /tmp/pair                # WARNING: any user on the box can now attach

The safe way is a dedicated group. Create a group, add both users, set the socket's group ownership, and restrict it to that group with 770 so no other account can join:

sudo groupadd pair
sudo usermod -aG pair alice
sudo usermod -aG pair bob

# owner runs this after creating the session:
chgrp pair /tmp/pair
chmod 770 /tmp/pair                # owner + group only, not world

Now the second user attaches by pointing at the same socket and session:

tmux -S /tmp/pair attach -t pair

The security trade-off you must understand

Attaching to a shared session means running commands inside the owner's shell, as the owner's user. Anyone who can write to the socket effectively has that user's full privileges — they can read its files, use its SSH keys, and run anything it can. So the socket permissions are your access-control boundary. Practical rules:

  • Never leave a chmod 777 socket around — it is a local privilege-escalation gift. Use a group and chmod 770.
  • Only invite people you would trust with that account's shell.
  • For someone who just needs to watch, attach them read-only so they cannot type:
tmux -S /tmp/pair attach -r -t pair    # -r = read-only client (view, no input)
  • Put the socket in a private directory (for example /tmp/pair-dir/ owned root:pair, chmod 770) so the socket cannot be replaced by another user.
  • Delete the socket when you finish (rm /tmp/pair) and run tmux -S /tmp/pair kill-server to tear the session down cleanly.

For servers you manage at scale, baking these rules into configuration management — rather than running ad-hoc chmod commands — keeps things consistent and auditable; see our guide on Ansible for server process automation.

Mirrored or independent views? Sharing windows and panes

A plain attach mirrors the active window: everyone sees the same window and pane, so if one person switches windows, everyone follows. That is perfect for true pairing where you want to look at exactly the same thing.

Sometimes you instead want a shared set of windows but independent navigation — you on window 1, your teammate on window 2, both inside one session's process group. Grouped sessions do this. Create a second session linked to the first with -t:

# attach to the same windows but move between them independently
tmux new-session -t pair -s pair-view

Both pair and pair-view share the same windows and panes (open a window in one and it appears in the other), but each client can focus a different window. Useful tmux commands while sharing:

Action Default keybinding
Detach (leave session running) Ctrl-b then d
Split pane vertically / horizontally Ctrl-b then % / "
Move between panes Ctrl-b then arrow keys
Create / switch windows Ctrl-b then c / n
List attached clients tmux list-clients

Modern alternatives: tmate, Live Share, SSH, and screen

The shared-socket method is great when everyone already has an account on the same server. For remote pairing across the internet — where the other person is not on your box and you do not want to open firewall ports or hand out logins — modern tools are easier and safer. Here is an honest comparison:

Method Who / where it fits Security model Ease
tmux shared socket Two+ users already on the same server Unix socket perms; guest gets a real shell as the owner Moderate — needs a group + chmod setup
tmate Ad-hoc remote help; guest has no account on your box Disposable SSH/web link via tmate relay; revoke by killing the session; read-only links available Easiest — one command prints a link to share
VS Code Live Share Editor-centric pairing (code, debugger, shared terminals) Microsoft account auth; host controls per-session permissions Easy if both use VS Code / Cursor
Plain SSH + tmux Guest already has (or can be given) an SSH account Standard SSH auth + the tmux session perms above Moderate — depends on SSH access being in place
GNU screen (screen -x) Legacy boxes where tmux is unavailable Same shared-shell risk as tmux; needs setuid for cross-user Legacy — prefer tmux on anything modern

tmate is a tmux fork built specifically for instant sharing: run tmate, and it prints SSH and web URLs (including read-only variants) that you paste to whoever is helping — no firewall changes, no accounts on your server, and the link dies when you end the session. For one-off remote help, it is the fastest path. For two engineers already logged in to the same production server, the native shared-socket approach keeps everything local with no third-party relay.

Which method should you choose?

  • Same account, same box: just tmux new -s shared and tmux attach -t shared. Nothing else to configure.
  • Different users, same box: shared socket with a dedicated group and chmod 770; add -r for viewers.
  • Remote help, no account for the guest: reach for tmate — instant link, nothing to open up.
  • Editor-first pairing: VS Code Live Share if both sides live in VS Code.
  • Stuck on a legacy host without tmux: screen -x, but plan to migrate to tmux.

Keeping shared-access servers patched, permissioned, and monitored is exactly the kind of work our server maintenance and DevOps services handle. If your pairing happens around deployments, our walkthrough on deploying Django with uWSGI and Nginx via an Ansible playbook shows how to script the surrounding setup so live debugging is the exception, not the routine.

Frequently Asked Questions

How do I share a tmux session with another user?

If you share the same account, one person runs tmux new -s shared and the other runs tmux attach -t shared — both see and control the same screen. If you are on different user accounts, start tmux on a shared socket with tmux -S /tmp/pair new -s pair, give the other account access to /tmp/pair (ideally via a group with chmod 770), and they join with tmux -S /tmp/pair attach -t pair.

How do two different Linux users attach to the same tmux session?

Each user's tmux server normally listens on a private socket under /tmp/tmux-<uid>/, so different users cannot see each other's sessions by default. Start the session on an explicit shared socket (tmux -S /tmp/pair new -s pair), grant the second user read/write access to that socket file, then have them run tmux -S /tmp/pair attach -t pair. Use a dedicated Unix group and chmod 770 on the socket rather than chmod 777.

Is sharing a tmux session secure?

It is as secure as you make the socket permissions. Anyone who can attach gets a full shell as the session owner, so a world-writable (chmod 777) socket is a local privilege-escalation risk. Restrict access with a dedicated group and chmod 770, place the socket in a protected directory, only invite people you trust with that account, and attach watchers read-only with -r.

How do I make a tmux client read-only for a viewer?

Attach with the -r flag: tmux attach -r -t shared (or tmux -S /tmp/pair attach -r -t pair for a shared socket). A read-only client renders the session live but cannot send keystrokes, which is ideal for demos or for someone who only needs to observe an incident.

How do I detach from a shared tmux session without closing it?

Press the prefix key, then d — with the default prefix that is Ctrl-b then d. Detaching leaves the session and any running commands alive for the other attached clients and for you to reconnect later. To shut the whole session down, use tmux kill-session -t <name> (add -S /tmp/pair for a shared-socket session).

tmux or tmate for sharing a terminal — which should I use?

Use the native tmux shared socket when both people already have accounts on the same server and you want everything to stay local with no third-party relay. Use tmate for ad-hoc remote help when the other person has no account on your box: running tmate prints SSH and web links (including read-only ones) that work without opening firewall ports, and the access disappears when you end the session.

Share this article