WebRTC vs SSH for Remote Terminal Access

SSH is the default answer for remote terminal access, and it's been that way for thirty years. For good reason: it's secure, well-understood, and works great for connecting to servers. But there's another option worth knowing about, especially if what you're connecting to is a personal Mac rather than a remote server.

WebRTC is the technology behind browser video calls. Its connection model turns out to be a good fit for terminal access in specific situations. This post breaks down how each protocol works, where they differ, and which one makes more sense depending on what you're trying to do.

How SSH Works

SSH (Secure Shell) creates an encrypted channel between two machines. You run an SSH client, connect to a server running sshd, authenticate with a key or password, and you get an encrypted terminal session.

It runs over TCP, which guarantees ordered packet delivery. Authentication is typically done with a public/private key pair. The connection is encrypted after an initial key exchange using symmetric ciphers like AES or ChaCha20.

SSH assumes the server has a stable, reachable address. It was designed for the datacenter model: the client initiates a connection to a known host. This works perfectly when the destination is a Linux server with a static IP. It works less well when the destination is a Mac sitting behind a home router doing NAT.

SSH has no built-in NAT traversal. If your target machine is behind a router, you need port forwarding so the router knows to direct inbound traffic on port 22 to the right machine. You also need to know or track the router's public IP, which changes unless you have a static IP from your ISP or have set up dynamic DNS.

How WebRTC Works

WebRTC (Web Real-Time Communication) was built for browser-to-browser audio and video calls. The core design challenge it solved was connecting two peers, both potentially behind NAT, without requiring either of them to configure their network.

The mechanism is called ICE (Interactive Connectivity Establishment). Here's roughly what happens:

1. Both devices gather a list of candidate addresses they might be reachable at. This includes local network IPs, public IPs (discovered via STUN servers), and relay addresses (via TURN servers).
2. Both devices exchange these candidates through a signaling server. The signaling server passes the messages but doesn't see the connection content.
3. Both sides try connecting via each candidate. The best working path wins. Usually this is a direct peer-to-peer connection. If NAT or firewalls block that, it falls back to a relay through a TURN server.

Once the connection is established, it's encrypted with DTLS-SRTP. DTLS is TLS adapted for UDP. SRTP handles data encryption. The result is a secure channel that neither the signaling server nor the network can read.

WebRTC typically runs over UDP. It was built for video, but the transport doesn't care what data flows through it. Terminal output works just as well as video frames.

Key Differences

NAT traversal

This is the biggest practical difference. SSH doesn't handle NAT on its own. If your target is behind a router, you need to configure port forwarding, set up a VPN, or use a reverse tunnel through a cloud server. All of those require setup and ongoing maintenance.

WebRTC was designed specifically for NAT traversal. STUN and TURN are baked into the protocol. The connection negotiates through NAT automatically. You don't configure anything on your router.

Setup complexity

SSH to a server is simple: enable sshd, open the port, use a key. SSH to a Mac behind NAT adds port forwarding, dynamic DNS, and key management on the client side.

A WebRTC-based tool like Macky requires a signaling server (handled by the app), but nothing on your network. Install the software, create an account, connect. No router config, no keys to manage.

Transport protocol

SSH runs over TCP. TCP guarantees ordered, reliable delivery. If a packet is lost, everything waits for the retransmit. For terminal traffic this is usually invisible. Packet loss on a stable connection is rare.

WebRTC uses UDP by default. UDP doesn't wait for retransmits. A dropped packet is dropped. For video, that's fine because a missed frame is better than freezing. For terminal use, it's less critical, but on a lossy connection UDP can actually feel more responsive because nothing is waiting.

Encryption

Both are considered secure. SSH uses symmetric encryption after an initial key exchange, and has decades of real-world deployment behind it. WebRTC uses DTLS for the handshake and SRTP for data, the same stack used by every major video conferencing platform.

Neither has known practical weaknesses when configured correctly. For terminal access, you're not giving up security by choosing either one.

Handling network changes

SSH connections drop when your network changes. Switch from WiFi to cellular and the TCP connection breaks. You reconnect and start over. Mosh (Mobile Shell) addresses this with UDP and reconnection logic, but it's a separate tool on top of SSH.

WebRTC can renegotiate when network conditions change. The ICE agent switches to a new path if the current one stops working. This makes it more tolerant of the kind of transitions that happen on a mobile device.

When SSH Is the Better Choice

SSH is the right tool when your destination has a known, stable address. Cloud VMs, Linux servers, Raspberry Pis with static local IPs, anything in a datacenter or a network you control. SSH has decades of tooling: config files, key agents, ProxyJump, multiplexing, scripted automation. If you're doing serious server work, SSH is what you want.

• Connecting to AWS, GCP, DigitalOcean, or any cloud provider VM
• Automating deployments via scripted SSH commands
• Linux servers where you control the network and port 22 is reachable
• Anything that uses SSH as infrastructure (git over SSH, rsync, scp)

When WebRTC Is the Better Choice

WebRTC wins when the destination is behind NAT you don't control, when you don't want to manage port forwarding and key files, and when you need a connection that works regardless of what network you're on.

The specific case where this matters most is connecting to a personal Mac from an iPhone. Your Mac is behind your home router. Your phone might be on cellular, on a corporate network that blocks SSH, or on a public WiFi. A WebRTC-based tool handles all of those conditions without any router configuration.

• Mac-to-iPhone access from any network
• Networks where port 22 is blocked outbound
• Zero-config situations where you don't want to manage network settings
• Connections that need to survive switching between WiFi and cellular

Macky uses WebRTC for the Mac-to-iPhone case specifically. The signaling server coordinates the handshake and then gets out of the way. Terminal data travels encrypted, peer-to-peer when possible, through a relay only when it has to.

They Work Together

One pattern worth knowing: use WebRTC to reach your Mac, then SSH from your Mac to whatever servers you need. Your Mac already has SSH configured for your infrastructure. Those keys and configs work normally once you're connected via Macky.

Run that through Macky on your iPhone and it uses your Mac's SSH identity. You get the NAT traversal convenience of WebRTC for the Mac connection, and the full SSH toolchain for everything downstream. The two approaches aren't competing. They're covering different parts of the same workflow.

The Short Version

Use SSH for servers. It's the standard, it has the best tooling, and it works great when you have a stable address to connect to.

Use WebRTC-based tools when the destination is behind NAT and you don't want to deal with network configuration. For connecting to your own Mac from an iPhone, that's where WebRTC pulls ahead. Both are secure. The choice mostly comes down to what you're connecting to and how much setup you're willing to do.