Question
PuTTY and X11 Server: Xauth Cookie Handling Across Concurrent Sessions
Ash Atlas
0 reputation · 14 Feb 2025, 21:31 UTC
31.3K views
Loading…
0 reputation · 14 Feb 2025, 21:31 UTC
PuTTY implements X11 forwarding by tunneling graphical data between a local X server and a remote X client via the SSH-2 protocol. This process requires the remote server's sshd to allocate a pseudo-terminal and set the DISPLAY environment variable based on the client's request during session negotiation.
When managing multiple concurrent SSH sessions to the same remote host, the integration must handle X11 authentication cookies to ensure the remote X client can authorize requests to the local X server. There is uncertainty regarding how PuTTY manages these cookies when several independent sessions attempt to utilize the same local X display address simultaneously.
32275 reputation · 15 Feb 2025, 06:58 UTC
PuTTY does not share a single X11 authentication context across multiple sessions. Instead, it negotiates unique authentication cookies for each individual session. When X11 forwarding is enabled, PuTTY generates a temporary cookie and transmits it to the remote server during the SSH handshake. The remote sshd then assigns a unique DISPLAY variable (typically localhost:10.0, localhost:11.0, etc.) to isolate the traffic for that specific channel.
Conflicts are avoided through the use of separate display offsets. Because each concurrent session is mapped to a different local port on the remote server, the remote X clients use different cookies associated with those specific display addresses. These cookies are typically stored in the user's ~/.Xauthority file. The xauth utility manages these entries, allowing multiple cookies to coexist for different display offsets simultaneously.
While the SSH protocol and sshd are designed to handle this isolation, the following distinctions apply:
puttyDISPLAY value on the remote host.xauth supports multiple entries in the .Xauthority file, preventing one session from overwriting another's cookie.Invalid MIT-MAGIC-COOKIE errors during concurrent sessions, it is rarely due to PuTTY's negotiation and more likely due to .Xauthority file locking issues (common on NFS mounts) or session switching (using sudo or su).To verify that your concurrent sessions are using distinct cookies, run the following commands in each separate PuTTY window:
# Check the assigned display for the current session
echo $DISPLAY
# List all active X11 cookies
xauth listYou should see a unique localhost:N entry for every active session, each paired with its own unique hex cookie.
If you are experiencing authentication failures despite unique DISPLAY values, please specify if your home directory is hosted on a network file system (NFS), as this changes the recommendation toward using a local XAUTHORITY environment variable.
Use comments to ask for clarification. Post a solution as an answer.
32,275 reputation · 15 Feb 2025, 05:44 UTC
One detail worth adding: PuTTY itself never touches an .Xauthority file. During session setup it generates a random MIT-MAGIC-COOKIE-1 value, presents it to the local X server when relaying connections, and hands it to the remote sshd, which merges it into the remote user's ~/.Xauthority keyed to the allocated display (e.g. localhost:10.0).
The practical consequence: concurrent sessions never conflict on cookie storage, because each gets its own display offset and its own remote xauth entry. The real local-side requirement is that PuTTY can authenticate to your X server at all — on Windows this is handled by the X server (VcXsrv, Xming) trusting localhost; on Linux, PuTTY must be able to read your local authority file. Failures like Authorization required, but no authorization protocol specified usually mean the local side failed, not a cookie clash between sessions.
Verify with xauth list $DISPLAY on the remote host per session and PuTTY's Event Log for "X11 forwarding enabled" lines.