Pinggy

Pinggy

Public reverse tunnels to localhost using SSH remote forwarding or the Pinggy CLI. Use for authorized dev/test ingress, webhook capture, controlled lab callbacks, and temporary remote access without router port forwarding.

Scope Guard

• Confirm the exposed service, audience, time window, and authorization before creating a public URL or port.
• Default to short-lived tunnels, strong app-layer auth, and IP allowlists for anything sensitive.
• Do not expose admin consoles, databases, model servers, MCP tools, or shells to the internet without explicit access controls and owner approval.
• Prefer tls for end-to-end encrypted HTTPS services when Pinggy must not inspect HTTP content; HTTP tunnels terminate at Pinggy to provide debugger and header features.

Choose the Mode

Quick Starts

# HTTP(S) via OpenSSH
ssh -p 443 -R0:localhost:8000 free.pinggy.io

# HTTP(S) with QR code in terminal
ssh -p 443 -R0:localhost:8000 qr@free.pinggy.io

# TCP tunnel to local SSH
ssh -p 443 -R0:localhost:22 tcp@free.pinggy.io

# TLS tunnel to local HTTPS service
ssh -p 443 -R0:localhost:8443 tls@free.pinggy.io

# CLI equivalents
pinggy -l 8000
pinggy --type tcp -l 22
pinggy --type udp -l 51820

# Docker HTTP tunnel on Linux
docker run --net=host -it pinggy/pinggy -p 443 -R0:localhost:8000 a.pinggy.io

On Windows, if localhost fails through OpenSSH, retry with 127.0.0.1.

SSH Grammar

ssh -p443 -R0:<local_host>:<local_port> [more -R rules] [<token>+<keywords>@]a.pinggy.io [remote options]

Useful SSH flags:

Username keywords are joined with +: TOKEN+tcp+force@a.pinggy.io, qr@a.pinggy.io, TOKEN+tls@pro.pinggy.io.

HTTP Controls

Append these after the SSH destination and use -t:

# Basic auth; username/password cannot contain ':'
ssh -p 443 -R0:localhost:8000 -t free.pinggy.io b:user:pass

# Multiple bearer keys: visitor sends Authorization: Bearer <key>
ssh -p 443 -R0:localhost:8000 -t free.pinggy.io k:key1 k:key2

# IP/CIDR allowlist
ssh -p 443 -R0:localhost:8000 -t free.pinggy.io w:203.0.113.10/32

# HTTPS-only redirect, CORS preflight pass-through, original URL header
ssh -p 443 -R0:localhost:8000 -t free.pinggy.io x:https x:passpreflight x:fullurl

# Local service expects HTTPS/TLS
ssh -p 443 -R0:localhost:8443 -t free.pinggy.io x:localServerTls:example.com

# Header manipulation: append, remove, update
ssh -p 443 -R0:localhost:8080 -t free.pinggy.io a:X-Lab:pinggy r:Referer u:Host:example.com

Other controls:

Web Debugger

ssh -p 443 -R0:localhost:8080 -L4300:localhost:4300 a.pinggy.io
# Open http://localhost:4300
# API examples: GET /urls, GET /ipwhitelist

Use it to inspect requests/responses, replay modified HTTP requests, verify webhook payloads, and compare proxy headers before involving Burp, ZAP, mitmproxy, or app logs. Do not use HTTP debugger mode for secrets that Pinggy should not see; choose tls instead.

Multi-Forwarding and Domains

Pro tokens can route multiple services through one session, especially with wildcard custom domains.

ssh -p 443 \
  -R http//app.example.com:1:localhost:3000 \
  -R http//api.example.com:1:localhost:8080 \
  -R tcp//ssh.example.com/34567:1:localhost:22 \
  -R 1:localhost:80 \
  TOKEN@pro.pinggy.io

Listen address syntax: [schema//]hostname[/port][@name]. Schemas include http, tcp, tls, tlstcp, and udp. Custom domains use CNAME where possible; apex/root domains use relay setup. Relay-based custom domains do not support UDP, so use persistent subdomains/ports for UDP.

Offensive Lab Synergies

Use Pinggy as the public ingress layer; pair it with specialist tools locally.

When an operation needs SOCKS pivoting through a compromised host, prefer chisel. Use Pinggy when a public SaaS ingress endpoint is acceptable and fast setup matters more than stealth or routing.

CLI, SDK, Docker, and APIs

# CLI install and basic use
npm install -g pinggy
pinggy --help
pinggy -l 8000
pinggy --type tcp -l 22
pinggy --serve /path/to/files

# Saved configs and auto-start
pinggy config save my-tunnel -l 3000 TOKEN@pro.pinggy.io
pinggy start my-tunnel
pinggy start --all
pinggy start --all --remote-management <API_KEY>

• CLI has auto-reconnect, JSON-style saved configuration, file-server mode, logging, and remote management.
• Node.js SDK: use @pinggy/pinggy, pinggy.forward({ forwarding: "localhost:5000" }), then read tunnel.urls().
• Python SDK: install pinggy, then pinggy.start_tunnel(forwardto="localhost:8000").
• Pro API can list active tunnels and query session history with Authorization: Bearer <API_KEY>.

Egress-Constrained Clients

# HTTP proxy with nc/ncat
ssh -p443 -R0:localhost:4000 -o ProxyCommand="nc -X connect -x 192.0.2.10:3128 %h %p" a.pinggy.io
ssh -p443 -R0:localhost:4000 -o ProxyCommand="ncat --proxy-type http --proxy 192.0.2.10:3128 %h %p" a.pinggy.io

# SSH-over-SSL when only TLS egress is allowed
ssh -p443 -R0:localhost:4000 -o ProxyCommand="openssl s_client -quiet -connect %h:%p" a.pinggy.io
ssh -p7878 -R0:localhost:4000 -o ProxyCommand="ncat --ssl %h %p" a.pinggy.io

Use these only when policy allows outbound proxy/TLS tunneling. On Windows, PuTTY proxy settings or installed OpenSSL/ncat can fill the same role.

Troubleshooting

Resources