termal.in

← Blog

SSH em um servidor atrás de NAT ou CGNAT, sem encaminhamento de portas

· Termalin Team sshtunnelingnetworkinghomelab

Você quer fazer SSH em uma máquina que não pode aceitar conexões de entrada: um servidor doméstico atrás do seu roteador, um Raspberry Pi no escritório, uma máquina num link móvel ou 5G. A velha resposta — encaminhar a porta 22 no roteador — está cada vez menos disponível e, onde está, é uma má ideia. Este post percorre as quatro abordagens que realmente funcionam, o que cada uma custa a você e um exemplo prático de cada. Nenhuma delas abre uma porta de entrada na máquina que você quer alcançar.

Por que já não dá para simplesmente encaminhar uma porta

Duas coisas atrapalham. Primeira, o NAT em nível de operadora (CGNAT): a maioria das conexões domésticas de fibra, cabo, móvel e Starlink hoje compartilha um único IP público entre muitos clientes, então não há porta no “seu” endereço para encaminhar — o roteador que você controla não é o que detém o IP público. Segunda, mesmo com um IP público de verdade, uma porta SSH encaminhada é encontrada por scanners em minutos; os logs se enchem de tentativas de força bruta no momento em que ela entra no ar. A solução em todos os casos abaixo tem o mesmo formato: a máquina privada faz uma conexão de saída para algo alcançável, e você entra de volta por essa conexão. A saída funciona até por CGNAT e firewalls trancados, porque é só mais uma conexão deixando a rede.

As quatro opções num relance

AbordagemO que você rodaInfraestrutura extraChave de longa duração na máquina?Ideal para
Túnel SSH reversossh -R + autossh na máquinaum VPS com IP públicosim (para o VPS)você já aluga um VPS
VPN em malha (Tailscale / WireGuard)um cliente de VPN nas duas pontasum serviço de coordenaçãosua chave SSH normalalcançar várias máquinas
Cloudflare Tunnelcloudflared na máquinauma conta Cloudflare + domíniosua chave SSH normalvocê já usa a Cloudflare
Connector de saídaum pequeno agente na máquinauma conta Termalinnão — certificado de curta duraçãoacesso via navegador, sem VPS nem VPN

As três primeiras te dão um ssh you@… normal a partir do seu notebook. A última alcança a máquina por um navegador ou um agente de IA, em vez disso. Continue lendo para ver qual encaixa.

Opção 1 — Túnel SSH reverso por um VPS

Se você já aluga um VPS barato com IP público, a máquina privada pode discar para ele e encaminhar a própria porta SSH de volta. Na máquina atrás de NAT:

ssh -N -R 2222:localhost:22 tunnel@vps.example.com

Isso abre a porta 2222 no VPS e encaminha toda conexão a ela de volta à porta 22 da máquina de casa. De qualquer lugar, salte pelo VPS para cair na máquina:

ssh -J tunnel@vps.example.com -p 2222 you@localhost

Um ssh -R cru morre na primeira vez que a rede engasga, então envolva-o em autossh sob uma unidade do systemd para mantê-lo vivo entre reinicializações e quedas, e acrescente -o ServerAliveInterval=30 -o ExitOnForwardFailure=yes. Toda a mecânica — incluindo a pegadinha do GatewayPorts e por que o túnel se vincula ao loopback do VPS por padrão — está em túneis SSH reversos, explicados. O trade-off: você mantém um VPS e uma chave de longa duração na máquina que consegue alcançá-lo, e esse VPS agora faz parte da sua superfície de ataque.

Opção 2 — Uma VPN em malha (Tailscale ou WireGuard)

Em vez de expor uma porta, coloque as duas máquinas em uma rede privada que só elas enxergam. O Tailscale é a versão de baixo esforço. Na máquina atrás de NAT:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Instale o Tailscale também no seu notebook, e os dois ganham um endereço 100.x.y.z estável (e um nome MagicDNS). Depois é só:

ssh you@home-box

como se vocês estivessem na mesma LAN — a máquina nunca fica exposta à internet pública. O sudo tailscale up --ssh pode até cuidar da autenticação SSH por você, então você não gerencia chaves para isso. O WireGuard é a mesma ideia feita à mão: você mesmo roda a coordenação e configura os peers manualmente — mais trabalho, sem coordenador de terceiros. Para um home lab com um NAS e uns Raspberry Pis, uma VPN em malha costuma ser a resposta inteira, e é o padrão a que eu recorro no guia de NAS/servidor doméstico. O trade-off: todo dispositivo que precisa de acesso tem que entrar na rede, o que significa um cliente para instalar e uma conta para manter.

Opção 3 — Cloudflare Tunnel

Se o seu domínio já está na Cloudflare, o cloudflared te dá um túnel de saída sem porta aberta. Na máquina:

cloudflared tunnel login
cloudflared tunnel create home

Roteie um hostname para o túnel e aponte-o para o sshd local (ssh://localhost:22) na configuração do túnel, depois rode o cloudflared como serviço. Do lado do cliente, o SSH o alcança por um ProxyCommand no seu ~/.ssh/config (em inglês):

Host ssh.example.com
    ProxyCommand cloudflared access ssh --hostname %h

Agora ssh you@ssh.example.com flui pela edge da Cloudflare até a máquina. O plano gratuito cobre isso. O trade-off: você roteia o seu SSH por um terceiro e passa a depender de uma conta Cloudflare e de um domínio hospedado lá — ótimo se você já faz isso, exagero se não.

Opção 4 — Um connector de saída (sem VPS, sem VPN)

Cada uma das três opções acima pede infraestrutura permanente — um VPS, uma VPN ou um domínio na Cloudflare. O Connector do Termalin reduz isso a um comando e alcança a máquina pelo seu navegador, pelo app do Termalin ou por um agente de IA, em vez de um ssh local. No servidor privado, uma linha instala um pequeno agente estático (Linux x86_64 e arm64):

curl -fsSL https://termal.in/tunnel-install.sh | sudo TERMALIN_TOKEN=<token> sh

O agente disca para fora, até o Termalin, por um único WebSocket e o mantém aberto; ele nunca escuta em uma porta. Quando você abre um terminal no cliente web, a requisição desce por esse link e o agente conecta ao próprio sshd da máquina em localhost — ele só movimenta bytes SSH opacos, então nunca vê as suas credenciais nem o texto em claro da sessão. O cadastro faz o sshd da máquina confiar na autoridade certificadora SSH do Termalin, então os logins usam um certificado de curta duração em vez de uma chave privada de longa duração parada no servidor. Essa é a única linha da tabela com “não” na coluna chave de longa duração na máquina.

A ressalva, dita sem rodeios: você alcança a máquina pelo lado hospedado do Termalin — o terminal web, os apps de desktop e de iOS do Termalin (que conectam pelo mesmo gateway) ou um agente de IA pelo servidor MCP — e não com um comando ssh cru a partir da sua própria máquina, e o Connector faz parte do plano pago (ou do teste). Se o que você quer é um terminal normal a partir do seu notebook, as opções 1–3 encaixam melhor. Se o que você quer é acesso via navegador a partir de qualquer dispositivo — ou deixar um agente trabalhar em uma máquina que não tem endereço público nem chave para roubar — esta é a opção feita para isso. O mesmo Connector de saída também leva monitoramento e alertas leves para uma máquina sem porta aberta.

Qual você deve escolher?

  • Você já aluga um VPS: o túnel reverso o reaproveita — um ssh -R sob o autossh e pronto.
  • Você tem mais de uma máquina para alcançar, ou quer que elas pareçam uma LAN: uma VPN em malha como o Tailscale escala melhor e não expõe nada.
  • Seu domínio mora na Cloudflare: o túnel deles encaixa naturalmente, sem um fornecedor novo.
  • Você quer zero infraestrutura permanente, acesso via navegador ou acesso supervisionado de agente: um connector de saída, sem nenhuma chave de longa duração deixada no servidor.

As quatro compartilham o único princípio que vale lembrar: nunca abra uma porta de entrada em uma máquina que você não pode se dar ao luxo de ver escaneada. Deixe que ela alcance para fora — essa única inversão de direção é o que torna o SSH atrás de NAT seguro.


O Termalin é um cliente SSH gratuito e multiplataforma, com túneis salvos, um terminal web e um Connector sem chaves para servidores privados — baixe o Termalin, ou veja como ele cuida das suas chaves com segurança.

Experimente em um host.

Termalin é um cliente SSH rápido para você — e para seus agentes.

Plano gratuito · 14 dias de Pro grátis · preços