You can reach an SSH server without opening a port on your router. The key is that the connection starts from inside the protected network and stays outbound.

That distinction matters when a server sits behind a home router, office firewall, mobile hotspot, Starlink connection, or carrier-grade NAT. In each case, an inbound connection from the public internet may be blocked, unreliable, or impossible to configure. An outbound HTTPS or relay connection usually has a much better chance of leaving the network.

This does not remove the need to secure SSH. It changes where the public-facing connection lives and how traffic finds its way back to the server.

Why normal inbound SSH needs port forwarding

In a traditional setup, your SSH client connects to a public IP address on TCP port 22. Your router receives that traffic and needs a rule telling it which device on the local network should receive it. That rule is port forwarding.

For example, a router may map its public port 22 to 192.168.1.50:22, where 192.168.1.50 is a Linux server. The router has to keep that mapping in place because it cannot otherwise know whether an unsolicited connection should go to the NAS, a Raspberry Pi, a Proxmox host, or some other device.

There are practical problems with this approach:

• Your public IP may change.
• Your ISP may place you behind CGNAT, so you have no usable public IPv4 address.
• A work, apartment, hotel, or mobile network may give you no router settings at all.
• Port 22 becomes visible to internet scanners and password-guessing attempts.
• Router rules become one more piece of infrastructure to document and maintain.

Changing SSH to a different external port reduces noise in logs, but it does not change the basic exposure. A port scan can still find the service.

What replaces the forwarded port

A no-port-forwarding design has a component inside your network that dials out to a service or relay. Because the local device initiated that connection, NAT state in the router allows return traffic to use the same path.

When you later request an SSH session, the relay associates your request with that existing outbound connection and carries SSH traffic through it. The server itself still runs SSH locally. There is simply no direct inbound route from the internet to the router.

Picture a small server at home:

1. A connector on the home network opens an outbound connection to a relay.
2. The connection remains available while the connector is online.
3. You authenticate to the remote access system from another network.
4. The relay sends the session through the already-established outbound connection.
5. The connector forwards it only to an allowed local SSH host and port.

The router sees outbound traffic and replies associated with it. It never needs an inbound port-forwarding rule.

This pattern is useful for SSH behind CGNAT, where configuring the home router would not solve the problem anyway. The ISP's carrier NAT is upstream from your own equipment.

Common ways to do it

Several tools use this general pattern. They differ in where credentials live, who runs the relay, how target access is limited, and how much administration they require.

Reverse SSH tunnels

A reverse SSH tunnel starts from the protected machine and connects to a host with a public address. It can expose a port on that public host which forwards back to the internal server.

A typical command might use ssh -R from the home server to a VPS. You then SSH to the VPS port, and the VPS carries the traffic down the tunnel.

This is a familiar option for Linux administrators who already operate a VPS. It also creates operational work. You must secure the public relay host, keep the tunnel alive, decide which interfaces can bind the remote forwarded port, manage keys, and handle reconnects after network changes or reboots. Tools such as autossh can help maintain a tunnel, but they do not make the design self-maintaining.

Be particularly careful with remote bind addresses. A reverse-forwarded port that listens on every interface of a VPS can become publicly reachable. Confirm the exact SSH daemon settings and test from an external network.

Mesh and overlay networks

Some remote-access tools create a private network between enrolled devices. Your laptop and server receive addresses on that network and can often communicate directly, with relays used when direct peer-to-peer traffic cannot work.

This can be a good fit when you control all client devices and want access to more than SSH. It is a different model from publishing one approved SSH route. You need to manage device enrollment, identity, access policies, software updates, and the fact that the connected devices can potentially reach each other according to those policies.

A mesh network is useful for a fleet. It may be more access than you need for one Raspberry Pi.

Purpose-built outbound SSH bridges

A bridge can be dedicated to reaching a limited set of SSH targets. It dials outward, then carries a browser SSH session or other approved session back to a specified host.

SSH Guru uses an ESP32-S3 bridge for this model. The board is flashed from Chrome or Edge over USB, then connects outbound from the local network. Its allow-list rules are written to the board and can only be changed over USB. That physical step matters: someone with an account cannot quietly expand a bridge from one approved server to every address on the LAN.

The bridge is designed for SSH access to permitted targets. It is not a VPN or a general route into the local network. For a home lab with a changing IP address, an ISP router, or 5G home internet, that narrower boundary is often easier to reason about. See the details of SSH without port forwarding if this is the access pattern you need.

NAT is not an authentication system

Removing the router rule reduces public exposure, but the outbound connection itself becomes important infrastructure. Treat it accordingly.

Start with SSH authentication. Use a private key where possible, protect that key with a passphrase, and disable password login on the target server if your recovery plan permits it. Keep a local console path available for the day a key, tunnel, or remote-access account fails.

Verify host identity too. The first time a client connects, it records the server's SSH host key. On later connections, a changed host key deserves attention. It may mean a server was rebuilt, but it can also indicate that traffic is reaching the wrong system. SSH Guru pins host keys in the browser and warns when one changes.

Limit the bridge or connector to the targets it actually needs. An allow-list containing one hostname or local IP and port is easier to audit than a broad subnet rule. If you run separate services, consider whether each needs remote SSH at all.

Use separate credentials for separate people. Shared private keys make it hard to revoke one person's access and nearly impossible to know who used a session. On the server, individual Unix accounts and authorized_keys entries give you a cleaner record.

Check failure behavior before you rely on it

Remote access is most valuable when something is already wrong. That is also when hidden assumptions surface.

Test these cases deliberately:

• Reboot the bridge, connector, and target server.
• Restart the router or switch the internet connection from primary to backup.
• Change the local DHCP address of the SSH target, then confirm whether the connection still reaches the right machine.
• Disconnect the outbound path and verify that remote access stops rather than falling back to an unexpected route.
• Attempt access to a non-allow-listed local address.
• Connect from a Chromebook, iPad, or locked-down laptop if those are devices you expect to use.

A remote path that only works from your desktop on the same Wi-Fi is not a remote recovery path.

You should also know what happens during an internet outage. No port-forwarding approach can carry a remote session when the protected site has no outbound connectivity. For critical systems, out-of-band management, a second WAN path, or a local person with console access may still be necessary.

Browser access changes the client side

The server-side route is only half the problem. Sometimes the device you are holding cannot install an SSH application, import a private key easily, or reach your usual network.

A browser SSH client can address that client-side constraint. With SSH Guru, the SSH client runs locally in the browser as Go compiled to WebAssembly. Private keys and passwords are encrypted in the browser using Argon2id and AES-256-GCM under the user's passphrase. The service states that it does not hold private keys, passwords, or SSH sessions.

That model is useful for SSH from a Chromebook or iPad, provided you still verify the host key and use the same account discipline you would in a desktop client. Browser convenience should not turn into copied private keys on shared machines or permanent login sessions on devices you do not control.

No port forwarding is a routing decision, not a shortcut around security work. A controlled outbound connection, a narrow target allow-list, verified SSH host keys, and tested recovery steps make the approach practical for servers that cannot accept inbound connections in the first place.