SSH is a tunnel to a machine you own
SSH is an encrypted channel between your device and another computer. You send keystrokes, that machine runs the commands, its output comes back, and no hop in between can read any of it. To run a coding agent remotely, SSH is how your phone reaches the machine the agent runs on.
The last article argued that an agent does its best work in a terminal, with full access to a filesystem and permission to execute. That terminal does not have to be in your pocket. It can be the Mac mini at home that never gets switched off, or the workstation at the office, as long as your phone can route to it.
Why another machine instead of a cloud service?
Browser agents and cloud IDEs connect you to a machine too. The difference is whose machine it is.
SSH connects you to your own. Your files and API keys are already there, along with every package you installed and every environment variable you set. Nothing has to move onto someone else's server, and the changes stay where you made them, so there is nothing to sync back afterwards.
The trade-off runs the other way too. A cloud environment is the better answer if you own no machine that stays on, or if a whole team needs one identical starting point. Your machine has to be awake, reachable, and set up by you.
What you actually type: host, user, port
Every SSH connection needs three things, and the command writes them on one line:
ssh -p 22 sax@mac-mini| Part | What it names |
|---|---|
| Host | Which machine: a name such as mac-mini, or an address such as 100.101.102.103 |
| User | Which account on it. You get its files, permissions, and shell, and nothing above that account |
| Port | Which door. SSH's default is 22, so the field usually goes empty |
Two of those three are where beginners get stuck. The host has to be an address your phone can route to; the next section covers which ones. And the user has to exist on that machine: an agent runs as that user, and it can touch exactly what that user can.
Why not your LAN address or your public IP?
The first address you find is in your network settings: something like 192.168.1.23. Try it from a laptop on the same Wi-Fi; that is what it is for. It is a private address handed out by your router, valid only inside your own network. A phone on mobile data has no route to it.
The second is the public address your home connection shows the internet, with a port forwarded through the router to that one machine. That road works, and it is the one to avoid. Scanning bots try logins against every address in the world, around the clock, and an exposed port starts collecting attempts within a day. One mistake in the router settings opens the whole network instead of one machine.
Use a third kind: a private address only your own devices can see. Tailscale gives each machine a MagicDNS name or a 100.x address, and nothing else on the internet knows those exist. That goes in the host field, at home and away.
Keys are safer and need less typing
SSH takes passwords or keys, and the choice gets framed as security versus convenience. Keys are better at both.
A key pair is two small text files. The private one stays on the device that connects. The public one is computed from it and copied onto the machine you want to reach, into authorized_keys inside that account's ~/.ssh directory. The arithmetic runs one way. The public half comes from the private half, and you cannot recover the private half from the public one. ssh-keygen makes a pair in seconds.
At login the two halves prove the match and you type nothing. A password has to survive repeated guessing, and a key is long enough that guessing never pays. Set it up once and every connection afterwards works the same way.
Put a passphrase on the private key, because a key is a file. Copy it off an unlocked laptop and someone else holds your key. The passphrase makes that copy worthless by itself, and unlike a login password it never crosses the network: it unlocks the key on the device, and what travels is a signed answer to a challenge.
On a phone the difference matters more. A typed password goes over the wire on every connection, handing anyone who can reach the port a fresh guess. A key answers a challenge instead, and the private half never leaves the device. If the key is in place and still refused, the usual causes are few: wrong path, wrong user, wrong permissions.
Where does the app keep my key?
Agentmux collects no personal data. Usage statistics are anonymous and optional; turning them off changes nothing about how it connects. Passwords, keys, and passphrases go into the operating system's hardware-backed credential storage. Your SSH traffic is never logged: the channel is encrypted between your device and your machine, and the app is not a relay.
Why the fingerprint prompt appears the first time
The first time you reach a machine, before any password or key, the client prints a line about the host's authenticity, a short string of hex, and a yes or no. That string is the server's fingerprint: a readable summary of the host key the machine signs with. Nothing has gone wrong. SSH is authenticating the other direction.
A password or key proves you to the machine. A host key proves the machine to you. Without that second half, anyone between your phone and your Mac mini could answer in its place and read what you send. On a first connection there is no stored copy to compare against, so the client asks you to accept it and remembers it from then on.
It earns its keep later. Reconnect to a machine whose fingerprint has changed and the client refuses. Either you reinstalled the system, or something else is answering.
Do you have to turn your computer into a server?
People hear "SSH" and picture racks in a data centre. You are flipping a switch. On a Mac it is System Settings → General → Sharing → Remote Login. On Linux it is usually starting a service called sshd, which most distributions already ship.
Nothing else about the machine changes. It is still your everyday computer, with one more door you can knock on from outside. If you would rather not remember the order of operations, the setup page asks three questions and hands back a checklist.
SSH is not a VPN or a remote desktop
Three things SSH does not do:
| Not this | What that would mean | What SSH does instead |
|---|---|---|
| A VPN | Everything your phone sends routed into your home network | One channel to one port on one machine. Nothing else becomes reachable |
| A mounted filesystem | Your remote disk appears as a folder | Bytes on request. A file browser fetches and pushes each file itself |
| Screen sharing | Pictures of a desktop, steered with a finger | Text both ways: keystrokes out, printed output back |
That last row is a real limit, not a flaw in this tool. Software that exists only as a window you click cannot be driven over SSH, which is the same boundary the previous article drew: an agent that speaks text is an agent that fits down the tunnel.
Then you put your phone away, the tunnel drops, and the agent dies with it. Unless the session was never living inside your connection: that is what tmux is for.