How to connect to a server without a public IP over a reverse SSH tunnel

You have a machine with no public IP — a home PC, an office server, or a rented rig behind NAT. You can't reach it from outside: the ISP gave you no external address, and router port-forwarding is fiddly and risky. On mobile plans and many home plans forwarding is impossible outright: the address sits behind CGNAT, and the thing facing the internet is the provider's gateway. Remote Access solves this with one command: you reach your own server over SSH through the vast.sale hub — from anywhere, phone included.

This is how we service our clients' servers on Vast.ai. The failures described below we first caught on our own fleet — six machines, from a single RTX 5090 to a box with four RTX 4090s on an EPYC 7C13. Below: how it works, what it costs in latency, what it covers and what it can never cover. Income for these machines is public on our fleet page.

How it works

The key idea: the connection is always outbound. Your machine itself opens a secure channel to the hub (a relay node) and keeps it alive. Nothing on your side listens to the internet: no public IP, no port forwarding, not a single exposed port. When you need in, you reach your server through the hub as if it were right next to you.

In detail, one service appears on the machine: an SSH connection to the hub with a remote port forward — "listen on this port and hand whatever arrives there to my local port 22." autossh keeps it up, systemd brings it back after a reboot. This is the stock OpenSSH already on the server, with no closed protocols and no cloud agents.

• You run one command on the server — it brings up an encrypted outbound tunnel.
• The machine initiates the channel, so it works behind NAT, CGNAT, routers and firewalls.
• On the hub the forwarded port is bound to 127.0.0.1 only — it is not visible from outside the hub (GatewayPorts no).
• The channel key is stripped to restrict and port-forwarding with one port; the hub account has no shell.
• Every server gets its own key pair: close access to one machine and the rest are untouched.
• You connect through the hub — over SSH from your computer, or right in the browser.

How this differs from the alternatives

The only difference between rows four and five is who administers the middle. The mechanics are identical: if you have a VPS and the appetite to keep a shell-less account, a stripped key and liveness monitoring on it, build your own hub — we covered that scheme in the paid guide on backup tunnels. Our hub is for people who do not need another server.

Why it's safe

• Nothing is exposed — only an outbound channel: the server never lands in scanner lists.
• Isolation: each client has its own channel and loopback port on the hub, and reaches only its own servers.
• Encrypted throughout — traffic runs over SSH and the hub does not decrypt it. One caveat: in the browser terminal the SSH session is opened by the vast.sale server, which sees what you see on screen; for end-to-end protection connect with your own SSH client using the connection kit.
• Per-connection keys, scoped: the channel key can do nothing but forward one port.
• You stay in control: one command fully removes the tunnel and the service account.
• The channel status is visible in your account; nothing happens without the install command you run.

One thing we don't hide: the service account has passwordless sudo rights. Without them you cannot update a driver, restart the exchange agent or collect diagnostics — the very things remote access exists for. So what matters is not promises but two verifiable facts: every server has its own key, and removal is a one-step action on your side.

Latency and traffic: what it costs

The practical takeaway: terminal comfort is bound by latency, not bandwidth, and a few tens of milliseconds are imperceptible while typing — ours is 12 ms to the hub. You do feel it in file managers that repaint the screen and in long log output — the cure is writing tail -n 200 instead of tail -f. An idle tunnel sends nothing but keepalives. We can measure your line before you install anything during a free consultation, and estimate what a machine would earn in the income calculator.

The browser terminal

The "Terminal" button in your remote access panel opens a real SSH session in the browser: xterm.js, a WebSocket connection, the same reverse tunnel behind it. No client to install, no keys to carry, and it works from a phone. We wired the clipboard bindings by hand, PuTTY style:

• Copy: select with the mouse — the text is in the clipboard at once; or Ctrl+Insert, or Ctrl+Shift+C.
• Paste: right click, or Shift+Insert, or Ctrl+Shift+V.
• Ctrl+C is deliberately left as SIGINT, not copy.
• In Firefox right-click paste fails: the browser won't let a page read the clipboard, use the native Ctrl+V.
• Copying works in every browser, but only over HTTPS.

What remote access fixes — and what it doesn't

The first four rows are exactly what the scheme exists for: they hit at random moments, take minutes to fix, and cost money only for as long as you don't know about them. A case from the log: our machine with two RTX 5080s sat without VM mode for ten days — from 19:22 on 11 September to 17:04 on the 21st — the exchange cron kept wiping the flag, and the only way to notice was to log in. The write-up with a watchdog is in the stuck controller article, the commands in our Linux cheat sheet.

The last two rows are the hard limit of any remote access. We hunted a dead memory module on the four-RTX-4090 box for weeks: memtest passed clean, the kernel was silent, the machine died under load; we proved it by moving modules between slots and swapping in a spare — by hand, on site. So we split the work plainly: setup, diagnostics and most failures happen remotely, physical work needs you or a site visit.

Where we got it wrong

The scheme looks simple, but we reached this version through four mistakes, each one paid for in downtime. The first: routing the management channel through the same tunnel as the working traffic. On 20 September one rig started its tunnel before it got a DHCP address: the packet to the VPS went into an interface that wasn't ready, and the client began opening sockets in waves — some 28 thousand, practically the whole outbound port range. The home router's connection table filled up, every rig behind it started dropping, and four decided the VPS was dead and failed over, though not one was broken. The lesson is blunt: the access you use to fix the tunnel must not run through that tunnel.

The second: a check that checked itself. The failover script "pinged" the non-current VPS and got a reply in 1–8 milliseconds, so it always considered it alive: what answered was the local tunnel interface, which accepts the packet and forwards it nowhere. Failovers were happening blind. In the 20 September version the check became real and returns an honest 36–46 milliseconds, and the threshold went from three consecutive failures to nine — with three, ordinary noise on a home line was enough. Since 7 October we have switched automatic failover off entirely: the standby VPS is gone and a person makes the switch.

The third: a hub at a cheap hoster. Download speed is throttled not per address but per hoster's autonomous system as a whole: for us OVH and M247 were throttled to unusability while Private Layer was clean, with a byte-identical config. A day went into permuting parameters before we compared two hosters using the same settings file. In a terminal you see it instantly: on a throttled AS the text arrives in jerks. And the list changes: on 6 October TCP traffic from VEESP, where our hub lives, started being throttled too, while OVH was working again by then. Pick a hub by measuring from your own line, not by price, and re-measure; on links, see our separate write-up.

The fourth: we shipped the browser terminal without once trying to copy text out of it. The complaint came from a client: "I can paste into the console, but I can't copy out." The template had not a single line about the clipboard: xterm.js handles paste itself but does not wire up copying out of the box — the selection is visible, it just never reaches the clipboard. The lesson isn't about xterm.js: acceptance testing that stops at "the connection came up and bash printed a prompt" proves nothing, you test the whole scenario.

How to start

The procedure is simple and takes a couple of minutes. Requirements: Ubuntu or Debian with systemd and sudo rights, since the installer uses apt. If the machine has no SSH server, it installs and enables one — the tunnel needs somewhere to lead; behind NAT it stays invisible from outside, and with a public IP close port 22 in your firewall. we test Ubuntu 22.04 Server first, because it is all we install on rigs ourselves. No server yet — start with the free install guide.

• Sign up or log in — by e-mail or via Telegram.
• Open the “Remote access” section.
• Take a trial server for free or get a subscription.
• Copy the install command and run it on your server (Linux, with sudo) — nothing else to configure.
• Wait for the “online” status — usually a few seconds.
• Connect: the “Terminal” button right in the browser, or the “Connection kit” for SSH from your computer.

# одна команда установки на вашем сервере (точную ссылку берите в кабинете)
curl -fsSL https://vast.sale/remote/dl/ВАША-ССЫЛКА -o podkl.sh && sudo bash podkl.sh

The script is idempotent: a repeat run breaks nothing and spawns no second service. The result is visible on the machine itself, without your account:

# служба туннеля: точное имя печатает установщик
systemctl list-units 'vast*' --no-pager
journalctl -u vast-tunnel -n 20 --no-pager

# исходящее соединение до хаба (наружу ничего не слушаем)
ss -tnp | grep -i ssh
ss -ltn            # новых внешних слушателей здесь появиться не должно

Managing and detaching

• Status, renewal and payment — in your account, the “Servers” tab.
• Auto-renewal from balance — optional and with explicit consent.
• Detach any time: one command fully removes the tunnel and the service account from your machine; the autossh and OpenSSH packages stay as ordinary system packages.
• Gave a contractor access and the work is done — revocation is surgical: one server's key is closed.

# полностью удалить служебный доступ с вашего сервера
sudo vast-service-remove

In short

• No public IP and no port forwarding: the connection is always outbound, behind CGNAT it works as behind ordinary NAT, and nothing is exposed
• Latency decides how a terminal feels: 12 ms from our line to the hub
• The scheme covers everything a command can fix: a stuck controller, a wiped VM flag, a hung agent, a wrong route
• It does not cover physics: a dead memory module and a stuck card took hands on site
• The management channel must not depend on the tunnel you configure through it — we paid with a false failover of 4 machines