Der agentless Proxy: Downloadbare Clients durch SSH ersetzen

e Wie ein einzelner SSH-Befehl bloatige CLI-Dienste ersetzt — und was Ihr InfoSec-Team darüber wissen muss.

Das Problem: Wenn Ihr Laptop keine Installationen zulässt

Moderne Unternehmensendpunkte sind strenger denn je gesichert. Endpoint Detection and Response (EDR)-Plattformen wie CrowdStrike Falcon, SentinelOne und Microsoft Defender for Endpoint erkennen und blockieren aktiv die Installation von nicht signierten oder unbekannten Binärdateien — inklusive beliebter Tunneling-CLIs, die in Go oder Rust geschrieben sind. Application Whitelisting-Richtlinien bedeuten, dass selbst legitime Entwickler-Tools vor ihrer Ausführung in Quarantäne genommen werden können.

Für Entwickler, die eine lokal laufende React-App für eine schnelle Stakeholder-Überprüfung teilen oder einen Webhook-Endpunkt für Stripe-Integrationen testen möchten, entsteht so ein frustrierendes Paradoxon: Die Werkzeuge, die das Problem lösen könnten, werden selbst durch Richtlinien blockiert.

Die elegante Lösung liegt bereits auf jedem Entwicklerrechner: OpenSSH.

Was ist agentless Localhost-Tunneling?

Agentless Tunneling (auch Zero-Install-Tunneling genannt) bedeutet, einen lokalen Port mithilfe des bereits in Ihrem Betriebssystem integrierten SSH-Clients öffentlich zugänglich zu machen — kein heruntergeladener Binary, kein npm-Paket, keine erhöhten Installationsrechte erforderlich.

Die Technik basiert auf dem Remote Port Forwarding (-R) Flag von SSH, das einem entfernten Server mitteilt, öffentlichen Traffic anzunehmen und ihn verschlüsselt durch einen SSH-Tunnel an einen Port auf Ihrem lokalen Rechner weiterzuleiten. Der Relay-Server fungiert als öffentlich zugänglicher Endpunkt; Ihr Laptop ist die versteckte Herkunft.

Die Architektur sieht folgendermaßen aus:

[ Öffentlicher Internetnutzer ]
         │
         ▼ (HTTPS-Anfrage)
[ Relay-Server ] (z.B. *.pinggy.io)
         │
         │ SSH Reverse Tunnel (Port 443)
         ▼
[ Ihr Laptop ] (Native OpenSSH-Client)
         │
         ▼ (Interne Weiterleitung)
[ Lokale App ] (z.B. Node.js auf localhost:3000)

Das Einzeiler-Dissection

Hier ein typischer Zero-Install-Tunnel-Befehl:

ssh -p 443 -R0:localhost:3000 free@a.pinggy.io

Jedes Flag hat eine spezielle Funktion:

ssh — Ruft den nativen OpenSSH-Binary auf. Kein Download nötig; ist in macOS, allen gängigen Linux-Distributionen und Windows ¹⁰⁄₁₁ enthalten.
-p 443 — Verbindet über Port 443 statt des Standard-SSH-Ports 22. Dies ist eine bewusste technische Entscheidung: Unternehmensfirewalls erlauben fast ausnahmslos ausgehenden HTTPS-Verkehr auf 443, während Port 22 häufig blockiert ist. Der SSH-Handshake läuft über denselben Kanal wie normaler Webverkehr.
-R — Aktiviert Remote Port Forwarding. Dies weist den entfernten Server an, einen Port zu öffnen und den Traffic zu Ihnen weiterzuleiten.
0:localhost:3000 — Die 0 fordert den Relay auf, dynamisch einen verfügbaren öffentlichen Port oder Subdomain zuzuweisen. localhost:3000 teilt dem Relay mit, wohin der Traffic auf Ihrem Rechner gesendet werden soll.
free@a.pinggy.io — Die Adresse des Relay-Servers, mit free als Präfix für den Benutzernamen (Pinggy nutzt dieses Feld für Parameter-Injection, später erklärt).

Beim Ausführen generiert der Relay-Server eine öffentliche URL — etwa https://rkyxl-12-34-56.a.pinggy.link — die direkt im Terminal ausgegeben wird und sofort geteilt werden kann.

Warum Port 443 der entscheidende Trick ist

Die meisten Unternehmensfirewalls sind so konfiguriert, dass ausgehender Port 22 von Entwicklerarbeitsstationen blockiert wird, um unbefugtes Remote-Management zu verhindern. Port 443 ist für HTTPS-Webverkehr reserviert und fast immer offen — eine Blockierung würde das normale Surfen im Web für die gesamte Organisation unterbrechen.

Durch SSH über 443 wird der initiale Handshake des Tunnels ununterscheidbar von einer normalen TLS-Verbindung zu einem Webserver. Deep Packet Inspection (DPI)-Geräte erkennen es als hochvolumigen verschlüsselten HTTPS-Traffic. Wie in Sicherheitsforschungen von JUMPSEC Labs erwähnt, erlauben viele Unternehmensumgebungen immer noch ausgehendes SSH, auch wenn sie es glauben zu blockieren, weil die Überwachung von SSH als “Living off the Land”-Binary (LOLBIN) für Malware-Detectionen nicht Standard ist.

e Wichtiger Hinweis für Sicherheitsteams: Diese Dual-Use-Natur wird im Abschnitt Sicherheit weiter unten detailliert behandelt.

Die führenden agentless Tunneling-Plattformen im Jahr 2026

Da jeder Nutzer dasselbe Standard-SSH-Binary verwendet, liegt die Differenzierung zwischen Zero-Install-Diensten ausschließlich in den Fähigkeiten des Relay-Servers. Hier die Plattformen, die man kennen sollte:

1. Pinggy

Pinggy hat sich als die funktionsreichste agentless-Option etabliert, die ohne Installation auskommt. Ein einzelner SSH-Befehl startet eine voll interaktive Terminal-Benutzeroberfläche (TUI) mit Echtzeit-Anfragen-Zähler, Live-Traffic-Statistiken und einem QR-Code direkt im Terminal — nützlich für sofortiges mobiles Responsiveness-Testing.

Hauptfunktionen: - Protokollunterstützung für HTTP, HTTPS, TCP und UDP (UDP-Tunneling bieten weder ngrok noch Localtunnel) - Eingebauter Web-Debugger unter http://localhost:4300, bei Kombination mit einer lokalen Portweiterleitung (-L 4300:localhost:4300), um HTTP-Header, Payloads und Request-Replays zu inspizieren - Erweiterte Traffic-Kontrolle durch den SSH-Benutzernamen (Authentifizierung, IP-Whitelisting, CORS-Overrides, benutzerdefinierte Header — alles ohne Konfigurationsdatei) - Kostenlose Sessions nach 60 Minuten; kostenpflichtige Tarife ab 3 USD/Monat für dauerhafte Tunnel

Bestätigte Funktionalität (Stand März 2026, getestet vom NousResearch Hermes Agent Team): Ein einzelner SSH-Befehl liefert sofort HTTP- und HTTPS-öffentliche URLs mit kostenlosen Let’s Encrypt-Zertifikaten, kein Konto erforderlich.

Leistungshinweis: Bei einem 100 MB-Datei-Transfer-Benchmark im Jahr 2025 erzielte Pinggy ca. 1,10 MB/sec (8,81 Mbps), was der langsamste Wert unter den getesteten Tools war. Das liegt vor allem am TCP-over-TCP-Problem bei SSH-basiertem Tunneling: Sowohl die innere TCP-Schicht der Anwendung als auch der äußere SSH-Tunnel führen eigenes Congestion Control durch, und ein verlorenes Paket auf der äußeren Schicht kann die innere Verbindung zum Stillstand bringen. Für Webhook-Tests und UI-Sharing ist das selten ein Problem; bei großen Dateiübertragungen jedoch relevant.

2. localhost.run

Für absolute Minimalisten bietet localhost.run eine zuverlässige, konfigurationsfreie Alternative ohne visuelle Überladung:

ssh -R 80:localhost:3000 nokey@localhost.run

Der Server liefert einen sauberen HTTPS-Link und bleibt im Hintergrund — ideal für automatisierte Bash-Skripte, CI/CD-Validierungen und Situationen, in denen der Terminalplatz erhalten bleiben soll. Unterstützt nur HTTP und HTTPS (keine TCP oder UDP), läuft auf jedem OS mit SSH. Kein Konto erforderlich, um sofort zu tunneln.

3. Serveo

Serveo ist eine lang etablierte kostenlose Option, die für eine Funktion bekannt ist: Sie können direkt im Befehl eine spezifische Subdomain anfordern:

ssh -R mysubdomain:80:localhost:5000 serveo.net

Wenn die Subdomain verfügbar ist, bindet der Server sie sofort. Das ist nützlich für persistent Webhook-URLs während der Entwicklung. Als community-unterstützte Free-Ressource kann die Verfügbarkeit unter Last schwanken — wichtig bei zeitkritischen Anwendungen.

4. Localtonet (SSH-Modus)

Localtonet begann als client-lastiges Multi-Protokoll-Tunneling-Tool, hat aber eine dedizierte Zero-Install-SSH-Entry-Point aufgebaut. Nutzer konfigurieren einen Tunnel über ein Web-Dashboard, das einen token-authentifizierten SSH-Befehl ausgibt. Das verbindet Unternehmenskontrollanforderungen mit agentless-Ausführung.

Stand Januar 2026 kostet Localtonet 2 USD pro Tunnel und Monat, bietet Multi-Region-Redundanz, UDP-Unterstützung, SSO-Integration und 99,9% Verfügbarkeit — die vollständigste Option für Teams, die mehr als nur eine schnelle Demo-URL benötigen.

Vergleich zu traditionellen Tools

Feature	Pinggy	localhost.run	Serveo	ngrok	Cloudflare Tunnel
Installation erforderlich	Nein (SSH)	Nein (SSH)	Nein (SSH)	CLI-Binary	`cloudflared`-Daemon
Protokollunterstützung	HTTP, HTTPS, TCP, UDP	HTTP, HTTPS	HTTP, HTTPS, TCP	HTTP, HTTPS, TCP	HTTP, HTTPS, gRPC
Terminal-Dashboard	Ja (interaktiv)	Nein (nur Text)	Nein (nur Text)	Ja (benutzerdefinierte CLI)	Nein (Cloud-Konsole)
Web-UI-Inspektor	Ja (über lokalen Port)	Nein	Nein	Ja (localhost-Port)	Ja (Cloud-Konsole)
Benutzerdefinierte Domains	Kostenpflichtige Tarife	Kostenpflichtige Tarife	Ja (wenn verfügbar)	Kostenpflichtige Tarife	Ja (kostenlos via DNS)
Kostenlose Nutzungslimit	60 Min. Sessions	Unbegrenzt	Unbegrenzt	1 GB/Monat	Unbegrenzte Bandbreite
UDP-Unterstützung	Ja	Nein	Nein	Nein	Nein
Durchsatz (100 MB Test)	~1,10 MB/s	Nicht getestet	Nicht getestet	~0,84 MB/s	~3,47 MB/s

ngrok-Preise Anfang 2026: Kostenlose Version (1 GB/Monat, zufällige Domains, Warnung bei Session-Überschreitung), Personal ab 8 USD/Monat (5 GB, 1 dauerhafte Domain), Pro ab 20 USD/Monat (15 GB, Edge-Config, Load-Balancing). Cloudflare Tunnel bleibt vollständig kostenlos für HTTP/HTTPS ohne Bandbreitenbegrenzung — äußerst preiswert für Teams im Cloudflare-Ökosystem — erfordert jedoch die Installation des cloudflared-Daemons.

Erweiterte Funktionen ohne Client: Parameter-Injection via SSH-Benutzername

Ein verbreitetes Missverständnis ist, dass agentless-Ansätze den Zugriff auf erweiterte Funktionen wie Authentifizierung, Header-Manipulation und CORS-Kontrolle einschränken. Pinggy hat dieses Problem gelöst, indem es eine Funktion des SSH-Protokolls nutzt, die die meisten Entwickler übersehen: Der SSH-Benutzername kann beliebige Strings tragen.

Da das SSH-Verbindungsprotokoll jeden String als Benutzernamen erlaubt, wertet Pinggy diesen auf ihren Edge-Knoten aus, um Traffic-Konfigurationen dynamisch anzuwenden, bevor Pakete ins Tunnel gelangen. Sie übergeben Ihre Parameter durch Trennung mit +.

Grundlegende Authentifizierung

Schützen Sie eine öffentliche URL mit Benutzername/Passwort — nützlich, wenn interne Tools extern zugänglich gemacht werden sollen:

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

Pinggy’s Edge fängt eingehende Anfragen ab und zeigt eine Standard-HTTP-Basic-Auth-Dialogbox im Browser. Ihr lokaler Server erhält niemals eine unautorisierte Anfrage.

IP-Whitelisting (CIDR)

Beschränken Sie den Zugriff auf einen bestimmten IP-Bereich — z.B. Ihre VPN-Ausgangs-IP:

ssh -p 443 -R0:localhost:3000 "w:192.0.2.0/24+free@a.pinggy.io"

Benutzerdefinierte HTTP-Header-Injektion

Nützlich, um bestimmte Umgebungen zu simulieren, API-Gateway-Checks zu umgehen oder Webhook-Signaturen zu validieren:

ssh -p 443 -R0:localhost:3000 "a:X-Environment:Staging+free@a.pinggy.io"

Globale CORS-Overrides

Beim Testen von Microservices über verschiedene Ursprünge und bei Cross-Origin-Blocking, das Frontend-Execution stoppt:

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

Parameter können verkettet werden. Ein Tunnel mit Basic-Auth, aktivem CORS und benutzerdefiniertem Header sieht so aus:

ssh -p 443 -R0:localhost:3000 "b:admin:pass+co+a:X-Environment:Staging+free@a.pinggy.io"

Dies verschiebt komplexe Routing- und Sicherheitslogik auf Edge-Server, vollständig gesteuert durch String-Parsing im SSH-Handshake.

Umgang mit restriktiven Proxys

Wenn Ihr Netzwerk auch ausgehenden Port 443 blockiert oder den Traffic durch einen HTTP-Proxy leiten muss, dokumentiert Pinggy eine Lösung mit ncat und openssl:

ssh -p 443 -R0:localhost:4000 \
  -o ProxyCommand="ncat --proxy-type http --proxy 192.168.2.2:3128 %h %p" \
  a.pinggy.io

Dies leitet den SSH-Tunnel durch Ihren Unternehmens-HTTP-Proxy, auch in Umgebungen mit strengen ausgehenden Filtern.

Die Sicherheits-Perspektive: Was InfoSec-Teams wissen müssen

Zero-Install-Tunneling ist grundsätzlich dual-use. Die Eigenschaften, die es für Entwickler so reibungslos machen — verschlüsselter Traffic auf Port 443, kein Binary, keine Installationsereignisse — machen es auch zu einem möglichen Datenexfiltrations-Tool, wenn missbraucht oder ausgenutzt.

Was Entwickler gewinnen

Aus Sicht des Datenflusses ist agentless Proxy wirklich sicher. Die Verbindung zwischen Entwicklerrechner und Relay-Server ist in SSH-Verschlüsselung (AES-GCM oder ChaCha20-Poly1305) eingebettet. Der Traffic auf der öffentlichen Seite läuft über standardmäßiges HTTPS zum Anbieter-Edge, wo er entschlüsselt und vor dem Ziel wieder verschlüsselt wird. Auf offenen oder kompromittierten lokalen Netzwerken — Kaffeehaus-Wi-Fi, Konferenzhotels — können Unternehmensdaten nicht ausgespäht oder abgefangen werden.

Was Sicherheitsteams überwachen sollten

Da der Traffic in einem verschlüsselten SSH-Wrapper auf Port 443 läuft, klassifizieren DPI-Geräte ihn als generischen HTTPS-Traffic. Es gibt kein Binary-Installationsereignis, keine Registry-Änderung, keinen Prozess mit ungewöhnlichem Namen. Das einzige Signal ist eine ausgehende SSH-Verbindung zu einer unbekannten Domain.

Praktische Governance-Ansätze, die zukunftsorientierte Sicherheitsteams übernehmen:

Relay-Infrastruktur-Whitelisting. Anstatt alle SSH-Tunnel zu blockieren (was legitime Nutzung gefährdet), arbeiten Unternehmen mit kommerziellen Zero-Install-Anbietern wie Pinggy Pro oder Localtonet Enterprise zusammen. Die Organisation konfiguriert eine dedizierte, benutzerdefinierte Domain (z.B. *.tunnels.company.com) und whitelisted die statischen IP-Bereiche dieser Relay-Knoten im Firewall. Unautorisierte Relay-Anbieter werden standardmäßig blockiert.

SSH-Key-Policy. Sicherheitsteams verlangen, dass jeder SSH-Tunnel, der von einem Unternehmensgerät initiiert wird, mit einem autorisierten SSH-Key-Paar verbunden ist, das an den Identity Provider (IdP) des Mitarbeiters gebunden ist. So wird vollständige Nachvollziehbarkeit gewährleistet: Welcher Account hat den Tunnel geöffnet, wann, und wie viel Bandbreite wurde übertragen.

Ephemere Laufzeiten. Pinggy’s kostenlose Version erzwingt automatische 60-Minuten-Sitzungsabbrüche. InfoSec-Teams können dies als Feature statt als Limit nutzen, indem sie festlegen, dass Tunnel temporäre Ressourcen sind — bei Bedarf für Debugging, sofort nach Abschluss wieder geschlossen. Das minimiert die Angriffsfläche für Internet-Scanner und persistente Bedrohungsakteure.

Verhaltensbasierte Erkennung. Sicherheitstools wie Zeek und moderne EDR-Plattformen mit SSH-Verhaltensregeln können so konfiguriert werden, dass sie ungewöhnliche Port-Forwarding-Muster erkennen — z.B. eine Workstation, die einen -R-Forward zu einem externen Host aufbaut, oder lang andauernde hochbandbreitige SSH-Sitzungen zu nicht-unternehmensbezogenen Domains. Das ist eine nachhaltigere Erkennungsstrategie als das vollständige Blockieren von SSH.

Wann was verwenden: Ein Entscheidungsrahmen

Verwenden Sie Pinggy, wenn: Sie innerhalb von 30 Sekunden etwas ohne Installation benötigen, einen Request-Inspektor wollen, UDP-Unterstützung brauchen oder einen QR-Code für mobiles Testing teilen möchten.

Verwenden Sie localhost.run, wenn: Sie Automatisierungen skripten, CI/CD-Validierungen durchführen oder einen ruhigen Hintergrundprozess ohne Terminal-Dashboard benötigen.

Verwenden Sie Serveo, wenn: Sie während eines Entwicklungs-Sprints eine einprägsame, dauerhafte Subdomain brauchen und gelegentliche Verfügbarkeitsprobleme tolerieren können.

Verwenden Sie Localtonet, wenn: Sie im Team arbeiten, Multi-Region-Redundanz, SSO-Integration oder UDP-Unterstützung mit SLA benötigen.

Verwenden Sie Cloudflare Tunnel, wenn: Sie bereits im Cloudflare-Ökosystem sind, Produktionsqualität, unbegrenzte HTTP/HTTPS-Bandbreite brauchen und cloudflared installieren möchten. Es erreichte 3,47 MB/s im Durchsatztest 2025 — das schnellste aller getesteten Tunnellösungen.

Verwenden Sie ngrok, wenn: Sie die größte Integrationsvielfalt wollen und bereit sind, für Persistenz und Volumen zu bezahlen. Mit 0,84 MB/s ist es der langsamste, aber bekannteste Dienst.

Fazit

Der Fall für Zero-Install-Tunneling im Jahr 2026 geht über Bequemlichkeit hinaus — es geht darum, mit der Sicherheitsarchitektur der Unternehmen zu arbeiten, anstatt ständig gegen sie anzukämpfen. Ein nativer SSH-Binary ist vorvertrauenswürdig. Es generiert keine Installationsereignisse. Es benötigt keine erhöhten Rechte. Und läuft es über Port 443, passiert es ohne Probleme durch Unternehmens-Firewalls.

Die Plattformen, die auf diesem Modell aufbauen — Pinggy, localhost.run, Serveo, Localtonet — haben ein Reifegrad erreicht, der die Funktionen herkömmlicher CLI-Clients tatsächlich erreicht oder übertrifft. Die Möglichkeit, Parameter wie Auth, CORS und Header-Manipulation über den Benutzernamenstring in einem einzigen SSH-Befehl zu steuern, ersetzt die vorher erforderliche Konfigurationsdatei und einen laufenden Daemon.

Für InfoSec- und NetOps-Teams lautet die richtige Antwort nicht, SSH zu blockieren (was mehr Probleme schafft), sondern die Governance um genehmigte Relay-Infrastruktur, schlüsselbasierte Authentifizierung und Verhaltensüberwachung zu strukturieren. Die Werkzeuge sind vorhanden; die Rahmenwerke entwickeln sich.

Für Entwickler, die auf einem gesperrten Endpoint arbeiten: Hören Sie auf, Installationsrechte zu bekämpfen. Der mächtigste Tunnel-Client, den Sie brauchen, ist bereits auf Ihrem Rechner.

ssh -p 443 -R0:localhost:3000 free@a.pinggy.io

Das war’s.

Letzte Aktualisierung: Mai 2026. Preis- und Funktionsangaben für Pinggy, ngrok, Cloudflare Tunnel und Localtonet basieren auf aktuellen Dokumentationen und Drittanbieter-Benchmarks.

Zero-Install Tunneling im Jahr 2026: Der vollständige Entwicklerleitfaden zu agentless Localhost-Proxys