{"id":6,"date":"2014-05-25T22:24:44","date_gmt":"2014-05-25T20:24:44","guid":{"rendered":"http:\/\/chriskrz.selfhost.bz\/wordpress\/?p=6"},"modified":"2026-01-09T16:27:27","modified_gmt":"2026-01-09T15:27:27","slug":"reverse-ssh-tunnel-schritt-fur-schritt","status":"publish","type":"post","link":"https:\/\/www.rustimation.eu\/index.php\/reverse-ssh-tunnel-schritt-fur-schritt\/","title":{"rendered":"Reverse SSH Tunnel &#8211; Schritt f\u00fcr Schritt"},"content":{"rendered":"<p>Ein Reverse SSH Tunnel ist immer dann hilfreich, wenn man auf einen Raspberry Pi, der hinter einer Firewall l\u00e4uft, zugreifen will und die Firewall nicht selbst f\u00fcr Zugriffe von au\u00dfen freischalten kann.<br \/>\nZum Beispiel, wenn der Pi per Mobilfunk mit dem Internet verbunden ist. Mobilfunkprovider lassen meist keine Zugriffe von au\u00dfen auf die im Netz vorhandenen Clients zu. Au\u00dferdem wird in der Regel eine Network Address Translation (NAT) vorgenommen, um IP Adressen zu sparen. Ganz \u00e4hnlich wie bei eurem Router zuhause.<span style=\"color: #808080;\">\u00a0<\/span><\/p>\n<p>Diese Anleitung funktioniert bei jeder Art von Internetanbindung, also z.B. auch, wenn euer Ferienhaus, B\u00fcro etc. \u00fcber DSL am Internet h\u00e4ngt.<\/p>\n<p>Dieser Beitrag ist zwar schon ein paar Jahre alt; ich aktualisiere ihn aber laufend nach Erkenntnisfortschritt oder bei \u00c4nderungen im Raspberry Pi OS (ehemals Raspbian):<\/p>\n<p><!--more--><\/p>\n<p style=\"padding-left: 30px;\"><span style=\"color: #808080;\">Einger\u00fcckte Texte sind zus\u00e4tzliche Erkl\u00e4rungen und Exkurse. Wenn ihr es eilig habt, dann k\u00f6nnt ihr das auch \u00fcberlesen.<\/span><\/p>\n<h3>Begriffskl\u00e4rung<\/h3>\n<p>F\u00fcr das weitere Verst\u00e4ndnis dieses Artikels m\u00f6chte ich einige Begriffe definieren<\/p>\n<ul>\n<li><strong> Remote Pi<\/strong>: Das ist der Raspberry Pi, der im Mobilfunknetz etc. h\u00e4ngt und auf den \"von au\u00dfen\" zugegriffen werden soll<\/li>\n<\/ul>\n<ul>\n<li><strong> Gateway Pi<\/strong>: Das ist der Raspberry Pi, mit dem sich der Remote Pi verbindet und \u00fcber den auf den Remote Pi zugegriffen werden soll<\/li>\n<\/ul>\n<ul>\n<li><strong> SSH<\/strong>: Secure Shell, ein Protokoll bzw. Programm, das auf beiden Rechnern l\u00e4uft. Normalerweise ist SSH schon aktiviert, andernfalls \u00fcber <code>sudo raspi-config<\/code> den Punkt \"Advanced Options &#8211; SSH\" ausw\u00e4hlen.<br \/>\n<span style=\"color: #808080;\"><strong>Achtung<\/strong>:\u00a0 Bei Raspbian ab ca. Dezember 2016 ist SSH standardm\u00e4\u00dfig deaktiviert! Bitte die Hinweise in <a href=\"http:\/\/www.rustimation.eu\/index.php\/ssh-bei-neuen-distributionen-deaktiviert\/\" target=\"_blank\" rel=\"noopener noreferrer\">diesem Artikel<\/a> meines Blogs beachten.<\/span><br \/>\nSSH d\u00fcrfte jeder kennen, der \u00fcber Putty oder ein anderes Terminalprogramm auf den Pi zugreift.<\/li>\n<li><strong>Dynamische IP Adresse<\/strong>. In der Regel hat ein Privatmensch keine statische IP Adresse sondern bekommt von seinem Provider in regelm\u00e4\u00dfigen Abst\u00e4nden eine neue IP Adresse verpasst. Damit die gerade aktuelle Adresse \u00fcberhaupt gefunden wird, sollte man sich eine Dynamische IP Adresse zulegen. Das geht \u00fcber spezialisierte DynDNS Provider wie <a title=\"Selfhost\" href=\"http:\/\/www.selfhost.de\" target=\"_blank\" rel=\"noopener noreferrer\">Selfhost<\/a>. Wenn man bereit ist, diese Adresse monatlich zu best\u00e4tigen, kostet das dort noch nicht einmal etwas.<\/li>\n<li><strong>Hinweis zu IPv6 und DS-Lite<\/strong>: diese Anleitung funktioniert nur, wenn das Gateway \u00fcber eine \u00f6ffentlich erreichbare IPv4 Adresse im Internet h\u00e4ngt. Der Zugriff auf Heimnetzwerke, welche nur eine \u00f6ffentliche IPv6 Adresse haben, ist ungleich schwieriger und funktioniert auch nur, wenn der Remote Client ebenfalls mit IPv6 im Internet ist. Bei Mobilfunknetzen wird bislang (Ende 2017) fast nur mit IPv4 gefunkt.\u00a0 Betroffen sind Alle, die Zuhause (Gateway) mit DS-Lite (ausschlie\u00dfliche IPv6 Verbindung) am Internet angeschlossen sind. Hier n\u00fctzt meine Anleitung leider nichts. Ggf. kann man beim Provider aber eine IPv4 Adresse nachbuchen &#8211; gegen Aufpreis versteht sich.<\/li>\n<\/ul>\n<h3>Was ben\u00f6tige ich daf\u00fcr?<\/h3>\n<p>Folgende Voraussetzungen sind zu erf\u00fcllen:<\/p>\n<p><strong>Allgemein<\/strong><\/p>\n<ul>\n<li>Alle Eingaben etc. erfolgen im Terminalmodus bzw. \u00fcber ein Terminalfenster vom Raspberry Desktop.<\/li>\n<li>Ferner gehe ich davon aus, dass immer der User Pi verwendet wird, Raspbian in einer aktuellen Version installiert ist, und du schon etwas Erfahrung mit dem Terminalmodus des Pi sowie mit Putty oder einem anderen Terminalprogramm hast.<\/li>\n<\/ul>\n<p><strong>Remote<\/strong><\/p>\n<ul>\n<li>Logischerweise einen Raspberry Pi, sonst macht das alles ja keinen Sinn.<\/li>\n<li>Je nach Setup (DSL oder Mobilfunk) einen (mobilfunkf\u00e4higen) Router und unbedingt einen Flatrate Tarif, sonst wirds teuer, da der Tunnel immer wieder ein paar Byte durch den \u00c4ther jagt. Der Remote Router braucht <strong>keine<\/strong> Portfreigabe.<\/li>\n<\/ul>\n<p><strong>Gateway<\/strong><\/p>\n<ul>\n<li>Einen weiteren Raspberry Pi &#8211; oder einen (Linux) Rechner als Gateway, auf dem SSH l\u00e4uft. Die Gatewayfunktion \u00fcbernimmt der Pi nur so nebenbei, darauf k\u00f6nnen problemlos noch zus\u00e4tzlich und gleichzeitig ein OwnCloud und ein WordPress Server laufen. Der Pi ist ideal f\u00fcr diese Aufgabe, kostet wenig und braucht nur wenig Energie, kann also 7\/24 in Betrieb sein. Ob der Pi einen Monitor hat oder headless betrieben wird, ist egal. Wichtig ist nur, dass dieser Raspberry Pi aus dem Internet erreichbar ist.<\/li>\n<li>Router am Gateway Pi mit Port Freischaltung f\u00fcr den SSH Port Nummer 22 &#8211; oder besser einen alternativ konfigurierten Port z.B. Port 2000. Ggf. kommen noch weitere Portfreigaben hinzu. Wie man einen alternativen SSH Port einstellt, ist in <a title=\"SSH Portadresse \u00e4ndern\" href=\"http:\/\/www.rustimation.eu\/wordpress\/?p=41\">diesem Post<\/a> hier beschrieben. Dort auch die M\u00f6glichkeiten einer Absicherung zu Gem\u00fcte f\u00fchren. Durch die Portfreischaltung hat eure Firewall ein Loch bekommen und euer Netz ist somit angreifbar.<\/li>\n<li>Dynamische IP Adresse sollte unbedingt vorliegen, sonst macht's keinen Spa\u00df.<br \/>\nDann noch den Router so konfigurieren, dass er seine aktuelle IP Adresse an den DynDNS Provider meldet.<\/li>\n<li>Nachdem der Router am Gateway Pi konfiguriert ist, muss man am Gateway Pi\u00a0 initial nur die SSH Konfiguration einstellen.\u00a0 Du k\u00f6nntest anschlie\u00dfend zu deinem Remote Pi in den Urlaub fahren und alles Weitere dort konfigurieren. Idealerweise hat man beide Pis nat\u00fcrlich zuhause, konfiguriert und testet dort alles und f\u00e4hrt <strong>dann<\/strong> mit dem Remote Pi in Urlaub.<\/li>\n<\/ul>\n<h3>Wie funktioniert das \u00fcberhaupt?<\/h3>\n<p>Vereinfacht ausgedr\u00fcckt, baut der Remote Pi selbst\u00e4ndig eine Verbindung zu einem anderen Rechner (Gateway) auf. Diese Verbindung (der Tunnel) wird aufrecht gehalten. Das Gateway kann nun selbst \u00fcber den Tunnel mit dem Remote Pi Kontakt aufnehmen, oder ein dritter Rechner (z.B. Putty auf einem Windows PC) greift via Gateway Pi und Tunnel auf den Remote Pi zu.<\/p>\n<p>Ein Reverse SSH Tunnel macht \u00fcberall dort Sinn, wo man wegen eines Firewalls, Network Address Translation oder sonstiger Hemmnisse nicht von au\u00dfen auf einen Rechner zugreifen kann. Der Tunnel funktioniert, solange der Remote Rechner \u00fcber das Netzwerk, mit dem er verbunden ist, ins Internet kommt. Ob mit WiFi, Kabel oder Mobilfunk ist v\u00f6llig egal. Es versteht sich von selbst, dass das hier beschriebenen Verfahren nur dort verwendet werden darf, wo auch die Erlaubnis daf\u00fcr besteht. Also z.B. im eigenen Netzwerk bzw. im Auftrag eines Kunden in dessen Netzwerk. Die Verwendung des Reverse SSH Tunnels als illegale oder halblegale Hintert\u00fcr z.B. ins Netzwerk des eigenen Arbeitgebers wird fr\u00fcher oder sp\u00e4ter entdeckt werden und hat in der Regel arbeits- bzw. strafrechtliche Konsequenzen.<\/p>\n<h3>Schritt 1a: SSH Konfiguration auf dem Gateway Pi<\/h3>\n<p>Um sp\u00e4ter f\u00fcr unterschiedliche Anwendungsf\u00e4lle gewappnet zu sein, sollten folgende Einstellungen am <em>Gateway<\/em> <em>Pi<\/em> vorgenommen werden:<\/p>\n<p style=\"padding-left: 30px;\"><span style=\"color: #808080;\">In fr\u00fcheren Versionen der Anleitung fehlten diese Hinweise auf die Gateway Konfiguration. W\u00e4hrend meiner vielen vergeblichen Versuche, so ein Reverse Tunnel hinzubekommen, hatte ich diese Eintr\u00e4ge wohl einmal vorgenommen und dann vergessen, dass ich sie hatte&#8230; Danke an Hannes f\u00fcr die ensprechende Fehlermeldung und f\u00fcrs Finden der L\u00f6sung! (siehe Kommentare)<\/span><\/p>\n<p>Editiert die Datei \/etc\/ssh\/sshd_config als root &#8211; z.B. mit dem eingebauten Editor nano:<\/p>\n<pre class=\"lang:sh decode:true\">sudo nano \/etc\/ssh\/sshd_config<\/pre>\n<p>dort dann am besten folgende Eintr\u00e4ge suchen und ab\u00e4ndern bzw. die Eintr\u00e4ge am Ende vornehmen:<\/p>\n<pre class=\"lang:sh decode:true\">ClientAliveInterval 30\r\nClientAliveCountMax 99999\r\nGatewayPorts yes\r\nAllowTcpForwarding yes<\/pre>\n<p>Mit den ersten beiden Zeilen wird sichergestellt, dass die Verbindung nicht einfach wieder abgebaut wird, wenn eine Zeitlang keine Daten \u00fcber die Leitung flutschen.<\/p>\n<p><code>GatewayPorts yes<\/code> erlaubt es, das Gateway quasi als \"Durchlauferhitzer\" zu nutzen, d.h. von einem anderen Ger\u00e4t \u00fcber den Gateway Pi in der Mitte auf den Remote Pi zuzugreifen.<br \/>\n<code><br \/>\nAllowTcpForwarding yes<\/code> erlaubt es, auch andere Protokolle &#8211; z.B. http &#8211;\u00a0 im SSH Tunnel zu verpacken.<\/p>\n<p>Sind die \u00c4nderungen eingetragen, nano mit Strg-X beenden, bei der Frage, ob die ge\u00e4nderte Datei gespeichert werden soll, mit \"J\" antworten und anschlie\u00dfend die Eingabetaste dr\u00fccken. Anschlie\u00dfend neu booten.<\/p>\n<h3>Schritt 1b: Aufbau SSH Tunnel auf dem Remote Pi<\/h3>\n<p>Am Remote Pi geben wir folgenden Befehl ein:<\/p>\n<pre class=\"lang:sh decode:true\">ssh -p2000 -fNC -R 10011:localhost:22 pi@dyn.IP.adresse<\/pre>\n<p><strong>Erl\u00e4uterung der Parameter:<\/strong><br \/>\n&#8211;<strong>p2000<\/strong> (optional) abweichender Port des <span style=\"text-decoration: underline;\">Gateway<\/span> Pi \u00fcber den der <span style=\"text-decoration: underline;\">Remote<\/span> Pi den Tunnel aufbaut. Kann auch weggelassen werden dann wird automatisch die Portadresse 22 genommen. In jedem Fall muss die gew\u00e4hlte Portnummer im Router des Gateway Pi freigeschaltet werden. Wie man das anstellt, habe ich im Artikel\u00a0<a title=\"Dynamische IP Adresse mit Bordmitteln\" href=\"https:\/\/www.rustimation.eu\/index.php\/dynamische-ip-mit-bordmitteln\/#Portfreischaltung_Beispiel_FritzBox\" target=\"_blank\" rel=\"noopener noreferrer\">Dynamische IP Adresse mit Bordmitteln<\/a> im Kapitel<em> Portfreischaltung (Beispiel Fritz!Box)<\/em> beschrieben.<br \/>\n<strong>-f<\/strong> bedeutet, dass ssh im Hintergrund laufen soll. Anschlie\u00dfend kann das Terminalfenster wieder geschlossen werden, SSH l\u00e4uft aber im Hintergrund weiter.<br \/>\n<strong>N<\/strong> bedeutet, dass lediglich der Tunnel aufgebaut wird, aber keine Remote-Kommandos entgegen genommen werden.<br \/>\n<strong>C <\/strong>(optional) komprimiert die \u00fcber die Strecke laufenden Daten. Achtung, dieser Parameter verschlechtert unter Umst\u00e4nden die Performance &#8211; also ausprobieren.<br \/>\n<strong>-R<\/strong> besagt, dass ein Reverse Tunnel aufgebaut werden soll.<br \/>\n<strong>10011<\/strong> ist der Ausgangsport (outgoing port address) des <span style=\"text-decoration: underline;\">Gateway<\/span> Pi. Startet man dort eine SSH Sitzung \u00fcber den Port 10011, kommt man beim <span style=\"text-decoration: underline;\">Remote<\/span> Pi raus. Im Prinzip kannst du jede Portadresse \u00fcber 1024 verwenden, die nicht schon von deinem Pi belegt ist. Eine Liste der standardisierten Ports findest du z.B. <a href=\"https:\/\/de.wikipedia.org\/wiki\/Liste_der_standardisierten_Ports\" target=\"_blank\" rel=\"noopener\">bei Wikipedia<\/a><a href=\"https:\/\/de.wikipedia.org\/wiki\/Liste_der_standardisierten_Ports#Dynamische_Port-Bereiche_(49152%E2%80%9365535)\">.<\/a><br \/>\n<strong>localhost<\/strong> ist der Name unter dem ein Rechner sich selbst erkennt; also ein \"ich\" oder ein \"bei mir\".<br \/>\nFalls ihr \u00fcber den Tunnel, der beim Remote Pi ankommt, weitere Ger\u00e4te im Remote Netzwerk ansprechen wollt, dann kann statt localhost auch die lokale IP Adresse eines Remote Netzwerkger\u00e4ts stehen. Siehe weiter unten bei \"<a href=\"https:\/\/www.rustimation.eu\/index.php\/reverse-ssh-tunnel-schritt-fur-schritt\/#Externe_Geraete_ansprechen\">externe Ger\u00e4te ansprechen<\/a>\".<br \/>\n<strong>22<\/strong> ist die Standard SSH Portnummer des <span style=\"text-decoration: underline;\">Remote<\/span> Pi.<br \/>\n<strong>pi@dyn.IP.adresse<\/strong> ist der User- und Servername der auf dem Gateway Pi verwendet wird &#8211; dyn.IP.adresse ist die Adresse (URL) des Gateway Pi \u00fcber den man auf den Remote Pi zugreifen will. Bitte entsprechend deine dynamische IP Adresse eintragen. Anstatt \"Pi\" kannst du nat\u00fcrlich auch jeden anderen User verwenden, der auf dem Gateway Pi angelegt ist.<\/p>\n<p style=\"padding-left: 30px;\"><span style=\"color: #808080;\">Im deutschen Raspberry Pi Forum kam im Dezember 2017 eine interessante <a href=\"https:\/\/forum-raspberrypi.de\/forum\/thread\/37356-fernwartung-ssh-vpn\" target=\"_blank\" rel=\"noopener noreferrer\">Diskussion<\/a> auf &#8211; es drehte sich u.a. um die Frage, welchen User man in das obige Kommando eintr\u00e4gt. Ich habe der Einfachheit halber den User \"pi\" genommen, da der ja sowieso schon auf dem Raspberry Pi vorhanden ist. Nat\u00fcrlich kann hier jeder beliebige Nutzer genommen werden. Wichtig ist nur, dass dieser User auf dem Gateway angelegt wurde &#8211; also ein Konto hat.<\/span><\/p>\n<p><strong>Erster Test:<\/strong><br \/>\nProbiers mal aus, d.h. gebe oben stehendes Kommando am Remote Pi ein. Wenn alles stimmt, wirst du zus\u00e4tzlich noch das Passwort des Users Pi vom Gateway Pi eingeben m\u00fcssen.<\/p>\n<p><span style=\"color: #808080;\"><strong>Hinweis<\/strong>: sollte das nicht funktionieren, kann es sein, dass der Remote Pi den SSH Key vom Gateway noch nicht kennt. In diesem Falle am Remote Pi einfach <\/span><\/p>\n<pre class=\"lang:default decode:1 inline:1 \">ssh pi@dyn.IP.adresse<\/pre>\n<p>bzw.<\/p>\n<pre class=\"lang:default decode:1 inline:1 \">ssh -p2000 pi@dyn.IP.Adresse<\/pre>\n<p>eingeben und die Abfrage mit <em>yes<\/em> best\u00e4tigen.<\/p>\n<p>Auf dem <strong>Gateway <\/strong>Pi kann man sich nun mit dem Befehl<\/p>\n<pre class=\"lang:sh decode:true\">ssh -p 10011 localhost<\/pre>\n<p>auf dem Remote Pi einloggen. Das kann man \u00fcbrigens auch tun, wenn man nicht vor Ort ist. Dazu einfach auf dem Gateway Pi mit Putty einloggen &#8211; anstatt der IP Nummer aus dem Heimnetz, die dyn.IP.Adresse in das Adressfeld eingeben und ggf. noch eine abweichende Portnummer eintragen. Das geht nat\u00fcrlich nur, wenn der entsprechende SSH Port im Router zuhause auch freigeschaltet ist. Ihr kommt dann beim Gateway Pi raus und k\u00f6nnt dort den obigen Befehl eingeben.<\/p>\n<p style=\"padding-left: 30px;\"><span style=\"color: #808080;\">Hier k\u00f6nnte man fragen, warum man da localhost nimmt und nicht die IP Adresse des Gateway Pi. Theoretisch ginge das, allerdings hat das den Nachteil, dass die Verbindung erst nach drau\u00dfen zum Router oder Switch im lokalen Netzwerk aufgebaut wird und dann wieder zur\u00fcck zum Gateway geleitet wird. Das ist umst\u00e4ndlich und verlangsamt die Geschichte. Au\u00dferdem kann es ja sein, dass die IP Adresse neu vergeben wird &#8211; dann f\u00fchrt die angegebene IP ins Leere. Bei Verwendung von \"localhost\" wei\u00df der Pi, dass er das alles lokal bei sich \"zu Hause\" abwickeln kann.<\/span><\/p>\n<p>Perfekt? Nein, nicht ganz: Das Eingeben des Gateway Passworts beim Aufbau des Tunnels nervt und f\u00fchrt dazu dass der Tunnel nur mit Nutzereingriff d.h. manuell aufgebaut werden kann. Und wir wollen ja eine automatische L\u00f6ung. Deshalb&#8230;<\/p>\n<h3>Schritt 2a: Login ohne Passwort<\/h3>\n<p>Neben der Passworteingabe zum Login kann man einem entfernten Rechner auch seine \"Ausweisdaten\" d.h. einen RSA Key \u00fcbermitteln, anhand dessen dann der anrufende Rechner erkannt und akzeptiert wird. Auf unseren Fall \u00fcbertragen hei\u00dft das, wir m\u00fcssen den \u00f6ffentlichen RSA Key des Remote Pi auf den Gateway Pi \u00fcbertragen.<br \/>\nDazu erst einmal auf dem Remote Pi nachschauen, ob im Verzeichnis \/home\/pi\/.ssh (oder auch ~\/.ssh) bereits eine Datei id_rsa.pub existiert. Wenn nein, muss man den Schl\u00fcssel erst erzeugen:<br \/>\nDas geschieht mit<\/p>\n<pre class=\"lang:sh decode:true\">ssh-keygen<\/pre>\n<p>Nach Belieben die vom Programm abgefragten Daten eingeben, die Passphrase aber leer lassen, wir wollen uns ja automatisch mit dem Gateway verbinden.<br \/>\nNun muss man den erzeugten Schl\u00fcssel (RSA 2048 Bit) auf das Gateway kopieren. Dazu folgenden Befehl am Remote Pi eingeben:<\/p>\n<pre class=\"\">ssh-copy-id -i ~\/.ssh\/id_rsa.pub dyn.IP.adresse<\/pre>\n<p>Hat man auf dem Gateway Pi eine andere SSH Portadresse (z.B. 2000) eingerichtet, lautet der Befehl wie folgt:<\/p>\n<pre class=\"lang:sh decode:true\">ssh-copy-id -i ~\/.ssh\/id_rsa.pub -p 2000 pi@dyn.IP.adresse<\/pre>\n<p style=\"padding-left: 40px;\"><span style=\"color: #808080;\">Bei sehr alten Versionen von Raspbian (vor Jessie) musste <span class=\"lang:python decode:true crayon-inline\">-p 2000 pi@dyn.IP.adresse<\/span>\u00a0 in Anf\u00fchrungszeichen gefasst sein.<br \/>\n<\/span><\/p>\n<p>Testen kannst du das auf dieselbe Weise wie oben.<\/p>\n<p><strong>Klappt das nicht, bitte die Hinweise in <a href=\"https:\/\/www.rustimation.eu\/index.php\/reverse-ssh-tunnel-schritt-fur-schritt\/#Schritt_2b_Problem_bei_public-key_authorization\">Kapitel 2b<\/a> beachten<\/strong>!<\/p>\n<p style=\"padding-left: 40px;\"><span style=\"color: #808080;\">Sollte das Kopieren der ID mit einem Berechtigungsfehler scheitern, musst du dich mit SSH vom Remote aus einmal beim Gateway einloggen. Damit kennt der Remote das Gateway und akzeptiert auch den Copy Befehl.<\/span><\/p>\n<p style=\"padding-left: 40px;\"><span style=\"color: #808080;\"><span style=\"color: #ff0000;\"><strong>Wichtig<\/strong>:<\/span><br \/>\n<span style=\"color: #ff0000;\">Hat der User Pi den Schl\u00fcssel erzeugt, muss der User Pi auch den Tunnel<\/span><br \/>\n<span style=\"color: #ff0000;\">starten. Wenn du nachher (Schritt 4) die Crontab zum automatischen Start nach Reboot verwendest, dann muss es die Crontab vom User Pi sein. Diese erzeugst\/editierst du indem du dich als \"pi\" enloggst und dann <code>crontab -e<\/code> eingibst.<\/span><br \/>\n<span style=\"color: #ff0000;\"><strong>Merke<\/strong>: Au\u00dfer f\u00fcr Schritt 1a brauchst du den superuser sudo nicht!! Alle Eingaben erfolgen als User Pi bzw. mit dem User, den du f\u00fcr deinen Tunnel verwenden willst.<\/span><br \/>\n<\/span><\/p>\n<p style=\"padding-left: 40px;\"><span style=\"color: #808080;\"><strong>F\u00fcr Spezialisten:<\/strong> Wollt ihr irgendwann sp\u00e4ter ein neues\/anderes Gateway installieren, z.B. wg. HW-Tausch, dann k\u00f6nnt ihr das auch ohne Zugriff auf den Remote Pi durchf\u00fchren. Dazu die Dateien in ~\/.ssh an dieselbe Stelle des neuen Rechners kopieren \u2013 damit erkennt das Gateway den Remote Pi. Au\u00dferdem noch alle Dateien in \/etc\/ssh auch in das Verzeichnis \/etc\/ssh des neuen Gateways \u2013 damit erkennt der Remote Pi das Gateway als alten Bekannten. Dabei beachten, dass die Permissions und Besitzer mitkopiert bzw. hinterher entsprechend auf identische Werte umgestellt werden m\u00fcssen.<\/span><\/p>\n<h3>Schritt 2b: Problem bei public-key authorization<\/h3>\n<p>Wer sich auf seinem GatewayPi mit Passwort einloggt, kann den Rest des Kapitels vorerst \u00fcberspringen.<\/p>\n<p>Login mit Passwort ist out. Zu unsicher und auch unkomfortabel. Beim Erzeugen der SD Karte mit dem Raspberry Pi Imager wird einem deshalb das public-key Loginverfahren ohne Passwort f\u00f6rmlich aufgedr\u00e4ngt.<\/p>\n<p>Aber: ist der Gateway Pi ausschlie\u00dflich mit \u00f6ffentlichem Schl\u00fcssel zug\u00e4nglich (anstatt mit Passwort), kommt es zu Problemen mit <em>ssh-copy-id<\/em>. Das Gateway verh\u00e4lt sich wie eine Einwanderungsbeh\u00f6rde und verlangt nach einem in <em>authorized_keys<\/em> hinterlegten \"Visum\"namens <em>rsa_id.pub,\u00a0<\/em>aber das ist gar nicht so einfach.<\/p>\n<p>Ist das Gateway ferner mit <em>fail2ban<\/em> abgesichert (absolut empfohlen), wird der Remote Client nach ein paar Login Fehlversuchen mit Passwort\u00a0 anstatt Schl\u00fcssel komplett ausgesperrt. Ein praktisches Skript zum Entsperren findest du hier:<\/p>\n<pre class=\"height-set:true height:24 lang:sh decode:true \">#!\/bin\/bash\r\n#!\/bin\/bash\r\n# Filename: validate_ip.sh\r\n\r\nvalidate_ip() {\r\n    local ip=$1\r\n    local stat=1\r\n\r\n    if [[ $ip =~ ^[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}$ ]]; then\r\n        OIFS=$IFS\r\n        IFS='.'\r\n        ip=($ip)\r\n        IFS=$OIFS\r\n        [[ ${ip[0]} -le 255 &amp;&amp; ${ip[1]} -le 255 &amp;&amp; ${ip[2]} -le 255 &amp;&amp; ${ip[3]} -le 255 ]]\r\n        stat=$?\r\n    fi\r\n\r\n    return $stat\r\n}\r\n\r\n\r\n################################################################\r\n#check for sudo\r\nif [ \"$USER\" != \"root\" ]\r\nthen\r\n    echo \"Aufruf als Superuser mit sudo!!\"\r\n    exit 2\r\nfi\r\n\r\n#get public IP of server - remove this section in case no server present \r\nserv=`host myserver.com`\r\nmyeyepee=${serv#*address}\r\n################### End section\r\n\r\n# manual input of external IP  to be unblocked\r\necho -n \"Enter IPv4 address of external client (e.g. rustimation.eu) or leave empty to unban only server's own ext. IP aAddress: \"\r\nread eyepee\r\n\r\n# check whether IP was given\r\nif [ $# -eq 1 ]; then\r\n   #IP was given now format check\r\n   if validate_ip $eyepee; then\r\n       #unban external IP\r\n       echo \"${ip_address} is a valid IPv4 address.\"\r\n       echo unbanning $eyepee\r\n       fail2ban-client set apache-auth unbanip $eyepee\r\n       fail2ban-client set apache-fakegooglebot unbanip $eyepee\r\n       fail2ban-client set sshd unbanip $eyepee\r\n       cat \/var\/log\/fail2ban.log|grep $eyepee\r\n   else\r\n      echo \"${ip_address} is a invalid IPv4 address.\"\r\n      exit 2\r\n   fi\r\nfi\r\n#unban jails fo myIP\r\nfail2ban-client set apache-auth unbanip $myeyepee\r\nfail2ban-client set apache-fakegooglebot unbanip $myeyepee\r\nfail2ban-client set sshd unbanip $myeyepee\r\ncat \/var\/log\/fail2ban.log|grep $myeyepee\r\n\r\n# updating ignoreip in fail2ban's jail.local\r\nignoreline=`cat \/etc\/fail2ban\/jail.local|grep \"ignoreip =\"`\r\necho \"Telling fail2ban to ignore IP adress:\" $myeyepee $eyepee\r\nsed -i \"s\/$ignoreline\/ignoreip = $myeyepee $eyepee\/\" \/etc\/fail2ban\/jail.local\r\n#Restart fail2ban with updated ignoreip\r\nservice fail2ban restart\r\n\r\n###testing\r\necho \"ignoreip line now looks like this:\"\r\ncat \/etc\/fail2ban\/jail.local|grep \"ignoreip =\"\r\n<\/pre>\n<p>&nbsp;<\/p>\n<ol>\n<li>Alternative (nicht empfohlen) &#8211; Zulassen von Login mit Passwort:<br \/>\nEditieren von der SSH Konfiguration: <span class=\"lang:default decode:true crayon-inline \">sudo nano \/etc\/ssh\/sshd_config<\/span>\u00a0 und dann suchen nach <span class=\"lang:default decode:true crayon-inline\">PasswordAuthentication no<\/span>\u00a0 und diese auf \"yes\" stellen.<br \/>\nDa \u00f6ffentlich erreichbare Server laufend angegriffen werden und SSH ein beliebtes Einfallstor ist, sollte diese Methode nur verwendet werden, wenn ein komplexes Login Passwort vergeben wurde. Ist der Schl\u00fcssel \u00fcbertragen, den Parameter wieder aud \"no\" setzen.<\/li>\n<li>Alternative &#8211; direktes Kopieren des \u00f6ffentlichen Schl\u00fcssels via Command Line Interface (CLI):<br \/>\n&#8211; beim Remote Client die Datei <span class=\"lang:default decode:true crayon-inline\">~\/.ssh\/id_rsa.pub<\/span>\u00a0 kopieren (mit <span class=\"lang:default decode:true crayon-inline\">cat rsa_id.pub<\/span> anzeigen und mit der Maus alles markieren).<br \/>\n&#8211; am Gateway die Datei\u00a0<span class=\"lang:default decode:true crayon-inline \">\/ssh\/authorized_keys<\/span>\u00a0 editieren bzw. neu generieren und den kopierten Schl\u00fcssel mit einem Rechtsklick am unteren Ende einf\u00fcgen.<br \/>\nDie Datei id_rsa.pub erstreckt sich \u00fcber mehrere Zeilen und sieht ungef\u00e4hr so aus:<\/p>\n<pre class=\"height-set:true lang:default decode:true\">ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCh5\/BjTivwGvrlRgZKLrIHINpk7555ESqIpYMML6dCMD\r\noiX6o8qW5cKjhgVuN32ZOyu\/F313yESzQPC4+3INOf5qsq6od3HcBWZZjB2xJEtkFzoAYgpufqUsk4g5pL\r\nuy0M\/5WEJTRMPScw8ZMlXOr1f3KcSQNo97nvSZNohT4Poz+rrMnshpKvC\/TEm71UDVrEQIyZ\r\nUSAaufDemWegLEhin2n3sden+2lfa$schi$musL\/QLFCKTRMP!Ax89\/I51GoG3genreaktiontLqi\r\n2Y8iuXPAB9Y7c4OPJvl0p1AJwNo8U5rDZD7OIDRfK8oSWTF?AnmZSMCGuD48i7X9nyp5vlam2Fn69P\r\nmv5rZurnC96qdvlbBQz3pecw03QmhQVkGNLwPck777Guc9PoHs8oO8nR6Jyvjr1234rWHhbnIYn1DzmH8\r\n4NesFR1Zt+mZes2uOm378r333IueagvNEa3Eg0K0IaM\/L5vWKK999999KBdha1oS4NJVS\/QJtqfehUSut\r\nx4l49k= pi@MeinRaspi<\/pre>\n<p>Mit <span class=\"lang:default decode:true crayon-inline\">sudo service sshd restart<\/span>\u00a0 oder einem reboot aktualisieren und der Remote Client kann sich jetzt ohne Passwort beim Gateway einloggen.<\/li>\n<\/ol>\n<p>Gut, aber immer noch nicht perfekt!<\/p>\n<h3>Schritt 3: Stabilisieren<\/h3>\n<p>Gerade wenn der Remote Pi \u00fcber Mobilfunk im Internet h\u00e4ngt, kann es vorkommen, dass die Verbindung hin und wieder kurz unterbrochen wird. (Das passiert \u00fcbrigens auch bei den meisten DSL Providern. Irgendwann nachts setzt der Provider die Verbindung zur\u00fcck.) In diesem Falle bricht der Tunnel ger\u00e4uschlos aber unerbittlich zusammen. Man k\u00f6nnte jetzt ein Skript schreiben, das die Verbindung laufend \u00fcberpr\u00fcft und bei Bedarf neu aufbaut. Das ist zum Gl\u00fcck \u00fcberfl\u00fcssig, denn es gibt mit <code>autossh <\/code>eine Erweiterung (eigentlich einen Wrapper) f\u00fcr SSH. Einfach <code>autossh <\/code>anstatt <code>ssh <\/code>verwenden und schon haben wir ein stabiles System. Perfekt? Leider immer noch nicht, denn <code>autossh <\/code>hilft nichts, wenn der Remote Pi z.B. wegen eines Stromausfalls neu startet.<\/p>\n<p>M\u00f6glicherweise ist <code>autossh <\/code>noch nicht auf dem Pi installiert. Dem kann man ganz einfach mit<\/p>\n<pre class=\"lang:sh decode:1 inline:1\">sudo apt install autossh<\/pre>\n<p>abhelfen.<\/p>\n<h3>Schritt 4: Autostart<\/h3>\n<p>Wir erstellen ein Script mit Namen <strong>tunnel.sh<\/strong>, in das wir den Reverse SSH Tunnel Befehl eintragen:<\/p>\n<pre class=\"lang:sh decode:true\">#!\/bin\/bash\r\n\/usr\/bin\/autossh -p2000 -fNC -R 10011:localhost:22 pi@dyn.IP.adresse<\/pre>\n<p>Dieses Script legen wir im Homeverzeichnis ab. Mit<\/p>\n<pre class=\"lang:sh decode:true\">chmod +x tunnel.sh<\/pre>\n<p>machen wir es ausf\u00fchrbar.<\/p>\n<p>Alles was automatisch beim Start oder in regelm\u00e4\u00dfigen Abst\u00e4nden laufen soll, wird per Crontab aufgerufen. Dazu folgender Befehl:<\/p>\n<pre class=\"lang:sh decode:true\">crontab -e<\/pre>\n<p>Es erscheint die Crontab im Editor &#8211; ganz nach unten scrollen und folgende Zeile eingeben<\/p>\n<pre class=\"lang:sh decode:true\">@reboot \/home\/pi\/tunnel.sh<\/pre>\n<p>mit Strg+X speichern wir die Crontab und verlassen den Editor.<\/p>\n<p style=\"padding-left: 30px;\"><span style=\"color: #808080;\">In einer fr\u00fcheren Version dieser Anleitung hatte ich die Crontab als Superuser mit<code> sudo crontab -e <\/code>editiert. Das hatte zur Folge, dass der Tunnel beim Start vom Superuser bzw. Root und nicht vom User Pi aufgebaut wurde. Wenn nun der Root seine ID noch nicht im Gateway Pi hinterlegt hat, dann baut sich der Tunnel nicht auf, da der passwortlose Login nicht funktioniert; es sei denn, du hast vorher den Schl\u00fcssel mit \"sudo ssh-keygen\" erzeugt und mit \"sudo ssh-copy-id\" \u00fcbertragen. Dieses Problem ist bei mir lange nicht aufgefallen, da ich wohl bei Basteleien irgendwann vorher die ID vom Root des Remote Pi auf den Gateway Pi kopiert hatte.<br \/>\n<\/span><\/p>\n<p>So! jetzt ist es ann\u00e4hernd perfekt. Der SSH Tunnel startet nach jedem Reboot und ist nun komplett, stabil und betriebssicher. Bitte beachtet, dass der Tunnel unter Umst\u00e4nden nicht sofort nach dem Reboot steht, sondern einige Minuten braucht, um die Verbindung zum Gateway herzustellen. Ich vermute, dass die WLAN Verbindung noch nicht sauber steht, wenn das <code>autossh <\/code>Kommando das erste mal abgearbeitet wird. Mit <code>autossh <\/code>stellen wir aber sicher, dass die Verbindung anschlie\u00dfend automatisch hergestellt wird.<\/p>\n<p>Ich habe allerdings festgestellt, dass sich der Gateway Pi hin und wieder, d.h. alle paar Wochen, zu verabschieden schien. Das lag aber dann meist daran, dass meine Fritz!Box ihren Aufgaben nicht vollst\u00e4ndig nachkam und die Portweiterleitung bestreikte. Nach einem Reboot der Fritz!Box (auch per Fernzugriff m\u00f6glich) gings dann wieder.<\/p>\n<p><strong>Nochwas zum Anwendungsfall Remote per Mobilfunk<\/strong>: Auch der Router am Remote Pi scheint manchmal seine Probleme zu haben. Unter Umst\u00e4nden ist das Mobilfunknetz so stark \u00fcberlastet, dass der Router, bzw. der Internet Stick daran sich einfach nicht verbinden will. Nach zu vielen Fehlversuchen streikt der Router dann &#8211; zumindest der von mir verwendete TP-Link Mobilfunk Router TL-MR3420. Dann hilft nur ein physikalischer Reset des Routers. Auch daf\u00fcr gibts eine L\u00f6sung mittels Fernschalt-Steckdosen und 433MHz Sender am Pi. Dazu habe ich einen eigenen <a title=\"H\u00e4ngenden Router automatisch rebooten\" href=\"http:\/\/www.rustimation.eu\/index.php\/haengenden-router-automatisch-rebooten\/\">Artikel <\/a>geschrieben.<br \/>\nIch empfehle inzwischen eher eine Fritz!Box f\u00fcr Mobilfunk.<\/p>\n<h3>Schritt 5: Browsen im Tunnel<\/h3>\n<p>Bisher haben wir lediglich reines SSH Protokoll durch den Tunnel geschickt. Unser Remote Pi kann ja auch als Webserver laufen, z.B. um Temperaturen vor Ort anzuzeigen oder Bilder einer Webcam. Damit wir auch http d.h. Browserdaten durchs Tunnel schicken k\u00f6nnen, passen wir unser Skript bzw. den Befehl darin wie folgt an:<\/p>\n<pre class=\"lang:sh decode:true\">\/usr\/bin\/autossh -p2000 -fNC -R 8000:localhost:80 -R 10011:localhost:22 pi@dyn.IP.adresse<\/pre>\n<p>8000 ist die Portnummer mit der die http Daten vom Gateway zum Remote Pi umgelenkt werden.<br \/>\n80 ist der Standardport f\u00fcr http. Schickt man beim Gateway etwas an Port 8000, kommt es beim Remote Pi an Port 80 wieder an. Und 80 ist der Port, mit dem der Webserver normalerweise kommuniziert.<br \/>\nWill man nur aus dem eigenen lokalen Netzwerk auf den Remote Pi zugreifen, gibt man in den Browser die IP Adresse des Gateway Pi ein, gefolgt von einem Doppelpunkt und der Ausgangsportnummer f\u00fcr http. Also zum Beispiel:<\/p>\n<pre class=\"lang:sh decode:true\">http:\/\/192.168.178.40:8000<\/pre>\n<p><span style=\"color: #808080;\">Damit das funktioniert, braucht man logischerweise einen installierten Webserver auf dem Pi &#8211; z.B.\u00a0 Apache oder Lighttpd.<\/span><\/p>\n<p style=\"padding-left: 40px;\"><span style=\"color: #ff0000;\">Im Zuge des allgemeinen Trends, den User f\u00fcr unm\u00fcdig zu halten, hat Firefox sp\u00e4testens ab Version 75 geruht,\u00a0 den Zugriff auf http Seiten (also ohne SSL Verschl\u00fcsselung) zu erschweren. Will man \"von au\u00dfen\" mit Firefox f\u00fcr Windows \u00fcber Router Portfreischaltung und das Gateway einen auf dem Remote gehosteten Webserver erreichen, (sinngem\u00e4\u00df <em>http:\/\/deine Website.net:7555<\/em>) kann es passieren, dass die Remote Website nicht funktioniert. Das passiert dann, wenn man unter <em>deineWebsite.net<\/em> auch noch eine SSL verschl\u00fcsselte Website (z.B. auf dem Gateway) betreibt.<\/span><br \/>\n<span style=\"color: #ff0000;\">Abhilfe geht wie folgt: Im Firefox Profilordner die Datei<\/span><\/p>\n<p><span class=\"lang:python decode:true crayon-inline \">sitesecurityservicestate.txt<\/span><\/p>\n<p style=\"padding-left: 40px;\"><span style=\"color: #ff0000;\">editieren und die Zeile, welche <em>deineWebsite.net <\/em>enth\u00e4lt, rausl\u00f6schen. Dummerweise wird Firefox beim n\u00e4chsten Zugriff auf die SSL verschl\u00fcsselte Seite diesen Eintrag wiederherstellen. Falls das zu sehr nervt,<\/span><\/p>\n<p style=\"padding-left: 40px;\"><span class=\"lang:python decode:true crayon-inline \">sitesecurityservicestate.txt<\/span><\/p>\n<p style=\"padding-left: 40px;\"><span style=\"color: #ff0000;\">als Readonly einstellen (Rechtsklick auf Dateinamen &#8211; Eigenschaften &#8211; schreibgesch\u00fctzt).\u00a0 Wie man das mit FF f\u00fcr iOS hinbekommt, habe ich noch nicht herausgefunden.<\/span><\/p>\n<p style=\"padding-left: 40px;\"><span style=\"color: #ff0000;\">Firefox hat noch ein paar andere Schweinereien auf Lager, die k\u00fcnftig https erzwingen und unverschl\u00fcsselte Seiten ins Abseits stellen. Infos hierzu z.B. bei <a style=\"color: #ff0000;\" href=\"https:\/\/www.heise.de\/newsticker\/meldung\/HTTPS-Only-Firefox-erzwingt-verschluesselte-Verbindungen-4690550.html\" target=\"_blank\" rel=\"noopener noreferrer\"><span style=\"color: #800080;\">Heise.de<\/span><\/a><\/span><\/p>\n<h3>Mehrere Tunnel<\/h3>\n<p>Nat\u00fcrlich k\u00f6nnen wir auch mehrere Tunnel aufbauen. Entweder durch Starten eines weiteren Tunnelskripts oder durch Anh\u00e4ngen des Umleitungstupels an den autossh Befehl:<\/p>\n<pre class=\"lang:default decode:true\" title=\"Mehrere Tunnel mit einem Befehl\">autossh -p2000 -fNC -R 20000:192.168.4.12:80 -R 20002:192.168.4.13:80 -R 20004:192.168.4.14:80 -R 20006:192.168.4.11:80 pi@rustimation.eu\r\n# 20000 Solar Wechselrichter\r\n# 20002 EinspeiseInverter\r\n# 20004 Battery\r\n# 20006 Batterielader\r\n<\/pre>\n<p>Es hat sich bew\u00e4hrt, eine kurze Legende zu den Zieladressen einzuf\u00fcgen &#8211; man kommt bei vielen Tunneln sonst leicht durcheinander.<\/p>\n<p>Ferner habe ich im Lauf der Jahre festgestellt, dass nicht jede, scheinbar freie Gateway-Portadresse sauber umleitet. Bei Gateway-Portfolgen wie z.B. 8001 &#8211; 8002 &#8211; 8003 &#8211; 8004 bekommt 8003 keinen Connect hin.\u00a0 Das passiert merkw\u00fcrdigerweise auch, wenn diese Portadresse eigentlich frei sein sollte. Keine Ahnung warum das so ist.<\/p>\n<p>Ich habe mir deshalb angew\u00f6hnt, mindestens eine Portnummer Abstand zwischen den einzelnen Gatewayports zu lassen. Siehe oben: 20000 &#8211; 20002 &#8211; 20004 &#8211; 20006.<\/p>\n<p>Damit habe ich dieses Problem aktuell nicht mehr.<\/p>\n<h3>Externe Ger\u00e4te ansprechen<\/h3>\n<p>Extern bedeutet in diesem Kontext andere Ger\u00e4te im Remote Netzwerk. Wenn ihr also eine IP Cam mit einem Browser \u00fcber den Tunnel ansprechen wollt, dann einfach anstatt <em>localhost<\/em> die IP Adresse des externen Ger\u00e4ts verwenden.<\/p>\n<p>Hat die Cam z.B. die lokale Adresse 192.168.178.120 dann wird das Tunnelskript von oben wie folgt erweitert:<\/p>\n<pre class=\"lang:default decode:true\">\/usr\/bin\/autossh -p2000 -fNC -R 8000:localhost:80 -R 10011:localhost:22 -R 8889:192.168.178.120:80 pi@dyn.IP.adresse<\/pre>\n<p>\u00fcber die Parameter <span style=\"color: #800000;\">-R 8889:192.168.178.120:80<span style=\"color: #000000;\"> wird alles was auf Port 8889 ankommt, auf den http Port 80 des externen Ger\u00e4ts, z.B. einer Cam umgeleitet.<br \/>\nAuf einem PC im Netz des Gateway Pi gebt ihr im Browser die IP des Gateway Pi ein, gefolgt von einem Doppelpunkt und dem Port 8889. Wenn alles klappt, kommt ihr bei der Remote Cam &#8211; oder was auch immer ihr ansprechen wollt\u00a0 &#8211; heraus. Ihr k\u00f6nnt\u00a0 auf diese Weise auch euren remoten Router ansprechen und administrieren.<\/span><\/span><\/p>\n<p>Herzlichen Dank an Reto Huber f\u00fcr diesen genialen Tipp!<\/p>\n<p>Mehr dar\u00fcber in einem eigenen <a href=\"https:\/\/www.rustimation.eu\/index.php\/reverse-ssh-tunnel-remote-router-administrieren\/\">Beitrag .<\/a><\/p>\n<h5>Zugriff von \"Au\u00dfen\"<\/h5>\n<p>Will man auch von \"au\u00dfen\", also au\u00dferhalb des Heimnetzwerks, auf eine beim Remote Pi gehostete Website zugreifen, muss man im Router des Heimnetzwerks zus\u00e4tzlich die Portadresse 8000 (oder was immer du gew\u00e4hlt hast) freischalten. Der Aufruf erfolgt dann so:<\/p>\n<pre class=\"lang:sh decode:true\">http:\/\/dyn.IP.Adresse:8000<\/pre>\n<p>Auch hier braucht ihr nat\u00fcrlich einen Webserver auf dem Remote Pi.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Ein Reverse SSH Tunnel ist immer dann hilfreich, wenn man auf einen Raspberry Pi, der hinter einer Firewall l\u00e4uft, zugreifen will und die Firewall nicht selbst f\u00fcr Zugriffe von au\u00dfen freischalten kann. Zum Beispiel, wenn der Pi per Mobilfunk mit dem Internet verbunden ist. Mobilfunkprovider lassen meist keine Zugriffe von au\u00dfen auf die im Netz &hellip; <a href=\"https:\/\/www.rustimation.eu\/index.php\/reverse-ssh-tunnel-schritt-fur-schritt\/\" class=\"more-link\"><span class=\"screen-reader-text\">Reverse SSH Tunnel &#8211; Schritt f\u00fcr Schritt<\/span> weiterlesen <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,7,10],"tags":[93,94,89,29,36,39,41,47,48],"class_list":["post-6","post","type-post","status-publish","format-standard","hentry","category-mobile","category-netzwerk","category-raspberry-pi","tag-ipv4","tag-ipv6","tag-lte","tag-mobilfunk","tag-raspberry-pi","tag-reverse-ssh","tag-router","tag-tunnel","tag-umts"],"_links":{"self":[{"href":"https:\/\/www.rustimation.eu\/index.php\/wp-json\/wp\/v2\/posts\/6","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rustimation.eu\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.rustimation.eu\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.rustimation.eu\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rustimation.eu\/index.php\/wp-json\/wp\/v2\/comments?post=6"}],"version-history":[{"count":1,"href":"https:\/\/www.rustimation.eu\/index.php\/wp-json\/wp\/v2\/posts\/6\/revisions"}],"predecessor-version":[{"id":3748,"href":"https:\/\/www.rustimation.eu\/index.php\/wp-json\/wp\/v2\/posts\/6\/revisions\/3748"}],"wp:attachment":[{"href":"https:\/\/www.rustimation.eu\/index.php\/wp-json\/wp\/v2\/media?parent=6"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rustimation.eu\/index.php\/wp-json\/wp\/v2\/categories?post=6"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rustimation.eu\/index.php\/wp-json\/wp\/v2\/tags?post=6"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}