Mosh Mapped
You set up a mosh mapped session by matching UDP ports across your network. First, log in over SSH to start the remote server process and trade keys. Most teams open a wide range of UDP ports on their firewall for this. That setup keeps remote shells alive when laptops sleep or switch Wi-Fi networks. Still, broad host roles and open port ranges create big risks for your team. Once a user logs in, they can run any command that their host role allows. How a mosh mapped workflow operates A mosh
Mapped: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a mosh mapped session by matching UDP ports across your network. First, log in over SSH to start the remote server process and trade keys. Most teams open a wide range of UDP ports on their firewall for this. That setup keeps remote shells alive when laptops sleep or switch Wi-Fi networks. Still, broad host roles and open port ranges create big risks for your team. Once a user logs in, they can run any command that their host role allows.
How a mosh mapped workflow operates
A mosh mapped workflow uses two distinct steps to start a terminal session. First, the client connects to the remote host over a standard SSH channel. The user logs in with an SSH key or password to check their identity. Once inside, the client starts a helper process on the remote server. This helper picks a free UDP port and makes a new shared secret key. It sends the port number and the key back through the SSH channel.
Next, the initial SSH connection closes and the UDP session takes over. The client and server sync terminal screen states over UDP using that secret key. Instead of sending raw data streams, they send only the latest screen changes. If a user changes networks, the client sends a packet from the new IP. The server checks the key, updates the client address, and keeps the session running. You must map each UDP port on your firewall to support every single user.
What native setup solves and what it leaves open
This native architecture solves a real pain point for engineers on unstable networks. Roaming users do not lose their terminal state when a train enters a tunnel. Local typing feels fast because the client shows keystrokes right away on the screen. The initial SSH step also makes sure only users with valid keys log in.
Yet this native setup leaves a major operational gap open during the active session. The login check only decides who can enter the host at the very start. Once the UDP session runs, the network only sees encrypted state changes flowing back. Security teams cannot read the commands a user runs inside that terminal screen. They also cannot stop a risky command before it deletes a production file. If a command prints database rows with emails or card numbers, raw text shows up. You need a way to check individual commands and rewrite sensitive fields in flight.
Mapped: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing firewall rules and host roles
Running this tool across many servers adds daily work for network teams. Each active terminal needs its own dedicated UDP port on the target machine. If twenty engineers log in at once, you must open twenty UDP ports. When hosts sit behind a shared network address, port mapping gets very messy. You have to route specific outer ports to exact inner hosts by hand.
Host permissions also tend to grow too broad over time on Linux servers. Teams often share a single admin role so everyone can fix broken apps fast. When every user shares one role, system logs cannot tell who ran which command. Tying every single action back to one specific person becomes almost impossible. Teams need fine-grained command control and clear audit logs without opening big firewall holes.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Why does a mosh mapped setup need both TCP and UDP ports?
It uses TCP first so SSH can check the user and start the server process. After trading the secret key, it switches to UDP to sync screen states fast.
What happens when a firewall blocks the mapped UDP port range?
The initial SSH login finishes, but the terminal hangs when starting the UDP session. You must open the exact UDP port on the host firewall to fix this.
Can native firewall logs show which commands a user ran in the session?
No, firewall logs only show encrypted UDP packets moving between two IP addresses. The firewall cannot read the screen state or log the specific shell commands inside.