Pinggy vs localhost.run: Zero-Install SSH-Reverse-Tunnels

Betritt man im Jahr 2026 ein beliebiges Unternehmen für Enterprise-Software, findet man dort einen stillen, anhaltenden Konflikt zwischen Entwicklern und der IT-Abteilung. Entwickler müssen schnell iterieren — eine lokale Web-App mit QA teilen, externe Webhooks von Stripe oder GitHub testen, eine mobile Backend-Preview auf einem Laptop laufen lassen. Die IT hingegen setzt Zero-Trust-Netzwerkrichtlinien durch: eingehender Traffic ist standardmäßig blockiert, ausgehender wird genau überwacht.

Seit Jahren war die Standardmethode für Entwickler, ein Drittanbieter-Tunneling-Binary herunterzuladen, es auszuführen und eine öffentliche URL zu erhalten. Mit verschärften Sicherheitsmaßnahmen wurde das schwieriger. Das Mitbringen eines nicht genehmigten Executables auf einen verwalteten Laptop ist heute ein schneller Weg, um eine EDR-Alarm auszulösen.

Daher setzten Entwickler auf etwas, das überall bereits whitelisted ist: den nativen SSH-Client. Mit einem SSH-Reverse-Tunnel kannst du einen lokalen Port mit der Außenwelt teilen, ohne etwas zu installieren. Zwei Dienste, die speziell auf dieses Muster ausgelegt sind — Pinggy und localhost.run — sind die bevorzugten Backends dafür geworden. Hier erfährst du, wie die Technik funktioniert, wie die beiden Dienste im Jahr 2026 tatsächlich verglichen werden, und wo Marketing Dinge zu stark vereinfachen.

Warum traditionelle Tunnels im Unternehmen Schwierigkeiten haben

Tools, die auf einem lokal installierten Agent basieren, boten Entwicklern eine großartige Erfahrung, verursachten aber echte Kopfschmerzen bei Sicherheitsteams:

• Blockierte Binärdateien. EDR-Plattformen wie CrowdStrike oder SentinelOne blockieren routinemäßig nicht signierte oder unbekannte Executables, und Drittanbieter-Tunneling-Agents fallen in diese Kategorie.
• Erhöhte Privilegien. Manche Agents wollen Netzwerkschnittstellen manipulieren oder als Hintergrunddienst laufen — Zugriff, den die meisten Entwickler auf verwalteten Maschinen nicht haben.
• Nicht-Standard-Traffic. Einige Agents verwenden benutzerdefinierte Protokolle oder Ports, die durch Deep Packet Inspection markiert oder verworfen werden.

Das Ergebnis: Ein Entwickler, der einen Webhook-Payload testen will, verliert Tage im Genehmigungsprozess, nur um dann vom Firewall die outbound Verbindung des Binaries blockiert zu bekommen.

Die Lösung: SSH-Reverse-Tunnels, erklärt

SSH ist vorinstalliert auf macOS, Linux und (seit Windows 10 Update 2018) Windows, und wird von der IT vertraut, weil es das Rückgrat der Serververwaltung ist. Weniger gebräuchlich, aber im selben Protokoll integriert, ist remote/reverse port forwarding — das -R-Flag.

# Klassische Syntax für Reverse-Tunnel
ssh -R [remote-port]:localhost:[local-port] user@remote-server.com

Anstatt eine eingehende Lücke in der Firewall zu öffnen, startet ein Reverse-Tunnel eine ausgehende Verbindung von deinem Rechner zu einem öffentlichen Server. Da die Verbindung innerhalb des Netzwerks initiiert wird, lassen NAT und Stateful-Firewall-Regeln sie ohne spezielle Konfiguration durch. Der Remote-Server nutzt dann diese Verbindung, um den Traffic zurück an deinen lokalen Port zu leiten.

Zum Port-443-Trick: SSH läuft normalerweise auf Port 22, und viele Firmfirewalls blockieren speziell ausgehenden Port 22, um dieses Tunneln zu verhindern. Pinggy umgeht das, indem es SSH-Verbindungen auch auf Port 443 akzeptiert — dem Port, der normalerweise für HTTPS reserviert ist — wodurch der Traffic viel schwerer von normalem verschlüsseltem Web-Browsing zu unterscheiden ist. Das ist eine echte, dokumentierte Funktion von Pinggy. localhost.run dokumentiert derzeit keinen äquivalenten SSH-Listener auf Port 443 — seine Beispiele verwenden alle den Standard-SSH-Port. Wenn dein Netzwerk speziell Port 22 blockiert, ist das ein praktischer Unterschied zwischen den beiden, nicht nur eine Stilfrage.

Pinggy vs localhost.run: Der Vergleich 2026

localhost.run — der Minimalist

localhost.run folgt der Philosophie “SSH und nichts anderes.” Ein Befehl, eine URL, keine Konfigurationsdatei, kein TUI.

• Kostenlose Nutzung: Kein Signup nötig für einen kurzlebigen Tunnel, keine Zeitbegrenzung für die Session — es wird als “forever free” angeboten. Der Nachteil ist, dass die kostenlose Domain bei jeder neuen Verbindung rotiert und keine Prioritätsbandbreite besteht.
• Bezahlte Version: Ein Custom-Domain-Abonnement (ca. $9/Monat, jährlich abgerechnet) bietet eine stabile Domain — entweder deine eigene oder eine lhr.rocks-Subdomain — plus Prioritätsbandbreite. TLS-Passthrough-Tunnels (Weiterleitung von rohem, unverschlüsseltem TLS auf Port 443) sind nur bei Custom Domains verfügbar, nicht in der kostenlosen Version.
• Sicherheit: Keine integrierte Basic Auth oder IP-Allowlist. Du solltest die Authentifizierung in deiner App selbst regeln oder auf die schwer zu erratende URL vertrauen.
• Protokoll-Unterstützung: Nur HTTP/HTTPS in der kostenlosen Version.

Das richtige Tool, wenn du in den nächsten zehn Sekunden eine URL brauchst und es dir egal ist, dass sie beim nächsten Mal anders ist.

Pinggy — die funktionsreiche Option

Pinggy hat die gleiche “kein Binary”-Einschränkung genommen und daraus ein deutlich reichhaltigeres Produkt gebaut, mit einem cleveren Trick: SSH erlaubt es, einen beliebigen String als Benutzernamen zu übergeben, und Pinggy’s Edge parst diesen String nach Tokens und Schlüsselwörtern, noch bevor der Tunnel aufgebaut wird.

• Kostenlose Version: Sitzungen dauern 60 Minuten pro Verbindung (erneutes Verbinden ergibt eine neue zufällige Subdomain), unbegrenzte Bandbreite und sofortige HTTP und HTTPS-URLs via Let’s Encrypt.
• Bezahlte Version: Pinggy Pro kostet etwa $2,50–$3/Monat für eine persistenten Subdomain, eigene Domains und Team-Features — deutlich günstiger als die meisten Wettbewerber.
• Protokoll-Unterstützung: HTTP(S), TCP, UDP, und TLS-Tunnel — TCP und TLS sind auch in der kostenlosen Version verfügbar.
• Web Debugger: Mit -L4300:localhost:4300 im SSH-Befehl wird Pinggy’s Request/Response-Inspektor an localhost:4300 in deinem Browser weitergeleitet, und es gibt eine kleine lokale API (/urls, /ipwhitelist) für Automatisierungen.
• Auth an der Edge: Basic Authentication, IP-Allowlisting und Live-HTTP-Header-Manipulation werden durch Schlüsselwörter im SSH-Benutzernamen aktiviert — kein lokaler Proxy oder zusätzliche Software nötig.

Das Urteil hat sich 2026 kaum geändert: localhost.run gewinnt bei reiner “Gib mir sofort eine URL”-Einfachheit; Pinggy punktet bei TCP/UDP, Request-Inspection oder Auth an der Edge, und ist bereit, jede Stunde neu zu verbinden, auch in der kostenlosen Version.

Schritt-für-Schritt: No-Install Localhost-Sharing

Szenario 1 — Schnelles Teilen mit localhost.run

Du hast eine React-App auf Port 3000 und willst sie sofort zeigen.

ssh -R 80:localhost:3000 localhost.run

Das leitet den öffentlichen Tunnel an deinen lokalen Port 3000 weiter und gibt eine HTTP- und HTTPS-URL aus.

Szenario 2 — Funktionsreicher Tunnel mit Pinggy

Du hast eine Node-API auf Port 8080 und willst eine Firmfirewall umgehen, während du eingehende Webhook-Payloads inspizierst.

ssh -p 443 -R0:localhost:8080 -L4300:localhost:4300 free@a.pinggy.io

• -p 443 — verbindet über Port 443, damit der SSH-Handshake im normalen HTTPS-Traffic verschwindet.
• -R0:localhost:8080 — fordert Pinggy auf, eine zufällige öffentliche Subdomain zuzuweisen, die an Port 8080 weitergeleitet wird.
• -L4300:localhost:4300 — leitet Pinggy’s Web Debugger an dein Gerät weiter, sodass du Anfragen bei http://localhost:4300 inspizieren kannst.
• free@a.pinggy.io — verbindet zum kostenlosen Tier von Pinggy.

Szenario 3 — Tunnel mit Basic Auth absichern

Da Pinggy den SSH-Benutzernamen als Schlüsselwort-String liest, kannst du HTTP Basic Auth direkt an der Edge injecten, bevor der Traffic dein Laptop erreicht:

ssh -p 443 -R0:localhost:3000 "b:admin:supersecret+free@a.pinggy.io"

b:admin:supersecret ist das dokumentierte Basic-Auth-Schlüsselwort von Pinggy (Benutzername und Passwort dürfen keinen Doppelpunkt enthalten). Besucher bekommen eine Standard-Browser-Auth-Prompt; ohne die Anmeldedaten kommt niemand auf dein Gerät.

Szenario 4 — Durch einen Firm-HTTP-Proxy kommen

Wenn dein Netzwerk den gesamten ausgehenden Traffic durch einen expliziten HTTP-Proxy leitet — also auch Port 443 SSH blockiert — kannst du die Verbindung mit ProxyCommand tunneln:

ssh -p 443 -R0:localhost:3000 \
  -o ProxyCommand="ncat --proxy-type http --proxy proxy.corporate.local:3128 %h %p" \
  free@a.pinggy.io

Das tunnelt den SSH-Handshake selbst durch den Firm-Proxy als HTTP CONNECT-Anfrage, was ein gängiges Muster mit ncat/ProxyCommand ist, genau für diese Situation.

Was 2026 neu ist: Über reines SSH hinaus

Der reine ssh -R-Befehl funktioniert weiterhin genau wie oben beschrieben, aber Pinggy hat in diesem Jahr mehr drumherum gebaut, was du wissen solltest:

• Ein dedizierter CLI (npm install -g pinggy oder das Äquivalent für andere Paketmanager), der das gleiche SSH-Protokoll nutzt, aber eine benutzerfreundlichere TUI, gespeicherte Tunnel-Konfigurationen und automatische Wiederverbindung bietet — ohne separate Binary außerhalb eines Paketmanagers.
• Node.js- und Python-SDKs für programmatisches Starten und Verwalten von Tunneln aus eigenen Skripten oder CI-Jobs, statt direkt ssh aufzurufen.
• Offizielle AI-Agent-Integration — Pinggy dokumentiert jetzt ein Skill/MCP-Server-Muster, um KI-Coding-Agenten das Öffnen und Verwalten von Tunneln im Auftrag eines Entwicklers zu ermöglichen, was zeigt, wie viel lokale Entwicklungstools inzwischen von Agenten gesteuert werden.

Nichts davon ändert die Kernbotschaft — es bleibt bei Zero-Install beim Einsatzort — aber es zeigt, dass das “SSH als Tunneling-Backend”-Muster sich gut entwickelt hat, weg von einem cleveren Workaround.

Sicherheitsimplikationen der Rebellion

Sicherheitsteams haben gemischte Gefühle zu diesem Trend, und das ist verständlich.

Einerseits ist die Nutzung von nativen SSH-Tools arguably sicherer als das Herunterladen nicht geprüfter Drittanbieter-Binaries — die Kryptografie ist Standard-OS-SSH, und es gibt keinen Closed-Source-Agent, der als Trojaner fungieren könnte.

Andererseits schafft die einfache Umgehung von Outbound-Beschränkungen ein Shadow-IT-Problem. Wenn ein Entwickler eine unautorisierte lokale Datenbank oder eine Entwicklungsumgebung mit echten Kundendaten tunnelt, umgeht er die Perimeter-Kontrollen des Unternehmens — absichtlich oder unabsichtlich.

Best Practices für verantwortungsvolles Tunneln

• Keine echten Daten exponieren. Nutze Mock-Daten in lokalen Umgebungen, die du tunneln willst.
• Immer am Edge authentifizieren. Nutze Pinggy’s Basic Auth, IP-Allowlisting oder Bearer-Token-Features statt einer schwer zu erratenden URL.
• Inaktive Tunnels beenden. Ctrl+C sofort, wenn du fertig bist.
• Leistungsgrenze kennen. SSH-Reverse-Tunneling ist TCP-über-TCP, was bei Paketverlust zum bekannten “TCP-Meltdown”-Problem führen kann — gut für APIs und UIs, weniger ideal für große Dateiübertragungen.

Fazit

Der Vergleich Pinggy vs localhost.run ist eigentlich ein Vergleich von Philosophien: absolute Minimalistik versus ein volleres Funktionsset, beide basieren auf dem gleichen jahrzehntealten SSH-Reverse-Tunnel-Trick und sind beide wirklich frei von Binaries. Ob du eine Firmfirewall umgehen willst, um einen Stripe-WebHook zu testen, oder deinem Kunden einen Link für die nächsten zehn Minuten geben willst — das Tool liegt bereits in deinem Terminal.

---

Changelog (Faktencheck und Update)

• Korrigiert/klargestellt: Der ursprüngliche Entwurf implizierte, dass beide Dienste Firewalls über Port 443 gleich gut umgehen. Pinggys Port-443-SSH-Listener ist in der eigenen Dokumentation beschrieben; die CLI-Referenz von localhost.run zeigt nur den Standard-SSH-Port, daher bietet es nicht den gleichen dokumentierten Vorteil bei Netzwerken, die Port 22 speziell blockieren.
• Verifiziert als korrekt, beibehalten: Die -R-Syntax für Reverse-Tunnel; der Befehl ssh -R 80:localhost:3000 localhost.run (entspricht exakt dem Beispiel in der Dokumentation von localhost.run); Pinggys -L4300:localhost:4300 Web Debugger-Flag und die b:user:pass Basic-Auth-Schlüsselwortsyntax (beide bestätigt in der aktuellen CLI-Dokumentation von Pinggy); die 60-Minuten-Session im kostenlosen Tier von Pinggy; die TCP-über-TCP “Meltdown”-Leistungswarnung.
• Hinzugefügt: Aktuelle Preisangaben — Pinggy Pro (~$2.50–3/Monat) vs. localhost.run’s Custom Domain (~$9/Monat, jährlich); localhost.run’s Free Tier hat keine Session-Zeitbegrenzung (im Gegensatz zu Pinggy’s 60 Minuten), rotiert aber die Domain und bietet keine Auth- oder Allowlist-Funktionen; TLS-Passthrough-Tunnels sind nur bei Custom Domains verfügbar, nicht kostenlos.
• Hinzugefügt (neuer Abschnitt): Pinggy’s CLI 2026, Node.js/Python SDKs und die dokumentierte Skill/MCP-Server-Integration für KI-Coding-Agenten — alles, was im ursprünglichen “nur rohes SSH”-Rahmen noch nicht existierte.
• Entfernt: Originale Inline-Metadaten/Formatierungsartefakte; aufgeräumt und in Markdown bereinigt.