# SSH to a Pi without port forwarding

You do not need to open a port on the router to SSH to a Raspberry Pi from
outside. Run an agent on the Pi that connects out to a relay, and SSH to the
relay instead. There is no router login, no forwarding rule, no dynamic DNS,
and nothing on your network listens to the internet. This works from a
dorm, an office, a rented flat with the ISP's locked router, or your own
home if you would simply rather not expose sshd.

## Why not just forward port 22?

Forwarding works when you control the router and have a public IP. Even then
it has costs that show up later:

- **Your Pi is on the internet.** A forwarded port 22 sees thousands of password guesses a day within hours of opening. You then need key-only login, fail2ban, and a habit of reading the auth log.
- **Your address changes.** Most home connections have a dynamic IP, so you add dynamic DNS and a client to keep it updated — one more thing that silently breaks.
- **The router is not always yours.** Shared housing, campus networks, offices, and many ISP-supplied routers give you no forwarding rules at all.
- **It might not work anyway.** If your ISP uses carrier-grade NAT, a forwarded port does nothing. [How to check](https://relayssh.com/docs/ssh-behind-cgnat/).

## Connect out instead of in

An outbound connection needs no permission from the router. The agent on
your Pi opens one SSH connection to the relay and keeps it open, with a
reverse tunnel inside it. The relay assigns the tunnel a public port. When
you SSH to that port, the relay hands the connection down the tunnel to the
Pi's own SSH server. From the router's point of view, the Pi is browsing the
web.

This is plain reverse SSH, and you can run it yourself on any server with a
public IP —
[RelaySSH vs reverse SSH on your own VPS](https://relayssh.com/docs/relayssh-vs-reverse-ssh/)
shows both setups. Developer tunnels like ngrok can carry SSH too, at a
price shaped for web apps rather than devices; see
[RelaySSH vs ngrok](https://relayssh.com/docs/relayssh-vs-ngrok/).

Your login stays on the Pi. The relay forwards an encrypted SSH session it
cannot read, and the Pi checks your key or password exactly as it would on
your LAN — we never hold your logins.

## Install the agent

Copy the install command from **Add device** in the dashboard
and run it on the Pi. It installs the agent as a systemd service that
starts on boot.

```sh
curl -fsSL https://relayssh.com/install/YOUR-INSTALL-KEY/ | sudo sh
```

## Add a tunnel to port 22

On the Pi's page in the dashboard, add a tunnel to port 22. The relay
assigns a port between 20000 and 29999. That port is yours for as long as
the tunnel exists — it does not change when your home IP does.

## SSH in

```sh
ssh -p 20001 pi@relayssh.com
```

> **Tip:** Put the host and port in ~/.ssh/config once, and scp, sftp, rsync, and your editor's remote mode all pick it up.

## What you gave up, and what you did not

You gave up nothing on the SSH side. It is the same sshd on the Pi, the same
keys, and any SSH client. What changed is who can reach the Pi at all: only
connections that arrive through the relay's assigned port. Your router still
has no open ports, so a port scan of your home IP finds nothing.

The relay's port is public, so the Pi's sshd still faces login attempts on
it. Keep key-only authentication on — that advice does not change. What you
cannot do with a tunnel is reach the whole LAN through it; a tunnel forwards
one port to one target. If a second device next to the Pi needs reaching,
[the Pi can pass a tunnel
on to it](https://relayssh.com/docs/reach-lan-devices/), or you can forward through the SSH session with
`ssh -L`.

## Boundaries

The Pi needs outbound TCP to `relayssh.com` on ports 443 and
2002. Almost every home, campus, and office network allows this; a network
that only permits ports 80 and 443 will block the tunnel. Read
[getting started](https://relayssh.com/docs/getting-started/) for the
full install walk-through and what to expect at each step.