Reverse SSH Tunnel – Schritt für Schritt

Ein Reverse SSH Tunnel ist immer dann hilfreich, wenn man auf einen Raspberry Pi, der hinter einer Firewall läuft, zugreifen will und die Firewall nicht selbst für Zugriffe von außen freischalten kann.
Zum Beispiel, wenn der Pi per Mobilfunk mit dem Internet verbunden ist. Mobilfunkprovider lassen meist keine Zugriffe von außen auf die im Netz vorhandenen Clients zu. Außerdem wird in der Regel eine Network Address Translation (NAT) vorgenommen, um IP Adressen zu sparen. Ganz ähnlich wie bei eurem Router zuhause.

Begriffsklärung

Für das weitere Verständnis dieses Artikels möchte ich einige Begriffe definieren

  • Remote Pi: Das ist der Raspberry Pi, der im Mobilfunknetz hängt und auf den „von außen“ zugegriffen werden soll
  • Gateway Pi: Das ist der Raspberry Pi, mit dem sich der Remote Pi verbindet und über den auf den Remote Pi zugegriffen werden soll
  • SSH: Secure Shell, ein Protokoll bzw. Programm, das auf beiden Rechnern läuft. Normalerweise ist SSH schon aktiviert, andernfalls über sudo raspi-config den Punkt „Advanced Options – SSH“ auswählen.
    Achtung:  Bei Raspbian ab ca. Dezember 2016 ist SSH deaktiviert! Bitte die Hinweise in diesem Artikel meines Blogs beachten.
    SSH dürfte jeder kennen, der über Putty oder ein anderes Terminalprogramm auf den Pi zugreift.
  • Dynamische IP Adresse. In der Regel hat ein Privatmensch keine statische IP Adresse sondern bekommt von seinem Provider in regelmäßigen Abständen eine neue IP Adresse verpasst. Damit die gerade aktuelle Adresse überhaupt gefunden wird, sollte man sich eine Dynamische IP Adresse zulegen. Das geht über spezialisierte DynDNS Provider wie Selfhost. Wenn man bereit ist, diese Adresse monatlich zu bestätigen, kostet das dort noch nicht einmal etwas.

Was benötige ich dafür?

Folgende Voraussetzungen sind zu erfüllen:

Allgemein

  • Alle Eingaben etc. erfolgen im Terminalmodus bzw. über ein Terminalfenster vom Raspberry Desktop.
  • 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.

Remote

  • Logischerweise einen Raspberry Pi, sonst macht das alles ja keinen Sinn.
  • Einen mobilfunkfähigen Router und unbedingt einen Flatrate Tarif, sonst wirds teuer, da der Tunnel immer wieder ein paar Byte durch den Äther jagt. Der Remote Router braucht keine Portfreigabe.
  • Einen USB Internet Stick für den Remote Router bzw. direkt am Remote Pi oder einen UMTS bzw. LTE Router (z.B. die Fritz!Box 6820 LTE).

Gateway

  • Einen weiteren Raspberry Pi – oder einen (Linux) Rechner als Gateway, auf dem SSH läuft. Die Gatewayfunktion übernimmt der Pi nur so nebenbei, darauf können problemlos noch zusätzlich und gleichzeitig ein OwnCloud und ein WordPress Server laufen. Der Pi ist ideal für 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.
  • Router am Gateway Pi mit Port Freischaltung für den SSH Port Nummer 22 – 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 diesem Post hier beschrieben
  • Dynamische IP Adresse sollte unbedingt vorliegen, sonst machts keinen Spaß.
    Dann noch den Router so konfigurieren, dass er seine aktuelle IP Adresse an den DynDNS Provider meldet.
  • Nachdem der Router am Gateway Pi konfiguriert ist, muss man am Gateway Pi  initial nur die SSH Konfiguration einstellen.  Du könntest anschließend zu deinem Remote Pi in den Urlaub fahren und alles Weitere dort konfigurieren. Idealerweise hat man beide Pis natürlich zuhause, konfiguriert und testet dort alles und fährt dann mit dem Remote Pi in Urlaub.

Wie funktioniert das überhaupt?

Vereinfacht ausgedrückt, baut der Remote Pi selbständig eine Verbindung zu einem anderen Rechner (Gateway) auf. Diese Verbindung (der Tunnel) wird aufrecht gehalten. Das Gateway kann nun selbst mit dem Remote Pi Kontakt aufnehmen, oder ein dritter Rechner (z.B. Putty auf einem Windows PC) greift via Gateway Pi auf den Remote Pi zu.

Ein Reverse SSH Tunnel macht überall dort Sinn, wo man wegen eines Firewalls, Network Address Translation oder sonstiger Hemmnisse nicht von außen auf einen Rechner zugreifen kann. Der Tunnel funktioniert, solange der Remote Rechner über das Netzwerk, mit dem er verbunden ist, ins Internet kommt. Ob mit WiFi, Kabel oder Mobilfunk ist völlig egal. Es versteht sich von selbst, dass das hier beschriebenen Verfahren nur dort verwendet werden darf, wo auch die Erlaubnis dafür 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ür z.B. ins Netzwerk des eigenen Arbeitgebers wird früher oder später entdeckt werden und hat in der Regel arbeits- bzw. strafrechtliche Konsequenzen.

Schritt 1a: SSH Konfiguration auf dem Gateway Pi

Um später für unterschiedliche Anwendungsfälle gewappnet zu sein, sollten folgende Einstellungen am Gateway Pi vorgenommen werden:

In früheren Versionen der Anleitung fehlten diese Hinweise auf die Gateway Konfiguration. Während meiner vielen vergeblichen Versuche, so ein Reverse Tunnel hinzubekommen, hatte ich diese Einträge wohl einmal vorgenommen und dann vergessen, dass ich sie hatte… Danke an Hannes für die ensprechende Fehlermeldung und fürs Finden der Lösung! (siehe Kommentare)

Editiert die Datei /etc/ssh/sshd_config als root – z.B. mit dem eingebauten Editor nano:

dort dann am besten folgende Einträge suchen und abändern bzw. die Einträge am Ende vornehmen:

Mit den ersten beiden Zeilen wird sichergestellt, dass die Verbindung nicht einfach wieder abgebaut wird, wenn eine Zeitlang keine Daten über die Leitung flutschen.

GatewayPorts yes erlaubt es, das Gateway quasi als „Durchlauferhitzer“ zu nutzen, d.h. von einem anderen Gerät über den Gateway Pi in der Mitte auf den Remote Pi zuzugreifen.

AllowTcpForwarding yes
erlaubt es, auch andere Protokolle – z.B. http –  im SSH Tunnel zu verpacken.

Sind die Änderungen eingetragen, nano mit Strg-X beenden, bei der Frage, ob die geänderte Datei gespeichert werden soll, mit „J“ antworten und anschließend die Eingabetaste drücken. Anschließend neu booten.

Schritt 1b: Aufbau SSH Tunnel auf dem Remote Pi

Am Remote Pi geben wir folgenden Befehl ein:

Erläuterung der Parameter:
p2000 (optional) abweichender Port des Gateway Pi über den der Remote Pi den Tunnel aufbaut. Kann auch weggelassen werden dann wird automatisch die Portadresse 22 genommen. In jedem Fall muss die gewählte Portnummer im Router des Gateway Pi freigeschaltet werden. Wie man das anstellt, habe ich im Artikel Dynamische IP Adresse mit Bordmitteln im Kapitel Portfreischaltung (Beispiel Fritz!Box) beschrieben.
-f bedeutet, dass ssh im Hintergrund laufen soll. Anschließend kann das Terminalfenster wieder geschlossen werden, SSH läuft aber im Hintergrund weiter.
N bedeutet, dass lediglich der Tunnel aufgebaut wird, aber keine Remote-Kommandos entgegen genommen werden.
C (optional) komprimiert die über die Strecke laufenden Daten. Achtung, dieser Parameter; verschlechtert unter Umständen die Performance – also ausprobieren.
-R besagt, dass ein Reverse Tunnel aufgebaut werden soll.
10011 ist der Ausgangsport (outgoing port address) des Gateway Pi. Startet man dort eine SSH Sitzung über den Port 10011, kommt man beim Remote Pi raus. Im Prinzip kannst du jede Portadresse über 1024 verwenden, die nicht schon von deinem Pi belegt ist. Eine Liste der standardisierten Ports findest du z.B. bei Wikipedia.
localhost ist der Name unter dem ein Rechner sich selbst erkennt; also ein „ich“ oder ein „bei mir“.
Falls ihr über den Tunnel, der beim Remote Pi ankommt, weitere Geräte im Remote Netzwerk ansprechen wollt, dann kann statt localhost auch die lokale IP Adresse eines Remote Netzwerkgeräts stehen. Siehe weiter unten bei „externe Geräte ansprechen“.
22 ist die Standard SSH Portnummer des Remote Pi.
pi@dyn.IP.adresse ist der User- und Servername der auf dem Gateway Pi verwendet wird – dyn.IP.adresse ist die Adresse (URL) des Gateway Pi über den man auf den Remote Pi zugreifen will. Bitte entsprechend deine dynamische IP Adresse eintragen. anstatt „Pi“ kannst du natürlich auch jeden anderen User verwenden, der auf dem Gateway Pi angelegt ist.

Erster Test:
Probiers mal aus, d.h. gebe oben stehendes Kommando am Remote Pi ein. Wenn alles stimmt, wirst du zusätzlich noch das Passwort des Users Pi vom Gateway Pi eingeben müssen.
Auf dem Gateway Pi kann man sich nun mit dem Befehl

auf dem Remote Pi einloggen. Das kann man übrigens auch tun, wenn man nicht vor Ort ist. Dazu einfach auf dem Gateway Pi mit Putty einloggen – 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ürlich nur, wenn der entsprechende Port im Router zuhause auch freigeschaltet ist. Ihr kommt dann beim Gateway Pi raus und könnt dort den obigen Befehl eingeben.
Perfekt? Nein, nicht ganz: Das Eingeben des Gateway Passworts beim Aufbau des Tunnels nervt und führt dazu dass der Tunnel nur mit Nutzereingriff d.h. manuell aufgebaut werden kann. Und wir wollen ja eine automatische Löung. Deshalb…

Schritt 2: Login ohne Passwort

Neben der Passworteingabe zum Login kann man einem entfernten Rechner auch seine „Ausweisdaten“ d.h. einen RSA Key übermitteln, anhand dessen dann der anrufende Rechner erkannt und akzeptiert wird. Auf unseren Fall übertragen heißt das, wir müssen den öffentlichen RSA Key des Remote Pi auf den Gateway Pi übertragen.
Dazu 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 der Schlüssel erst erzeugt werden:
Das geschieht mit

Nach Belieben die vom Programm abgefragten Daten eingeben, die Passphrase aber leer lassen, wir wollen uns ja automatisch mit dem Gateway verbinden.
Nun muss man den erzeugten Schlüssel (RSA 2048 Bit) auf das Gateway kopieren. Dazu folgenden Befehl am Remote Pi eingeben:

Hat man auf dem Gateway Pi eine andere SSH Portadresse (z.B. 2000) eingerichtet, lautet der Befehl wie folgt:

dabei unbedingt die Anführungszeichen beachten.

Update: bei neueren Versionen von Raspbian (z.B. Jessie) sind die Anführungszeichen nicht mehr erforderlich.

Testen kannst du das auf dieselbe Weise wie oben.

Nochwas:
Hat der User Pi den Schlüssel erzeugt, muss der User Pi auch den Tunnel
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 crontab -e eingibst.

Gut, aber immer noch nicht perfekt!

Schritt 3: Stabilisieren

Gerade wenn der Remote Pi über Mobilfunk im Internet hängt, kann es vorkommen, dass die Verbindung hin und wieder kurz unterbrochen wird. (Das passiert übrigens auch bei den meisten DSL Providern. Irgendwann nachts wird die Verbindung zurückgesetzt.) In diesem Falle bricht der Tunnel geräuschlos aber unerbittlich zusammen. Man könnte jetzt ein Skript schreiben, das die Verbindung laufend überprüft und bei Bedarf neu aufbaut. Das ist zum Glück überflüssig, denn es gibt mit autossh eine Erweiterung (eigentlich einen Wrapper) für SSH. Einfach autossh anstatt ssh verwenden und schon haben wir ein stabiles System. Perfekt? Leider immer noch nicht, denn autossh hilft nichts, wenn der Remote Pi z.B. wegen eines Stromausfalls neu startet.

Möglicherweise ist autossh noch nicht auf dem Pi installiert. Dem kann man ganz einfach mit sudo apt-get install autossh  abhelfen.

Schritt 4: Autostart

Wir erstellen ein Script mit Namen tunnel.sh, in das wir den Reverse SSH Tunnel Befehl eintragen:

Dieses Script legen wir im Homeverzeichnis ab. Mit

machen wir es ausführbar.

Alles was automatisch beim Start oder in regelmäßigen Abständen laufen soll, wird per Crontab aufgerufen. Dazu folgender Befehl:

Es erscheint die Crontab im Editor – ganz nach unten scrollen und folgende Zeile eingeben

mit Strg+X speichern wir die Crontab und verlassen den Editor.

In einer früheren Version dieser Anleitung hatte ich die Crontab als Superuser mit sudo crontab -e 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üssel mit „sudo ssh-keygen“ erzeugt und mit „sudo ssh-copy-id“ übertragen. 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.

So! jetzt ist es annähernd perfekt. Der SSH Tunnel startet nach jedem Reboot und ist nun komplett, stabil und betriebssicher. Bitte beachtet, dass der Tunnel unter Umständen 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 autossh Kommando das erste mal abgearbeitet wird. Mit autossh stellen wir aber sicher, dass die Verbindung anschließend automatisch hergestellt wird.

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ändig nachkam und die Portweiterleitung bestreikte. Nach einem Reboot der Fritz!Box (auch per Fernzugriff möglich) gings dann wieder.

Nochwas: Auch der Router am Remote Pi scheint manchmal seine Probleme zu haben. Unter Umständen ist das Mobilfunknetz so stark überlastet, dass der Router, bzw. der Internet Stick daran sich einfach nicht verbinden will. Nach zu vielen Fehlversuchen streikt der Router dann – zumindest der von mir verwendete TP-Link Mobilfunk Router TL-MR3420. Dann hilft nur ein physikalischer Reset des Routers. Auch dafür gibts eine Lösung mittels Fernschalt-Steckdosen und 433MHz Sender am Pi. Dazu habe ich einen eigenen Artikel geschrieben.

Schritt 5: Browsen im Tunnel

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önnen, passen wir unser Skript bzw. den Befehl darin wie folgt an:

8000 ist die Portnummer mit der die http Daten vom Gateway zum Remote Pi umgelenkt werden.
80 ist der Standardport für http. Was beim Gateway an Port 8000 geschickt wird, kommt beim Remote Pi an Port 80 wieder an. Und 80 ist der Port, mit dem der Webserver normalerweise kommuniziert.
Will 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ür http. Also zum Beispiel:

Externe Geräte ansprechen

Extern bedeutet in diesem Kontext andere Geräte im Remote Netzwerk. Wenn ihr also eine IP Cam mit einem Browser über den Tunnel ansprechen wollt, dann einfach anstatt localhost die IP Adresse des externen Geräts verwenden.

Hat die Cam z.B. die lokale Adresse 192.168.178.120 dann wird das Tunnelskript von oben wie folgt erweitert:

über die Parameter -R 8889:192.168.178.120:80 wird alles was auf Port 8889 ankommt, auf den html Port 80 des externen Geräts, z.B. einer Cam umgeleitet.
Auf 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 – oder was auch immer ihr ansprechen wollt  – heraus. Ihr könnt  auf diese Weise auch euren remoten Router ansprechen und administrieren.

Herzlichen Dank an Reto Huber für diesen genialen Tipp!

Mehr darüber in einem eigenen Beitrag .

Zugriff von „Außen“

Will man auch von „außen“, also außerhalb des Heimnetzwerks, auf eine beim Remote Pi gehostete Website zugreifen, muss man im Router des Heimnetzwerks zusätzlich die Portadresse 8000 (oder was immer du gewählt hast) freischalten. Der Aufruf erfolgt dann so:

Das alles setzt natürlich voraus, dass auf dem Remote Pi auch ein Webserver installiert ist.

 

123 Gedanken zu „Reverse SSH Tunnel – Schritt für Schritt

  1. Hallo
    Vielen Dank für die Erläuterungen.
    Ich möchte das ganze gerne wie auch im Beispiel genannt für einen Pi nutzen, der per Mobilfunk ins Internet kommt.

    Wie groß ist denn der Traffic-Verbrauch, wenn der Tunnel dauerhaft steht?
    Also ohne dass man jetzt gerade auf den Pi zugreift?

    1. Hi,
      ich hab noch nicht nachgemessen. Im Prinzip ist es relativ wenig – ein paar KB pro Tag. Sofern es das überhaupt noch gibt, macht ein zeitbasierter Mobilfunk-Internet Tarif (z.b. 1 Stunde für 1€) keinen Sinn, da die Verbindung ja immer wieder kurz gepingt wird. Also besser einen Volumentarif. Je nach Anwendung mehr oder weniger. Ne Cam braucht relativ viel Daten, reine HomeAutomation eher weniger.
      Happy making
      Chris

      1. Besten Dank für die schnelle Antwort.
        Es wird ein Volumentarif zum Einsatz kommen.
        Ich möchte ein Zeitraffer-System warten / fernsteuern.

        Könnte sich durch die Verbindung auch in das Netzwerk des Remote-Pi einwählen (VPN?) und so die anderen Netzwerkteilnehmer erreichen?

        Ich hoffe das ist verständlich. Kenne mich in dem Bereich noch nicht so gut aus 🙂

        VG
        Patrick

        1. Hi,
          so ganz habe ichs nicht verstanden. Was ich beschrieben habe ist eine Punkt zu Punkt Verbindung zwischen Remote und Gateway.
          Auf das Gateway können natürlich mehrere User (von außen) zugreifen. Dafür muss aber der Gateway Pi und die Weiterleitungsportadresse(n) im Router freigegeben werden. .Z.B. kannst du auf dem Remote Pi einen Webserver laufen lassen, auf den dann alle möglichen Leute zugreifen können – indem sie deine Gateway dynIP Adresse:portnummer aufrufen und so auf dem Remote Webserver landen.
          Abgesicherter ginge es wenn du ein VPN z.B. auf der Fritzbox einrichtest – sofern du eine hast. Mit dem VPN landest du von „draußen“ in deinem privaten LAN und kannst dann auf das Gateway zugreifen als ob du dich direkt in deinem Netzwerk befinden würdest. Das kann jeder, der die VPN Credentials hat.
          Ich hoffe, du kannst das einigermaßen nachvollziehen.
          Freundliche Grüße aus München
          Chris

          1. Hi
            Das habe ich soweit verstanden.
            Was ich versuchen wollte ist folgendes:
            Der Remote-Pi hängt in einem Netzwerk mit einem weiteren Pi und einem Router.
            Ist es möglich sich, wie oben mit der Fritzbox beschrieben, in das Netzwerk per VPN einzuloggen, sodass ich auch den Router bzw den weiteren Pi erreichen kann?
            Geht das durch den SSH Tunnel?

            Viele Grüße aus Anröchte
            Patrick

            1. Klar geht das. VPN brauchst du dafür nicht unbedingt. Steht auch so ähnlich im Kapitel Externe Geräte ansprechen des Beitrags
              Wenn du dein Tunnelkommando auf dem Remote Pi wie folgt erweiterst, kommst du, wenn du deine Gateway IP gefolgt von :8111 im Browser eingibst bei der angegebenen IP Adresse raus: -R 8111:192.168.178.102:80
              Natürlich musst du hier die IP Adresse des Devices angeben, das du ansprechen willst. Geht natürlich auch mit Linux shell (via Putty), dann anstatt :80 eben :22 verwenden und du kannst mit Putty direkt auf das Gerät zugreifen.
              Der direkte Connect auf den Router geht so:
              -R 8111:192.168.178.1:443 8111 ist wieder beliebig, die IP vom Router (Fritzbox) ist normalerweise immer dieselbe, 443 ist die https Portnummer, unter der du den Router anspechen musst. Dann im Browser mit https:/IPvomGateway:8111 aufrufen. Dann noch den Sicherheitshinweis bestätigen und fertig! der Aufruf mit https:// ist wichtig, sonst wird die Verbindung zurück gewiesen.
              Was auch geht, ist eine Windows Remote Desktop Verbindung mit dem Remote Pi aufzubauen (d.h. die grafische Benutzeroberfläche vom Remote Pi aufrufen) Von da aus z.B. den Browser starten und die anderen Geräte anspechen. Die Tunnelerweiterung ginge dann so: -R 9000:localhost:3389
              9000 ist eine beliebige freie Portnummer auf dem Gateway, 3389 ist fest vorgegeben für den Remote Desktop. Irgendwo in den Kommentaren hier ist das etwas genauer beschrieben. Alternativ geht auch VNC. Vorher musst du noch auf dem Remote das Programm xrdp installieren. rdp und VNC beisst sich, also nur eines von beiden installieren.
              VPN brauchst du wirklich nur, um dich von außen in das Netzwerk des Gateways einzuloggen. Das ist in jedem Fall sicherer als die Freigabe einer weiteren Portadresse.
              Update: Vor Lauter Lauter hätte ich beihnahe die allereinfachste Möglihkeit vergessen. Du loggst dich via Gateway auf dem Remote Pi ein (mit Putty) und gibst dort ein: ssh username@IPAdresseDesAnderenPi So kommst du beim anderen Pi raus. Du kannst so eine ziemlich lange Kette aufbauen, indem du quasi von Pi zu Pi springst – ob das sinnvoll ist, steht auf einem anderen Blatt. Aber eine dreifache Verkettung habe ich öfter: vom Internet auf das Gateway – auf den Remote – auf einen weiteren Pi, der kein Reverse Tunnel hat.

  2. Hallo zusammen und vielen Dank für die super überschaubare Anleitung.

    Ich habe das Problem, dass die Portweiterleitung zwar läuft und ich vom Gateway (über ssh -p 10011 localhost) und von meiner Domain zwar auf dem Remote Pie ankomme, aber dort wird mein Passwort nicht akzeptiert. Woran kann das liegen?

    1. Hallo,
      könnte es sein, dass der User auf dem Gateway ein anderer ist, als auf dem Remote? Wenn der Remote User, der den Tunnel aufgebau hat, Pi heißt, dann solltest du es mal so versuchen: ssh -p10011 pi@localhost.
      Gruß
      Chris

      1. Ich hatte mir aus Sicherheitsgründen einen neuen User erstellt und bin mit seinen Rechten und Passwörtern durcheinander gekommen.
        Vielen Dank für die Hilfe 🙂

    2. Wie das oftmals so ist, kann man sich die meisten Fragen nach einiger Zeit selbst beantworten.
      Achtet immer darauf, von welchem Raspi das Kennwort grade verlangt wird und mit welchem Benutzer man sich anmeldet.

      Ich hatte auch mit der Firewall ein paar Probleme. Sollte jetzt aber laufen.

      Vielen Dank nochmal! Die Anleitung ist auch sehr schön erklärt. So bekommt man mehr Hintergrundwissen und kann sich besser weiterhelfen 🙂

  3. Hallo, klasse Sache, funktioniert in meinem Netz gut. Aber wenn ich über dyndns verbinden will geht es nicht, was mache ich falsch?
    Die Verbindung soll mit einem Surfstock über:
    /usr/bin/autossh -p12222 -fNC -R 8000:localhost:80 -R 10011:localhost:22 -R 8889:192.168.152.234:80 pi@xxxxxxx.dyndns.ws
    aufgebaut werden, der Port 12222 ist in der Fritzbox für den gateway freigegeben.
    Über den Stick kann ich die Adresse Pingen, Ip wird aufgelöst.
    Der Port am Gateway ist 22, muß ich die Portfreigabe auf einen anderen legen?
    Kann mir bitte jemand helfen? Daaaaaanke

    1. Hi,
      wenn du SSH von Remote das Gateway über Port 12222 ansprechen willst, musst du natürlich auch SSH im Gateway dazu bringen, das als Eingangsport zu akzeptieren. Wie das geht, steht in dem Artikel https://chriskrz.selfhost.bz/index.php/ssh-portadresse-andern/
      Alternativ kannst du auch in der Fritzbox den Port 12222 auf Port 22 umleiten – Portfreigabe aktiv für „andere Anwendungen“ auswählen, bei „von Port“ die 12222 eintragen und bei „an Port“ die 22 eintragen.
      Freundliche Grüße aus München
      Chris

      1. Hallo Rustimator, danke für deine Hilfe. In der Fritzbox ist der Port 12222 auf den Port Gateway-IP Port 22 weitergeleitet. Mit anderen Postfreigaben klappt ja auch alles…
        Habe gerade festgestellt das die Fritzbox 12222 nicht zulässt, 62222 wird aber angenommen. Aber auch damit klappt es nicht. Muß ich den Port 10011 im Verbindungsaufbau auch ändern?
        Danke.
        Gruß Horst

        1. Probiers doch erst einmal ganz einfach. Reines ssh Tunnel mit nur einer -R Einstellung ohne abweichende Gateway Portadresse.
          /usr/bin/autossh -fNC -R 10000:localhost:22
          Im Router ist Port 22 auf Port 22 durchgeroutet. (später wieder umstellen, da die bösen Jungs da draußen die 22 besonders gerne angreifen)
          Dann erst einmal testen, ob du von innerhalb deines Netzwerks mit putty o.ä. auf den Port 10000 des Gateways zugreifen kannst. Wenn alles klappt, kommst du direkt beim Remote Pi raus.
          Dann schrittweise komplizierter werden. Andere Portadresse des Gateway einstellen. ggf. versuchen die andere Portadresse im Router nicht zu verbiegen,. z.B. „An Port 3333“ und „Zu Port 3333“ einstellen. Dann weitere Porotkolle (http usw.) dazunehmen.
          Gruß
          Chris

      2. Hallo Rustimator,

        jetzt funktioniert es einigermassen: ich kann nicht mit /usr/bin/autossh -p12222….., sondern mit ssh -p12222…. die Verbindung aufbauen. es kommt zwar eine Fehlermeldung wegen der Ports 8000 und 10011, aber die Verbindung steht. Ich weiß nicht warum, aber so gehts erstmal.
        Gruß aus dem Schwarzwald,
        Horst

        1. Frage: hast du überhaupt autossh installiert? Wenns mit ssh funktioniert, muss es auch mit autossh funktionieren, das ist nur eine Kontollogik (wrapper) um ssh herum, ssh bleibt unverändert.
          Wie sieht die Fehlermeldung aus? wie sieht dein Tunnelaufbaukommando auf dem Remote aus? (private Inhalte bitte unkenntlich machen).

          1. War unterwegs und komme erst jetzt dazu, tut mir leid…
            Der Tunnelaufbau passiert mit den oben beschriebenen Befehlen in „Schritt 5“. Solange ich beide Pi in meinem Netz habe funktioniert auch autossh, nur wenn ein Pi über UMTS verbunden ist muss ich mich mit ssh statt autossh anmelden. Aber es funktioniert. Der Remote-Pi ist schon weit weg im Einsatz, aber ich werde in den nächsten tagen eine zweite Brücke einrichten, dann sehe ich das nochmal an.

  4. Wo finde ich denn das Log des und des ?
    Mit einem Rechner klappt es, mit dem nächsten nicht, und ich würde gerne das Log auslesen….
    Danke, Grüße,
    Linzus

  5. Hallo Chris,

    Deine Anleitung ist wirklich prima.
    Leider habe ich das Problem, dass ich beim Verbindungsaufbau Gateway > Remote
    nach einem Password gefragt werde. Weder das vom Gateway noch das vom Remote
    wird akzeptiert????
    Gruß
    Rudi

    1. Hi,
      für den Tunnelbetrieb muss sich eigentlich der Remote Pi beim Gateway einloggen, nicht andersrum. Dazu muss 1malig der Public Key übertragen werden. Wenn du dich dann vom Gateway beim Remote einloggen willst, musst du das PW des Remote Users kennen. Und zwar des Remote Users, der den Tunnel aufgebaut hat. Den User erkennst du an der Login Aufforderung pi@localhost’s password:
      Gruß
      Chris

  6. Hallo Chris.

    Eine wirklich tolle Anleitung hast du da erstellt. Hat alles auf anhieb funktioniert.
    Ich hätte noch eine kleine Frage, in der Hoffnung ein paar Tipps zu erhalten.
    Ich habe den Remote pi an einem etwas speziellen Router mit DS-lite Anschluss hängen. Da ich in dem Router sehr wenig Firewall Einstellungen machen kann, habe ich einen SSH Tunnel wie oben beschrieben erstellt und den Gateway pi bei mir Zuhause eingerichtet.
    In dem Netzwerk des Remote pis möchte ich eine Heizungsregelung auf der ein VNC Server vorinstalliert ist über mein Gateway ansprechen. Leider komme ich gerade nicht weiter weil ich nich genau weiß wie ich über SSH den VNC viewer auf dem Remote pi aufrufen kann. Würde mich sehr über Tipps wie ich am besten vorgehen soll freuen.
    Vielen Dank.
    Gruß Steffen

    1. Hallo Steffen,
      Weihnachtszeit, Bastelzeit.
      VNC habe ich vor längerer Zeit einmal genutzt, fand aber den VNC Client für Windows aber zu umständlich und verwende daher die Remotedesktopverbindung von Windows.
      Versuchen wir’s einmal Schritt für Schritt:
      Um den grafischen Desktop des Remote Pi anzuzeigen bzw. eine Remote Desktop Sitzung von zuhause aus zu starten gehe ich wie folgt vor:

    2. Installiere xrdp auf dem Remote Pi (mit sudo apt-get update und dann sudo apt-get install xrdp). Dabei wird ein Remote Desktop Server auf dem Remote Pi installiert und bei jedem Neustart auch gleich gestartet. Braucht relativ wenige Ressourcen, d.h. es kann so bleiben.
    3. Erweitere dein Tunnelstartkommando auf dem Remote Pi entsprechend der Anleitung hier im Blog wie folgt: /usr/bin/autossh -p2099 -fN -R 8000:localhost:80 -R 12100:localhost:22 -R 9000:localhost:3389 pi@deine.DynIP.adresse
      wichtig ist dabei der Teil -R 9000:localhost:3389. 3389 ist die vorgegebene Portadresse von xrdp. 9000 ist die Portnummer des GatewayPi, die angesprochen werden muss.
    4. Auf deinem Rechner daheim (hier Windows) gibt ein ein Programm namens „Remotedesktopverbindung“. Dieses Programm starten. In die Zeile Computer die IP Adresse deines GatewayPi eintragen, gefolgt von einem Doppelpunkt und der oben definierten Gateway Portnummer (hier 9000). Am Router zuhause musst du nichts ändern.
      Die anderen Einstellungen erst einmal so lassen. Mit Klick auf den Verbinden Button wird die Verbindung aufgebaut. Im nach ein paar Sekunden erscheinenden Fenster namens Login to xrdp bei Module sesman-xvnc auswählen. Username und Passwort des Remote Pi Benutzers eigeben (zwischen den Feldern mit dem Tabulator wechseln). Mit Klick auf OK wirst du jetzt auf dem Remote Pi Desktop eingeloggt. Voraussetzung ist natürlich, dass der Desktop überhaupt installiert ist. Bei einer Standard Raspbian oder Raspbian Noobs Distribution ist das der Fall, bei Raspbian Lite hingegen nicht.
      Nach ein paar Sekunden bist du auf dem Desktop des Remote Pi angekommen und kannst von dort aus alle Geräte im Remote Netzwerk z.B. über den Browser oder den VNC Viewer anfunken. Nicht sehr flott, aber vielleicht reicht das ja schon…
    5. Wenn du direkt auf die Heizungsregelung springen willst, ohne dich vorher auf dem Remote Pi einzuloggen, versuche den Tunnel wie folgt zu modifizieren:
      -R 9000:interne.ipadresse.deiner.heizungssteuerung:5500 Also anstatt localhost die Adresse deines anderen Devices im Remote Netz angeben. Die Portadresse von VNC ist – glaube ich – 5500 oder auch 5800. Ggf Dokumentation lesen…
      Ich bin mir aber nicht sicher, ob du dich mit dem Windows Remotedesktop auf einem VNCServer connecten kannst.
      Sollte es mit dem Windows RemoteDesktop nicht klappen, dann auf deinem Windows Rechenr einen VNC Client installieren und es damit versuchen (siehe Link weiter unten). Den VNC Port müsstest du im Tunnel Setup noch anpassen.
      Eine schöne Anleitung gibt es außerdem hier: https://raspberry.tips/raspberrypi-einsteiger/raspberry-pi-einsteiger-guide-vnc-einrichten-teil-4/
      Gib mir Bescheid, obs funktioniert.
      Chris
      1. Hallo Chris.
        Vielen Dank für die schnelle und Ausführliche Antwort.
        Ich habe alles nach deiner Anleitung eingerichtet. Wenn ich Remotedesktopverbindung starte, komme ich bis zum Anmeldebildschirm von xrdp. Da habe ich Benutzer und Passwort des Remote PI eingegeben und erhalte folgende Meldung:
        Connecting to sesman ip xxx.x.x.x port 3350
        sending login info to session manager, please wait…
        xrdp_mm_process_login-response:login succesful for display
        Started connecting
        Connecting to xxx.x.x.x 5910
        Error – problem connecting

        Das wird ausgegeben wenn ich mich einloggen möchte.
        Muss ich am Gateway PI evtl. noch etwas ändern?
        Gruß Steffen

        1. Ich habe es hinbekommen 🙂
          Ich habe nachgelesen das sich XRDP nicht mit dem realvncserver verträgt.
          Was habe ich getan:
          1. Den realvncserver deinstalliert
          $ sudo apt-get purge realvnc-vnc-server
          2. XRDP auch nochmal deinstalliert
          $ sudo apt-get purge xrdp
          3. Neu gestartet
          4. XRDP wieder installiert
          5. Neu gestartet
          6. Remotedesktop Verbindung am Windows PC gestartet und Logindaten eingegeben
          7. Vor Freude in die Luft gesprungen.
          Vielen Dank für deine Hilfe.
          Du glaubst gar nicht wie froh ich darüber bin.
          Gruß Steffen

  7. Hallo Chris!
    Du hast hier wirklich eine tolle Seite auf die Beine gestellt!
    Leider komme ich nicht so ganz weiter – ich möchte grundsätzlich gern einen FTP-Server auf meinem Gateway Pi installieren, auf diesen sollen Dateien von einem Pi weit von mir entfernt gelegt werden (im Tagestakt). Dieser Remote Pi wird mit einem Surfstick betrieben, ist also genatet. Wie kann ich nun Dateien vom Remote Pi auf den FTP-Server legen lassen? Das Beispiel, dass du Herbert gegeben hast, habe ich mir schon angeschaut – gebe ich aber die Zeile „scp /home/pi/xxx.jpg -P2022 pi@meine.dyndnsadresse.org:/home/pi/xxx.jpg“ ein, passiert gar nichts, es sieht nur so aus, als hätte der Raspi sich aufgehangen oder würde irgendetwas anderes machen, nur nicht meine Datei senden (auch eine Bestätigung durch die Konsole passiert nicht, es stoppt einfach). Hast du eine Idee, wie ich dieses Problem lösen kann?
    Viele Grüße, Jonas

    1. Hallo und danke. Freut mich, wenn die Seite weiterhilft.
      Wenn der Tunnel generell funktioniert, dann hast du ja schon einmal die Hälfte der Miete.
      Ich habs gerade eben noch mal ausprobiert: Mit Putty auf dem Remote Pi eingeloggt (via Gateway) und dort im Quellverzeichnis mit scp -PdeinGatewayPort Quelldatei pi@deineDynIP:Zieldatei eine Datei zurück aufs Gateway übertragen – bei mir kommt die Portadresse unmittelbar nach dem scp.
      Geht absolut sauber.Für Quelldatei und Zieldatei kannst du natürlich einen qualifizierten Pfad und Dateinamen hernehmen. Auch darauf achten, dass der User Pi Schreibrechte im Zielverzeichnis hat.
      Wenn das mit SCP funktioniert, gibt es eigentlich keinen Grund, den Dateitransfer mit FTP zu machen. Den FTP Server müsstest du auf dem Gateway erst mal konfigurieren. Ob das richtig funktioniert würde ich dann einfach einmal mit einem anderen Client (z.B. deinem PC) probieren.

      1. Erstmal danke für die schnelle Antwort. Ich hab das ganze jetzt einfach über einen Webspace realisiert, komme aber sicher nochmal auf den SSH-Tunnel zurück, wenn es darum geht, von außen ein Bild machen zu lassen!

        Viele Grüße, Jonas

  8. Danke Chris,
    aber ich bekomme es nicht hin. Habe einen Testuser angelegt und da auch den Schlüssel erzeugt und übertragen. Beide Rechner neu gestartet. Testweise mit ssh versucht. Es wird immer das Kennwort verlangt. Gebe ich dreimal kein Kennwort ein, dann kommt als Fehlermeldung (sinngemäß): not connect (Publickey,Password).
    Ich habe auch die Beschreibung(Link)versucht: https://linuxaria.com/howto/permanent-ssh-tunnels-with-autossh. Genau das gleiche. Funzt, aber es wird das Passwort verlangt.
    Rechte im /home/pi/.ssh Verzeichnis habe ich lt. man ssh überprüft.
    Gibt es irgendwo die Möglichkeit einzustellen, dass immer ein Passwort verlangt wird? Evtl. liegt ja da das Problem.
    Ansonsten muss ich mich um eine andere Lösung kümmern. VPN o.ä.
    Gruß
    Klaus-Peter

    1. Du musst die falschen IDs löschen!
      zuerst auf dem Gateway:

      cd ~/.ssh
      nano authorized_keys

      dort die Zeile löschen, die mit pi@derNameDeinesRemotePi (sinngemäß) endet.
      mit Ctrl-X speichern und beenden.

      Dann analog auf dem Remote Pi:

      cd ~/.ssh
      rm id_rsa
      rm id_rsa.pub

      (ich bin mir nicht ganz sicher, ob man das überhaupt machen muss, vielleicht werden die Dateien auch durch den nachfolgenden Schritt überschrieben)

      dann die neue ID generieren, wie in Schritt 2: Login ohne Passwort beschrieben.
      Dabei unbedingt die Passphrase leer lassen, sonst war alles umsonst.

      Ich hoffe, das hilft. Sonst weiß ich auch nicht weiter.

      Freundliche Grüße
      Chris

      1. Danke Chris,
        klappt nicht. Der zweite Pi läuft ja schon länger. Damit habe ich meine ersten Schritte unternommen. Evtl. ist da ja was schief.
        Ich habe mich jetzt entschlossen, beide Pi’s mit Jessie neu aufzusetzen. Als erstes werde ich die ssh Verbindung testen und wenn es klappt, dann nach und nach die anderen Programme hinzufügen. Vielleicht gibt es auch ein Problem zwischen Jessi und Weezy. Das Glaube ich allerdings nicht.
        Die Images habe ich gesichert. Dann kann ich immer den alten Zustand wieder herstellen.
        Melde mich, ob es geklappt hat oder nicht.
        Gruß
        Klaus-Peter

        1. Sehr merkwürden das. Ich habe Mischkonfigurationen sowohl mit Jessie Remote und Wheezy Gateway als auch umgekehrt problemlos zum Laufen gebracht. Gestern erst habe ich ein weiteres Remote Teilchen nach meiner Anleitung aufgesetzt. Völlig problemlos. Ein Neu Aufsetzen ist dann wohl die Ultima Ratio.

    2. Hallo Chris.
      Jetzt klappt es. Ursache: bei Jessie steht in der /etc/ssh/sshd_config bei Authentication normalerweise ‚PermitRootLogin without-password‘. Das hatte ich in ‚yes‘ geändert, da ich mit winscp beim Bearbeiten von Dateien schneller bin.
      Das sollte später in ’no‘ geändert werden.
      Nach dem Starten mit der frischen SD Karte und der Eingabe der obigen Konfiguration hat es auf Anhieb geklappt. Dann habe ich den obigen Eintrag auf ‚yes‘ geändert und siehe da, es wird immer ein Password verlangt. Also habe ich das wieder geändert. Klappte gleich.

      Eine Frage habe ich noch zum Tunnel:
      Um einen zweiten Tunnel zu verwenden müsste doch noch nur den Eingangs und Ausgangsport ändern? Also z.B.
      /usr/bin/autossh -p2000 -fNC -R 8001:localhost:8083 -R 10011:localhost:22 pi@dyn.IP.adresse. Oder sehe ich das falsch?
      Gruß
      Klaus-Peter

      1. Hallo,
        freut mich. Das mit dem PermitRootLogin ist schon tricky. Da muss man erst einmal drauf kommen. Wobei ich nicht verstehe, warum es bei „yes“ nicht funktioniert, da das sowieso der Defaultwert ist.
        Im Prinzip kannst du mehrere Tunnel gleichzeitig aufbauen. Dein Ansatz ist genau richtig! Da geht noch mehr. Bei mir sieht das z.B. so aus:
        /usr/bin/autossh -p2000 -fN -R 8000:localhost:80 -R 9000:localhost:22 -R 8221:192.168.178.1:443 pi@dynipadresse
        Der dritte Eintrag verweist direkt auf den Remote Router, den ich so ganz easy administrieren kann.

        1. Hallo Chris.
          Das geht ja prima. Ich habe jetzt einen Tunnel für fhem, Putty, webmin und auf die Fritz!box.
          Noch zum PermitRootLogin: Der Tunnelaufbau funktioniert mit no und without-password. yes geht nicht. Aber nur beim Remote Pi. Beim Gateway spielt es keine Rolle. Warum auch immer.
          Danke noch mal für deine Unterstützung und das super Tutorial.

          Gruß
          Klaus-Peter

  9. Hi,
    danke für ausführlichen Tips.
    Habe zwei Raspi, einer mit Weezy(Gateway), auf dem läuft noch minidlna. Der andere (Remote) mit Jessy soll sich mit dem Gateway verbinden. Der Remote steht hinter eine FritzBox 7270 mit einem USB Mobilfunkstick.
    Auf beiden Rechnern läuft ausserdem noch webmin. Zugriff habe ich ausserdem noch über Putty und WinSCP. (Lokal)
    Die Verbindung klappt, wenn ich die Passwörter eingebe. Mit den Zertifikaten aber nicht. Das Zertifikat habe ich als Pi auf dem Remote erstellt und wie beschrieben, auf das Gateway übertragen. Das klappt. Allerdings nur mit Passwort. Ist ja auch klar.
    In der Datei /home/pi/.ssh/authorized_keys, auf dem Gateway, ist der (Public) Schlüssel vorhanden. Bin dort auch als pi angemeldet. ssh habe ich jeweils neu gestartet. Auch die Rechner.
    Nun stehe ich als Linux NewBi auf dem Schlauch.
    Hast du eine Idee, wo ich noch nachsehen, oder dran drehen kann?

    Grüsse aus der Nähe von Nürnberg

    1. Hi,
      wenn du alles nach Anleitung gemacht hast, dann müsstest du dich vom Remote ohne Passwort auf dem Gateway einloggen können. Wenn du den Key erstellst, darfst du kein Passwort eingeben.
      In jedem Fall erst einmal manuell versuchen vom Gateway aus dich auf dem Gateway einzuloggen. Dass muss ohne Passwort gehen, sonst nützt das alles nichts…
      Viele Grüße
      Chris

  10. $ ssh -p 10011 -l pi localhost
    ssh: connect to host localhost port 10011: Connection refused

    Einmal gehts und dann erhalte ich diese Fehlermeldung auf dem Gateway IP. Ich komme nicht drauf wo der Fehler liegt. Boote ich den Remote PI neu, funktioniert der Reverse SSH Tunnel. Nach einiger Zeit aber die Fehlermeldung.. Danke!

    1. Hallo Daniel,
      scheint ganz so, als ob der Remote Pi seine Verbindung zumacht.
      Du kannst das im Syslog nachvollziehen.
      cat /var/log/syslog|grep "ssh"
      da steht dann so was:
      Sep 14 13:36:13 raspberryDrei autossh[2125]: ssh child pid is 16238
      Sep 14 13:36:22 raspberryDrei autossh[2125]: ssh exited with error status 255; restarting ssh
      Sep 14 13:36:22 raspberryDrei autossh[2125]: starting ssh (count 422)
      Sep 14 13:36:22 raspberryDrei autossh[2125]: ssh child pid is 16239

      Mit autossh connected sich der Remote Pi eigentlich immer wieder neu.
      hast du den Gateway Pi so vorbereitet, wie beschrieben? Damit wird sichergestellt, dass das Gateway nicht von sich aus (wg. Inaktivität) seine Arbeit einstellt.
      Schau mal, welche Meldungen Syslog zu „ssh“ ausspuckt und google nach dem Fehlercode.
      Gruß
      Chris

  11. Eigentlich hatte ich etwas anderes gesucht……
    Super, liest sich erst mal nach etwas das ich schon fast aufgegeben habe.
    Frage, ist es auch möglich ein am USB am Raspi angeschlossenes Gerät zu „Tunneln“ ? (es reicht wenn es bei mir ankommt NACHDEM es gesendet hat)
    Der Tunnel muß auch nicht allzulang sein, auf Wlan Wlan -mein anderer rechner- reicht.

    Danke

  12. Ich würde noch gerne wissen, ob Auf- und Abbau des Tunnels geloggt werden und wie ich den manuell auf- und abbauen könnte. Bspw. durch GPIO oder zeitgesteuert.
    Danke!

    1. Logging für den Aufbau des Tunnels geht z.B. so:

      Am Ende der Datei tunnel.sh z.B. noch folgendes einfügen

      if [[ $? -eq 0 ]]; then
      echo "tunnel started" >> tunnel.log
      else
      echo "An error occurred creating a tunnel to jumpbox. RC was" $?
      fi

      Du könntest dir auch einen String zusamemnbasteln und den in eine Datei schreiben. Mit Bash Scripten bin ich nicht so firm.
      SSH Zugriffe werden in der Datei /var/log/auth.log gespeichert. Die kannst du auch auf dem Remote Pi mit

      grep 'sshd' /var/log/auth.log

      auswerten.
      Wie du einen Abbruch des Tunnels loggst weiß ich allerdings auch nicht.

      Mit
      sudo killall autossh
      auf dem Remote Client kannst du den Tunnel auch wieder abbauen. Das Kommando kannst du natürlich auch ferngesteuert vom Gateway aus auslösen. Dann allerdings ist der Tunnel futsch bis jemand ihn manuell auf dem Remote Pi startet oder der Remote Pi neu bootet.

  13. Hallo,

    super Seite.

    Ich hatte damit folgendes gelöst:

    Auf einem Raspberry PI Smokeping und diesen per DHCP von „absolut unwissendem“ Nutzer in sein Netz setzen lassen. Dieser Raspberry baute dann einen SSH Tunnel zu einem Raspberry bei mir zu Hause auf. Tolle Sache. Ich konnte so „Netzstörungen“ im Netz des Bekannten protokollieren!

    Aber eine Frage habe ich:

    was genau sollte ich tun, wenn ich den Aufbau der Verbindung des SSH Tunnel NICHT mehr zulassen will. Reicht es den Public Key des Remote Raspberry auf dem Gateway Raspberry zu löschen.

    Eine Ergänzung hierzu in der Anleitung wäre schön. Denn alles was rein darf will man vielleicht auch einmal aussperren.

    Danke!!

    1. Hallo,
      Guter Hinweis. Werd ich nachtragen.
      Meines Erachtens reicht es, den Public Key des Remote Users am Gateway (steht in der Datei ~/.ssh/authorized_keys) zu löschen. Evtl noch das Passwort ändern, wenn es beim Einrichten offengelegt wurde.

  14. Hallo Chris,
    vielen Dank für die super Anleitung.
    Hat bei mir auf Anhieb funktioniert.
    Mein Problem ist jedoch, das ich unbedingt auch noch ein udp-Protokoll in den Tunnel bringen muss. Habe mich bei Google umgesehen und werde das mal mit socat probieren. Wenn Du jedoch dazu schon eine Lösung hast, wäre ich Dir für die Hilfe sehr dankbar.
    Bert

    1. Hi,
      freut mich, wenn ich dir helfen konnte. Leider bin ich nicht allzu firm mit den Protokollen. udp ist zwar so ähnlich wie TCP aber doch anders. SSH kann nur TCP. Meiner Meinung nach ,müsstest du die udp Messages in TCP verpacken, durch den Tunnel leiten und am anderen Ende wieder entpacken.
      Ciao
      chris

  15. Hi Chris,
    als Alternative zu einem reverse ssh tunnel empfehle ich ein leichtgewichtiges VPN mit tinc[1].

    einige Vorteile:
    – Der RemotePi verhält sich so, als wäre er im lokalen Netzwerk. Insbesondere sind alle Ports auf dem RemotePi direkt erreichbar, ohne weitere Konfiguration.
    – Es können einfach RemotePis oder GatewayPis hinzugefügt werden, RemotePis und GatewayPis unterscheiden sich nur durch die Existenz einer öffentlichen IP-Adresse.
    – Es dürfen alle bis auf einen GatewayPi ausfallen, ohne das Netz zu beeinträchtigen.
    – Es existieren Clients für Linux, Windows, Mac OS X und Android. Für jeden Host mit installiertem tinc sieht es so aus, als wären die Remote&GatewayPis im lokalen Netzwerk.

    Vorgehen:
    1. Konfiguration von tinc auf dem RemotePi
    2. Konfiguration von tinc auf dem GatewayPi (optional auch auf dem lokalen Rechner/Smartphone)
    3. Schlüsselaustausch (Verteilung der tinc-Keys, zb mit scp)
    4. Fertig 🙂

    Gruß, kerel

    [1] http://www.tinc-vpn.org/
    Ein how-to (english): http://xmodulo.com/how-to-install-and-configure-tinc-vpn.html

    1. Klingt interessant! Für den einen oder anderen sicher eine Alternative zum SSH Tunnel. Ich hab mir die tinc Seite mal angesehen und finde, dass das Konzept doch eher was für Leute mit guten bis sehr guten Admin Kenntnissen ist. Also eher nicht die Zielgruppe für mein Blog. Danke trotzdem für den Tipp!
      Chris

  16. Hallo Chris

    Danke für die Nachricht. Meine sshd_config ist seit dem 3 Feb. 20:03 im richtigen Verzeichnis??????!!!!!!.
    Zudem habe ich auf dem RemotePI seit 2 Tagen ein Programm am laufen welches mir die Temparatur über ein LCD anzeigt und die Werte in eine Datei schreibt. Bei Überschreitung der CPU Temparatur startet ein Lüfter für 15 Sekunden. Keine Unterbrechung in dieser Zeit. Daten werden angezeigt und alle 15 Sekunden gespeichert. Macht richtig Spass das mit dem RemotePI und Python.
    Werde gleich noch ausprobieren die Lüftergeschwindigkeit auszuwerten und ebenfalls abzuspeichern und dann zum GatewayPi übertragen.

    Gruß Herbert

  17. Ist der Schritt Schritt 2: Login ohne Passwort so richtig? Bei mir hat es erst funktioniert als ich es in die andere Richtung gemacht hatte…

    1. Den Schritt brauchst du, damit sich der Remote Pi, der den Tunnel aufbaut, automatisch beim Gateway identifiziert. Das Gateway KANN seinen Schlüssel beim Remote hinterlegen, muss aber nicht – vereinfacht lediglich den Login auf dem Remote Pi – ist aber für das Funktionieren des Tunnels nicht erforderlich.

    2. Sorry, stimmt natürlich alles. Kannst den Kommentar löschen. Hingegen ist oben ein Fehler, zumindest auf meinen raspberry liegt die sshd_config im Unterverzeichnis ssh
      sudo nano /etc/ssh/sshd_config

  18. Hallo Chris,

    danke für die super Anleitung!!
    Eine Frage; wenn ich mit einem weiteren Gerät beim Remote Pi kommunizieren möchte, also ein Gerät welches am selben Netzwerk wie der Remote Pi hängt, wie mache ich das? Port forwarding vom Remote Pi oder so?

    Danke,

    Reto

    1. Hallo,
      am einfachsten richtest du auf dem weiteren Gerät auch einen Reverse Tunnel (natürlich mit anderen Portnummern) ein.
      Oder du loggst dich auf dem Remote Pi ein und gehst dann von dort aus mit ssh auf das andere Gerät.
      Was auch geht – z.B. um auf die Admin Oberfläche des Remote Routers zu kommen – ist, die Installation von xrdp auf dem Remote Pi. Dann kannst du von einem PC im Gateway Netzwerk über den Windows Remote Desktop den grafischen Desktop des Remote Pi starten. Ist arschlangsam aber funktioniert recht zuverlässig.
      Was ich bisher nicht geschafft habe, ist eine verkettete ssh Verbindung Gateway–>Remote–>weiteres Gerät mit einem einzigen Befehl. Muss aber auch irgendwie funktionieren. Wenn ich mal mehr Zeit hab‘ dann versuch ich dafür auch ne Lösung zu finden.
      Viel Spaß
      Chris

            1. Hallo Reto,
              Wahnsinn. Ich habe lange danach gesucht, wie man das macht. Dabei ist die Lösung ganz einfach und so logisch. Ich werde mein Tutorial entsprechend erweitern!
              Danke
              Chris

  19. Hallo Chris

    Eine Frage zu der Verbindung der RemotePI mit dem GatewaPI zwecks Überprüfung ob überhaupt eine Verbindung zustande gekommen ist.
    Da ich ja beide PI’s noch zusammen hier stehen habe und somit auch auf Beide zugreifen kann ist es einfach den RemotePI neu zu starten falls ich über SSH keine Verbindung aufbauen kann. Nur könnte ich ein Programm erstellen welches den RemotePI dazu veranlasst den GatewayPI zu „Fragen“ ob er da ist?
    Falls nicht soll er dann einen Neustart einleiten.
    Bei mir ist es des natürlich schon einige Male vorgekommen das ich keine Verbindung hatte wobei ich noch nicht einmal weiss woran es lag. Aber in den meissten fällen nutzte ein Neustart des GatewayPI nicht sondern nur ein Neustart des RemotePI. Dieser aber soll ja weiter weg sein.

    Gruß Herbert

    1. Hallo Herbert,
      verwendest du autossh statt ssh? Wenn ja, brauchst du dir eigentlich um die Verbindung keine sorgen machen. Wenn die Verbindung einmal unterbrochen ist, startet autossh einen neuen Tunnel. Das kann unter Umständen mehrere Minuten oder manchmal auch Stunden dauern. Wenn du checken willst, ob der remote Pi überhaupt noch ins Internet kommt, kannst du dich an meinem Beitrag Hängenden Router automatisch rebooten orientieren.
      Um ganz sicher zu gehen, würde ich den Remote Pi sicherheitshalber einmal am Tag automatisch neu booten.

      1. Hallo Chris

        Ich bin davon ausgegangen das ich autossh verwende da ich in der tunnel.sh
        diesen Eintrag eingetragen habe.
        „/usr/bin/autossh -p2000 -fNC -R 10011:localhost:22 pi@dyn.IP.adresse
        Derweilen klappt ja zu 90% die Verbindung wenn ich ins Arbeitszimmer gehe und beide PI’s einschalte. Es kommt aber ab und zu vor das ich Versuchsschaltungen habe und dann merke das auf dem Display welches am RemotePI angeschlossen ist welches mir die Uhrzeit und die CPU Temperatur anzeigt dieser „eingefroren“ ist. Meine Verbindungen die über Putty dann zum RemotePI habe sind in diesem Fall dann auch „abgestürzt“.
        Der RemotePI selber läuft noch da ich mich ja, da dieser ja hier noch wegen den Versuchszwecken angeschlossen ist, über eine Tastatur und einen angeschlossenen kleinen TFT Monitor direkt anmelden kann. In diesem Fall kann ich z.B. über sudo reboot den RemotePI neu starten und brauch nicht die „harte Version“ einfach den Stecker ziehen anwenden. Ist dieser dann Neu gestartet komme ich über den GatewayPI oder Putty wieder auf den RemotePI.
        Wie ist das gemeint mit … Stunden dauern?. Deshalb war meine Frage ja ob der RemotePI nicht schauen kann , z.B. jede Stunde, ob er eine Verbindung zum GatewayPI hat und wenn nicht er selbständig ein reboot einleitet.
        Werde mir aber einmal Dein Link oben ansehen.

        Gruß Herbert

    2. Hallo Herbert,
      das sieht ganz danach aus, als ob die Internet Verbindung des Remote Pi abgeschmiert ist. Hast du ein Edimax WiFi Dongle unter Raspbian Wheezy angeschlossen? Da gibt es ein Problem, weil das Dongle gerne in Power Save geht und nicht mehr aufwacht. Ein Reboot hilft da naturgemäß als erste Hilfe – besser ist es ein paar Einstellungen zu ändern. Melde dich, wenn du hier eine Anleitung brauchst.
      Autossh macht eigentlich genau das, was du brauchst: prüft in regelmäßigen Abständen, ob die ssh Verbindung noch steht und baut dann bei Bedarf eine neue auf. Das geht natürlich nur, wenn der Pi überhaupt noch ins Internet kann. Schau dir mal die man Seiten von autossh an

      man autossh

      Deine gewünschte „Reboot wenn keine Antwort“ Lösung ist in meinem Beitrag Hängenden Router rebooten ganz gut beschrieben – etwas Transferleistung ist allerdings Voraussetzung.
      Grüße aus Oberbayern
      Chris

      1. Hallo Chris

        Ich benutze ein Huwai E173 UMTS Stick der an dem TP 3020 Router angeschlossen ist . Der Remote PI ist direkt über Kabel mit dem TP3020 verbunden.
        Wenn bei mir keine Verbindung zum RemotePI aufgebaut werden kann und ich somit über SSH und Putty keine Verbindung bekomme kann ich trotzdem direkt auf den RemotePI zugreifen da dieser hier noch steht . Auf der Oberfläche des RemotePI ist eine Internetverbindung vorhanden da ich ja ins WWW komme. Zu Deinen Link: Der RemotePI hat schon eine Schaltung die mir die Möglichkeit gibt mehrere Funksteckdosen zu schalten. Jetzt sehe ich mir erstmal Deinen PythonCode an wie ich Festellen kann das Dieser keine Verbindung zum GatewayPI oder keine Internetverbindung über UMTS hat.
        Danke und Gruß
        Herbert

        1. Hallo Herbert,
          wenn du die Diskussion mit Reto vielleicht mitgelesen hast: Meine Anleitung hatte einen „kleinen“ Fehler. Die Vorbereitung des Gateway Pi bzw. die Änderungen in der sshd_config (Abschnitt 1a) muss in der richtigen Datei erfolgen. Check doch mal ab, ob du auch wirklich die Datei /etc/ssh/ssh_config angepasst hast oder – wie es evtl. bei wortgetreuer Befolgung der Anleitung – die Datei /etc/sshd_config war, in die du die verlangten Parameter eingetragen hast. Andernfalls ist dein Reverse tatsächlich ziemlich instabil. also: bitte die Datei /etc/ssh/sshd_config wie folgt ergänzen: ClientAliveInterval 30
          ClientAliveCountMax 99999
          GatewayPorts yes
          AllowTcpForwarding yes
          Gruß
          Chris

  20. Guten Morgen Chris

    Derweilen habe ich weiter gesucht bekam aber bei dem Befehl:
    scp tt.txt -P22 pi@dyIP:~/home/pi/tt.txt

    den Fehler mit :
    ssh: connect to host port 22: Connection timed out
    lost connection

    In meiner FrixBox habe ich jetzt noch den Port 22 für den GatewayPI freigegeben und bekam beim gleichen Befehl oben:
    scp tt.txt -P22 pi@:~/home/pi/tt.txt

    Ausgabe:
    scp: /home/pi/home/pi/tt.txt: No such file or directory

    Diese Eingabe:
    scp tt02.txt pi@:/home/pi
    kopiert mir jetzt die Datei tt02.txt nach meinem GatewayPI.

    Werde jetzt Deine Antwort oben nach der Arbeit einmal in Ruhe genauer durchgehen.

    Gruß aus Dorsten
    Herbert

  21. Hallo Chrise

    Leider hat es damit nicht funktioniert.
    Ich hätte aber noch eine Frage zu Fillezilla.
    Wieso sieht es bei Filezilla so einfach aus Dateien zu kopieren?
    Dort kann ich vom RemotePI direkt über den GatewayPI zum WIN7 Rechner hin und her kopieren. Ich gebe oben ja eigentlich nur die DDNS des RemotePI ein und schon habe ich links meine WIN7 Seite und rechts meinen RemotePI.

    Gruß Herbert

    1. Hallo Herbert,
      ja das Command Line Interface (die klassische Shell) ist halt immer ein bisschen rätselhaft. Da haben tausende von Leuten Tools für geschrieben, deshalb gibt es häufig eine andere Syntax für die Befahle als man denkt. Aber bei Microsoft ist das auch nicht alles so einheitlich.
      Ich habe den Befehl jetzt nochmal ausprobiert und muss zugeben, dass ich da auch einen Fehler reingebracht habe. Korrekt muss das lauten:
      scp -P2022 quellpfadundquelldateiname pi@deinedynIP:zielpfadundzieldateiname
      also erst der Befehl, dann optional der Port mit großem P und dann Quelle und user@zieladresse gefolgt von einem Doppelpunkt und dem Pfad und dem gewünschten Ziel-Dateinamen. Gerde getestet. Klappt von Bayern aus auf einem Remote Pi in Italien eingeloggt, der die Datei wieder zu mir nach Hause schickt.
      Filezilla habe ich bisher nicht genutzt. Ich bin mit WinSCP voll zufrieden.
      Gruß
      Chris

  22. Hallo Chris

    Habe das mit der WebCam leider nicht hinbekommen. Zudem habe ich beruflich nicht viel Zeit gehabt und leider ja auch nicht die nötige Erfahrung. Aber wie heißt es “ Es ist nie zu spät und man lernt nicht aus“.
    Derweilen hatte ich auch noch festgestellt das beide PI’s in den letzten Tagen am laufen waren und somit die WebCam jede Bewegung in dem Raum aufzeichnete. Da kam was an Bildern zusammen. Da ich ja Motion am laufen hatte machte er aus diesen Bildern ein Film.
    Ist es nicht auch möglich z.B. das letzte Bild der Aufnahme in meine Homepage einzubinden und die Bilder zu meinen GatewayPI zu senden.
    Natürlich habe ich schon versucht die Bilder zu kopieren aber ich habe den richtigen Befehl nicht gefunden.
    Das hier ist der letzte Versuch um ein Bild vom RemotePI zum GatewayPI zu schicken:

    scp ~/tmp/motionCam0/06-20160121094834-03.jpg pi@MeineDDNS:22:~/home/pi/xxx.jpg

    Fehlermeldung:

    ssh: connect to host Meine DDNS port 22: Connection refused
    lost connection

    Danke und Gruß aus Dorsten
    Herbert

    1. Hi,
      du hast einen bzw. zwei Fehler im scp Kommando:
      probiers mal mit
      scp ~/tmp/motionCam0/06-20160121094834-03.jpg -P22 pi@MeineDDNS:/home/pi/xxx.jpg
      Die Portnummer ist, wenn du die Defaultnummer 22 verwendest, überflüssig. Ansonsten muss sie mit -P in das Kommando eingebracht werden. Dein Ziel Verzeichnis hast du doppelt gemoppelt. ~ ist ja schon das Homeverzeichnis vom Pi. Am sichersten ist es aber nach dem Doppelpunkt /home/pi/zielverzeichnis zu schreiben, dann gibts keine Missverständnisse. Gruß
      Chris

  23. Hallo Chris

    Danke für die Rückantwort.
    Die WEBCam hängt am USB HUB des RemotePI und wie erwähnt habe ich ja ein Bild wenn ich die WEB Seite im RemotPI Netzwerk aufrufe.
    Das hier ist mein Aufruf im Browser um meine Seite aufzurufen:
    http://myDynDNSAdresse:8000/gpio.php?S02_ALLE_AUS=Alle+AUS
    Hier habe ich gerade ALLE Funkschalter ausgeschaltet.
    Diese Adresse habe ich fest bei mir im Internetbrouwser gespeichert.
    Unter W7 wähle ich mich dann in eines von meinen beiden WLAN Netzen ein und rufe diese Seite dann auf. Beim RemotePI Netz habe ich dann ein Bild, aber im GatewayPI Netz an der Stelle des Bildes ein „kein Video“ stehen. Das hier ist die aktuelle Zeile für das Video:

    ich hatte auch an der Stelle der IP Adresse „192.168.0.4“ die „DynDNS“ stehen aber ohne Erfolg.

    Gruß Herbert

  24. Hallo Chris

    Ich habe eine erste WEBSeite auf dem RemotPI erstellt im Verzeichnis /var/www/.
    Diese kann ich nun von meinem Heimnetz vom Laptop, Tablet oder von meinem Handy aus aufrufen. Dort sind dann auch meine Schalter aufgebaut und diese Schalter können nun die vorhanden Funksteckdosen beim entfernten RemotePI über die GPIO und einem Funksendemodul ein und aus schalten.
    Auch ein Bild meiner Enkelkinder ist auf der WEBseite eingefügt zu sehen.
    Nur das Bild der Webcam wird nicht angezeigt.

    Gruß Herbert

    1. Hallo,
      na wenn du deinen Pi Remote über den Tunnel bedienen kannst, dann ist ja fast alles in Butter 🙂
      Wie bindest du denn die Webcam ein? Welches Programm verwendest du dafür?
      Ich habe mich als blutiger Anfänger seinerzeit an diese Anleitung gehalten: http://www.laub-home.de/wiki/Webcam_Snapshot_Skript
      Bei nicht bewegten Bildern besteht der Trick darin, die Webcam dazu zu veranlassen, ein Bild als JPG oder ähnliches zu erzeugen und auf der Karte abzulegen.
      Dieses wird dann über das html Tag img in die Website eingebunden. z.B. so: img src=“bild.jpg“ width=“800″ style=“border:5px solid #ffffff“. Das ist dann nicht anders, als bei dem Bild von deinen Enkelkindern.
      Du kannst mir den Code auch an folgende (Wegwerf-)Email Adresse schicken: 15e4d75b@opayq.com
      N.B. Diese Adresse existiert so lange ich es will und wird in dem Augenblick blockiert, wenn ich darüber zugespammt werde. Ich bin mit in Blogs veröffentlichten Adressen inzwischen sehr vorsichtig. Der von mir verwendete „Blur“ Dienst von abine.com ist übrigens ausgesprochen empfehlenswert.
      Grüße
      Chris

  25. Hallo Rustimator

    Das mit dem LM Rechner hatte ich nach kurzer Überlegung nicht versucht da Du recht hast. Ich bin soweit das ich die Verbindung stehen habe und den RemotePI jetzt entfernt stehen habe. Mein GatewayPI steht am Arbeitsplatz auf dem ich über SSH zugreife und von da wie von Dir erklärt auf den RemotPI. Wenn ich es richtig verstanden habe wäre es ja eigentlich umgekehrt das de RemotePI die Verbindung zum GatewayPI hält. Ich habe aber folgendes nicht verstanden. Wenn ich auf den RemotePI zugreifen will verbinde ich mich zuerst von meinem Laptop über Putty mit dem Gateway PI und von dort aus zum RemotePI. Möchte ich aber z.B. Daten austauschen mit dem RemotPI kann ich direkt bei FileZilla mich auf dem RemotPI einlogen. Warum brauche ich da nicht den GatewayPI?

    Grüße aus Dorsten Herbert

    1. Hallo Herbert,
      Weihnachtszeit, Bastelzeit…
      Bei einem Reverse Tunnel geht die Verbindungsaufnahme immer vom entfernten (Remote) Partner aus. Der legt gewissermaßen einen Klingeldraht zum Gateway. Dort muss man sich nur aufschalten, indem der richtige Port angesprochen wird.
      Brauchen tust du das nur, wenn du nicht direkt auf den Remote Pi draufkommst, z.B. weil er hinter einer Firewall liegt oder per Network Address Translation (NAT) verschattet wird. Da Remote ja normalerweise ohne weiteres ins Internet kommt, wird so die Firewall etc. einfach „durchbohrt“ bzw. „untertunnelt“.
      Liegen Remote und Gateway im selben Netzwerk, brauchst du das natürlich nicht; ebensowenig, wenn der Remote Pi aus dem Internet erreichbar ist. Bei Mobilfunk ist das aber i.d.R. nicht der Fall.
      Du kannst auch direkt via Putty auf den Remote Pi zugreifen, ohne erst eine Sitzung auf dem Gateway aufzumachen. Im Feld IP Adresse die (dyn)IP Adresse des Gateways eintragen und bei Port nicht die 22 sondern die vom Remote Pi definierte Portnummer eingeben. Das geht auch bei Verwendung von WinSCP oder FileZilla. Die Verbindung landet dann zwar erst auf dem Gateway, wird aber sofort weitergeroutet, ohne dass dort eine sichtbare Session läuft.
      So kannst du auch Webseiten auf dem Remote Pi direkt aus dem Browser ansprechen, indem du in die URL Zeile die (dyn)IP des Gateways einträgst gefolgt von einem Doppelpunkt und die definierte Portnummer für den Remote Pi Port 80. Das sähe dann ungefähr so aus:
      /usr/bin/autossh -p 2222 -fN -R 8888:localhost:80 pi@deine.dyn.IP Wenn du das von unterwegs aus dem Internet heraus über das Gateway zuhause machen willst, musst du logischerweise noch die entsprechende IP Adresse in deinem Router durchlassen. Für die Fritzbox hab‘ ich das in meinem Blog beschrieben.
      und im Browser die URL http://deine.dyn.IP:8888
      Lange Rede, kurzer Sinn: Dass du mit FileZilla direkt auf den Remote Pi kommst, liegt entweder daran, dass Remote und Gateway im selben Netz sind oder dass du in FileZilla (aus Versehen?) die passende Portnummer eingetragen hast. Mehr fällt mir momentan dazu nicht ein.

      1. Hallo Rustimator

        Danke für die Antwort.
        Zu meinem vorletzten Satz: „Möchte ich aber z.B. Daten austauschen mit dem RemotPI kann ich direkt bei FileZilla mich auf dem RemotPI einlogen“ diese Aussage von mir stimmt nicht. Wenn ich den GatewayPI ausgeschaltet habe klappt eine direkt Verbindung nicht. Ich weiss nicht wie ich dazu kam das zu meinen. Tut mir leid das ich etwas falsches verbreitet habe aber es ist so das ich bei FileZilla nicht ohne das der GatewayPI eine Verbindung bekomme.
        Jetzt werde ich aber einmal Deine Antwort in Ruhe nachgehen und versuchen das zu verstehen.

        Gruß aus Dorsten
        Herbert

        1. Hallo Herbert,
          denk‘ dir nichts. Ich habe auch einige Zeit gebraucht, das zu verstehen. Dann ging es mir wie dem „tapferen Schneiderlein“: Das war so stolz darauf, sieben Fliegen mit einem Streich erschlagen zu haben, dass er sich „7 auf einen Streich“ auf das Wams stickte.
          Auf heutige Zeiten übertragen, war ich so stolz darauf den Reverse Tunnel endlich kapiert zu haben, dass ich mein Blog damit angefangen habe.

          Gruß aus Oberbayern.
          Chris

          1. Hallo Chris

            Leider muss ich nochmals um Hilfe bitten da ich das mit der WEBCAM einfach nicht hinbekomme.
            Meine Installation sieht z.Z. so aus.
            1. Seite
            Mein GatewayPI ist direkt mit der FRitzbox 7490 verbunden. Mit meinen Laptop bin ich über SSH und Filezilla mit diesem verbunden.
            2. Seite
            Mein RemotePI ist über ein Netzwerkkabel mit dem TP Link 3020 verbunden. An diesem Router ist der UMTS Stick angeschlossen.
            An dem RemotPI ist zudem ein USB HUB mit der WEBCAM.
            Bis hier habe ich ja Deine Anweisung abgearbeitet und es klapp ja auch prima mit der Verbindung. Ich kann von meinem Laptop über den GatewayPI zum RemotPI zugreifen und die Schaltungen am GPIO Port schalten. Auch meine erste HTML/PHP Seite habe ich in Angriff genommen. Diese Seite hat z.B. sechs Button um zwei Funkschalter alleine und zusammen EIN und AUS zuschalten. Dort ist auch das WEBCAM-Bild eingefügt welches aber nicht angezeigt wird.
            Da ich mich aber auch mit meinem Laptop mich über das Netz des TPLINK 3020(RemotePI) einwählen kann sehe ich dann das WEBCAM Bild. Melde ich mich wieder in das FritzBox7490(GatewayPI)Netz habe ich ein Bildrand ohne Bild in dem kein Bild steht. Ich lasse also im Browser die Selbe Adresse, drücke auf „Aktuelle Seite neu laden“ und wechsel nur von GatewayPI Netz ins RemotePI Netz.

            Entschuldige, nachträglich wünsche ich allen noch ein gesundes erfolgreiches Jahr 2016

            Gruß Herbert

            1. Hallo Herbert,
              kein Problem… und keine Angst, das Thema scheint anfänglich etwas verworren, wenn mans dann aber kapiert hat, ist es eigentlich ganz einfach.
              Ich versuche das mal über eine Fallunterscheidung zu erklären, wobei für dich der zweite Fall am interessantesten sein dürfte.
              1. Im Netzwerk des Remote Pi TP Link Router möchte ich über einen im seben Netzwerk befindlichen Rechner auf den Webserver des remote Pi zugreifen.
              Remote Pi hat IP 192.168.0.50
              URL Eingabe in Browser auf Laptop http://192.168.0.50 ruft Website im Remote Pi auf. alles okay.

              2. Im Netzwerk des Gateway Pi möchte ich über einen im selben Netz befindlichen Laptop auf den Webserver bzw. eine dort liegende Website im Remote Pi zugreifen.
              Voraussetzung: Reverse Tunnel steht, Portadresse 80 (für http) des Remote Pi wird auf einen beliebigen Port (größer 1024 – hier z.B. 8000) des Gateway Pi getunnelt. Siehe auch Kapitel „Browsen im Tunnel“ meines Beitrags. z.B. durch /usr/bin/autossh -fN -R 8000:localhost:80 pi@dieDyn.IP.adresseDesGatewayNetzwerks. Außerdem ist der Port 22 im Router freigeschaltet und auf den Gateway Pi geroutet.
              Gateway Pi hat IP Adresse 192.168.178.20
              URL Eingabe in Browser auf Laptop http://192.168.178.20:8000 ruft Website im Remote Pi auf. alles okay. Wichtig ist es hier die Portnummer für den http Tunnel anzugeben, nicht etwa die Portnummer für den SSH/Putty Kanal.

              3. von Unterwegs möchte ich über das „freie“ Internet via Gateway Pi eine Website auf dem Remote Pi anzeigen.
              Voraussetzungen wie unter 2.
              Zusätzlich muss im Router noch die Portadresse 8000 freigeschaltet und auf den Gateway Pi umgerouted werden.
              URL Eingabe im Browser eines Smartphones: http://dieDyn.IP.adresseDesGatewayNetzwerks:8000 ruft Website im Remote Pi auf.

              Versuch anfänglich doch erst einmal eine ganz einfache „hello World“ Seite auf dem Remote Pi zum Laufen zu bringen. Wenn das funktioniert, den nächsten Schritt mit php und Webcam gehen. Was auch hilft, ist (wenn du einen Firefox Browser hast) ein Plugin namens Firebug, mit dem du deine html und PHP Seiten debuggen kannst. So kannst du schnell erkennen, ob irgend ein Link o.ä. nicht richtig funktioniert.

              Wenn ich mir mal deinen Code von der html/php Seite auf dem Remote Pi ansehen soll, gib mir Bescheid ich teile dir dann eine Email Adresse mit, an die du das schicken kannst.
              Gruß
              Chris

  26. Hello Tunnelbauer,
    Super Anleitung, danke vielmals! nach ein bisschen rumpröbeln hab
    ichs geschafft einen Reverse-Tunnel mit einem usb-getethertem Iphone
    hinzubekommen, soweit super!
    jetzt ist aber das problem aufgetaucht, dass wenn sich der Remote-Pi
    aus dem Ausland anmeldet kein Tunnel zustande kommt. ich vermute
    dass die Ports beim ausländischen Telco-Provider gesperrt sind…..
    habe dann Versucht einen Tunnel auf Port 443 oder Port 80 (die müssten sicher
    durchgeleitet werden) aufzubauen, macht aber ne fehlermeldung
    sudo ssh -o StrictHostKeyChecking=no -o „ServerAliveInterval 300“ -o UserKnownHostsFile=/dev/null -N -R 443:localhost:22 user@server
    Warning: remote port forwarding failed for listen port 443
    gibts eine Möglichkeit den Tunnel auf diese Ports zu legen?
    Keep up the good work!
    marcel

    1. Hallo Marcel,
      eigentlich sperren die Mobilfunk Provider wenn überhaupt nur VoIP Ports. In Italien nutze ich WIND (da geht sogar VoIP), aber auch TIM klappt wunderbar. Probier doch mal andere Portnummern. z.B. im Bereich 30000 bis 50000. Oder 8000, 8001, 8080 oder 8081 oder 8888. Von den standardisierten Ports von 0 bis 1024 würde ich die Finger lassen. Die darfst du eh nur als Superuser verwenden. Linux braucht eine ganze Reihe von denen für interne Funktionen und es kommt leicht zu Konflikten.
      Natürlich muss die verwendete Portnummer unbedingt in deinem Router freigeschaltet und auf den Gateway Pi geroutet sein (Port forwarding).
      Wenn du bei deinem Remote Pi im Ausland bist, kannst du das Setup auch ganz einfach testen: Dazu brauchst du einen Rechner, bzw. das Iphone mit dem du eine ssh Session (App dafür wird benötigt) zu deinem Gateway Pi zuhause aufmachst. Portadresse muss im Router auch noch zusätzlich durchgeroutet werden. Wenn du dich in deinen Gateway Pi eingewählt hast, kannst du so tun, als wärst du zu Hause. d.h. auf dem Pi eine SSH Tunnelsitzung mit dem gewählten Reverse Tunnel Port starten. Wenn alles klappt, kommst du auf dem Remote Pi raus.
      Generell ist das Iphone zu schade, um als permanent installierter Router beim Remote Pi zu dienen. Ein mobilfunkfähiger Router samt Internet Surfstick kostet nicht die Welt.
      Grüße und eine schöne Zeit

      1. Hi Rustimator,
        danke für Deine Ausführungen, hatte das ganze schon im betrieb, zuhause (schweizer gsm netz/lebara sim) gings wunderbar, und als das Ding in Italien war (gleiche sim, roaming eingeschaltet) wollts nicht. Das blöde ist halt dass ich nicht beim remote pi sein kann wenn er wieder unterwegs ist um ev. Netztwerksachen zu ändern…. (das Ganze ist im Rahmen eines Kunstprojektes manchmal unterwegs und leider sind Künstler meist nicht besonders Sysadmin-Affine 🙂 und muss darum DAU-Tauglich sein)
        Zum Iphone, musste ich nehmen, altes (4)Telephon vom Auftraggeber, war extrem nervend das usb-tethermässig zum laufen zu bringen (ich hätte ein billigen androiden genommen). Das Gute am Telephon, jeder kanns bedienen
        und am Hörerausgang hab ich Microcontroller der auf das richtige Klingelzeichen hört und dann ein Power-Cycle beim Remote-Pi macht. (falls sich das Teil mal hart aufhängt (könnte man natürlich mit einem Watchdog machen…)).

  27. Hallo Chris

    Auch ich habe es nach Deiner Anleitung versucht aufzubauen.
    Da ich ein Anfänger bin freue ich mich umso mehr das ich eine Verbindung herstellen konnte.
    Bei mir sieht es Hardwaremäßig so aus:
    Ausserhalb
    TP-Link 3020 mit UMTS, Stick daran ein Raspberry PI als RemotePI.
    Daran eine Relaiskarte und WEBCAM sowie ein Versuchsboard für Basteleien.

    Zuhause
    Fritzbox 7490
    RaspberryPi als GatewayPI
    Laptop mit WIN7 und LM17

    Über den Win7 Rechner und Putty habe ich jetzt zugriff zum GatewayPI.
    Bin ich auf diesem eingeloggt kann ich mich auf dem RemotePI einlogen und dort z.B meine Relaiskarte steuern.
    Nun hatte ich heute morgen LinuxMint17 gestartet und von dort mich über das Terminal zum GatewayPI verbunden. Von dort dann am RmotePI weiter.
    Jetzt meine Frage:
    Ist es möglich direkt von LinuxMint eine Verbindung zum RemotePI aufzubauen?
    In Deiner Anleitung erklärst Du:
    „Einen weiteren Raspberry Pi – oder einen (Linux) Rechner als Gateway, auf dem SSH läuft“
    SSH läuft ja sonst könnte ich mich ja nicht über das Terminal vom LM auf dem GatewayPI einloggen.
    Der Sinn ist ja einfach: Einen PI sparen und einen Linux Rechner habe ich ja.

    Danke und Gruß aus Dorsten
    Herbert

    1. Hallo! Freut mich, wenn meine Anleitung dir geholfen hat.
      In Anbetracht des supergünstigen Preises für den RaspberryPi (der brandneue RaspberryPi Zero kostet keine 15€ – bald bei Watterott). Braucht fast keinen Strom und behindert nicht das normale Arbeiten am PC. Außerdem kannst du ihn, da er dauernd laufen kann, auch als „von außen“ erreichbares Gateway verwenden. Überlegs dir… :-). Wie ich geschrieben habe, kannst auf dem Gateway Pi auch noch WordPress oder Owncloud installieren oder sonst irgend welche Applikationen. Der Gateway Pi langweilt sich sonst nur. Mein Blog hier läuft unter WordPress auf meinem Gateway Pi (ein Raspberry Pi 2 mit externer SSHD Festplatte) völlig problemlos.
      Ich bin kein Linux Experte…Trotzdem müsste es gehen, einen PC mit Linux Mint (nennen wir ihn LM) zum Gateway umzufunktionieren. Ich habe zwar einem Uralt Laptop mit Mint zu einem zweiten Leben verholfen, nur steht der jetzt im Ferienhaus und ich kanns nicht ausprobieren.
      Als erstes würde ich checken, ob LM überhaupt von einem anderen Rechner aus ansprechbar ist oder ob da ggf. noch ein Firewall im LM Zugriffe von außen verhindert. Das müsste man einstellen. Ferner weiß ich nicht ob auf LM auch der SSH Server läuft, das wäre im LM Terminal z.B. über top herauszufinden. Wenn in der Liste sshd steht, dann ja.
      Dann LM als Gateway genau so konfigurieren, wie in der Anleitung beschrieben. Raspbian und Linux Mint sind sich sehr ähnlich, ich weiß aber nicht, ob sshd_config auch unter /etc zu finden ist.
      Dann gemäß Anleitung weitermachen aber in deiner Fritzbox für Port 22 Weiterleitung (bzw. den Port, den du für den Pi verwendest) die IP Adresse des LM verwenden. In der Fritzbox auch bei der Netzwerkkonfiguration für den LM den Haken bei „Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen.“ machen.
      Das müsste dann funktionieren.
      Ich nehme an, du willst den LM immer nur anschalten, wenn du auch den Remote Pi zugreifen willst. So lange der LM ausgeschaltet ist, versucht der Remote Pi bzw. autossh immer wieder vergeblich eine Verbindung aufzubauen. Das gibt halt immer ein Paar Byte auf der Leitung. Ob es dadurch noch weitere Seiteneffekte gibt, kann ich nicht sagen.
      Ein zweiter Pi als Gateway wäre IMHO die bessere Lösung, wenn du über ein Bastelstadium hinausgehen willst.
      Grüße und viel Spaß
      Chris

      1. Hallo Chris

        Ich habe z.Z. Urlaub und mich in mein neu eingerichtetes Zimmer ehm. Kinderzimmer verschanzt. Dort steht jetzt alles aufgebaut rum.

        Somit kam der PI mir schon recht endlich etwas zu lernen was Spass macht.
        Das mit dem Preis ist nicht der Grund es auf dem Linux PC zu machen sonndern mehr als Lernspass und falls mal der GatewayPI keine Verbindung aufbaut einen zweiten Eingang zum PI. Da ich ja den RemotePI an einem TP3020 habe, bekomme ich von diesem Router z.Z. alle Stunde ein E-Mail das er noch Verbindung hat.
        Heute werde ich Versuchen das mit dem LM Rechner hinzubekommen.
        SDKarten habe ich genug und ich lege immer ein erweitertes Images des PI auf eine externe Platte so das ich immer zurückgreifen kann auf den letzten erfolgreichen Stand.

        Ich Danke Dir nochmals für die Zeilen und wünsche auch allen Lesern noch ein erfolgreichen Tag.

        Gruß aus Dorsten
        Herbert

  28. Vielen Dank, Super Beschreibung.

    Ich nutzte das an mein Kabel ipv6 Anschluss,
    um gleich mehrere reverse ipv4 Tunnel von mein V-Server zu mein interne PI auf zu bauen.
    Perfekt ! jetzt ist mein PI mit ipv4 (Handy, etc) wieder von außen erreichbar

    Danke für die Anleitung
    Gruß Michael

  29. Hallo,

    ist es möglich mit einem Befehl am RemotePI den ssh Tunnel wieder abzubauen.
    Da der Tunnel ja mit dem Kommando -fNC im Hintergrund gestartet wurde, kommt man nicht so einfach dran.

    Wie kann ich diesen Tunnel wieder beenden?

    Würde mich über einen Hinweis sehr freuen.
    Gruß
    Christian

    1. Hallo, spontan fällt mir dazu nur „killall “ ein.

      D.h. mit killall autossh und anschließend mit killall ssh den Tunnel abwürgen. Wenn du das über den Tunnel machst – also nicht direkt am Remote Pi – dann unbedingt erst autossh und dann ssh beenden.
      Ich bin mir ehrlich gesagt nicht ganz sicher ob man autossh überhaupt killen muss. Käme auf einen Versuch an.
      Gruß Chris

        1. Ah, okay. Ich dachte, dass ein noch aktives autossh vielleicht den Tunnel neu aufbaut. Freut mich, wenn ich dir helfen konnte.
          Chris

  30. Hallo zusammen, ich kann auch deutsch, bin aus der Schweiz

    Hi there
    i have a Huawei E303 and a Raspi B+ board powered with a samsung 2 Amp usb adapter.
    Everything works like charm. After the pi is it is automatically connected to internet. I need it to to a time lapse of my house build.
    Nowadays i had troubles with my autossh connection. Well it is establishing after the reboot and this is fine. I can connect with ssh -p 9091 pi@localhost without any problem.

    But sometimes it hangs to connect i do not know why. It is probably reestablishing. But in the last 6 days it workes very good and today i had several that i couldn’t connect to and had to wait for minutes to connect again…

    Even this morning when i want to connect to it it says:
    xxxxx@xxxxx-virtual-machine:~$ ssh -p 9091 pi@localhost
    ssh: connect to host localhost port 9091: Connection refused

    Somehow the autossh is not really reliable for me

    In messages i found the following:
    Can it be a power problem or what? Any clues?
    This is my sh script which will be executed after each reboot:

    #!/bin/bash
    sleep 20
    /usr/bin/autossh -fN -R 9091:localhost:22 -R 8080:localhost:80 username@host

    messages log:
    Jun 22 13:53:41 raspberrypi autossh[2715]: port down, restarting ssh
    Jun 22 13:53:41 raspberrypi autossh[2715]: starting ssh (count 8)
    Jun 22 13:53:41 raspberrypi autossh[2715]: ssh child pid is 6148
    Jun 22 13:57:44 raspberrypi kernel: [21436.669147] usb 1-1: USB disconnect, device number 32
    Jun 22 13:57:44 raspberrypi kernel: [21436.669171] usb 1-1.1: USB disconnect, device number 33
    Jun 22 13:57:44 raspberrypi kernel: [21436.669457] smsc95xx 1-1.1:1.0 eth0: unregister ’smsc95xx‘ usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet
    Jun 22 13:57:44 raspberrypi kernel: [21436.669540] smsc95xx 1-1.1:1.0 eth0: hardware isn’t capable of remote wakeup
    Jun 22 13:57:44 raspberrypi kernel: [21436.710226] usb 1-1.2: USB disconnect, device number 36
    Jun 22 13:57:44 raspberrypi kernel: [21436.710425] cdc_ether 1-1.2:1.0 eth1: unregister ‚cdc_ether‘ usb-bcm2708_usb-1.2, CDC Ethernet Device
    Jun 22 13:57:44 raspberrypi kernel: [21436.820820] usb 1-1.3: USB disconnect, device number 34
    Jun 22 13:57:44 raspberrypi kernel: [21436.989091] Indeed it is in host mode hprt0 = 00001501
    Jun 22 13:57:45 raspberrypi kernel: [21437.319109] usb 1-1: new high-speed USB device number 37 using dwc_otg
    Jun 22 13:57:45 raspberrypi kernel: [21437.319375] Indeed it is in host mode hprt0 = 00001101
    Jun 22 13:57:45 raspberrypi kernel: [21437.719452] usb 1-1: New USB device found, idVendor=0424, idProduct=9514
    Jun 22 13:57:45 raspberrypi kernel: [21437.719493] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
    Jun 22 13:57:45 raspberrypi kernel: [21437.720736] hub 1-1:1.0: USB hub found
    Jun 22 13:57:45 raspberrypi kernel: [21437.720961] hub 1-1:1.0: 5 ports detected
    Jun 22 13:57:45 raspberrypi kernel: [21438.009132] usb 1-1.1: new high-speed USB device number 38 using dwc_otg
    Jun 22 13:57:45 raspberrypi kernel: [21438.109498] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
    Jun 22 13:57:45 raspberrypi kernel: [21438.109541] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
    Jun 22 13:57:45 raspberrypi kernel: [21438.112813] smsc95xx v1.0.4
    Jun 22 13:57:45 raspberrypi kernel: [21438.181386] smsc95xx 1-1.1:1.0 eth0: register ’smsc95xx‘ at usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:84:c5:7c
    Jun 22 13:57:46 raspberrypi kernel: [21438.259156] usb 1-1.3: new high-speed USB device number 39 using dwc_otg
    Jun 22 13:57:46 raspberrypi kernel: [21438.365310] usb 1-1.3: New USB device found, idVendor=0951, idProduct=1665
    Jun 22 13:57:46 raspberrypi kernel: [21438.365351] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    Jun 22 13:57:46 raspberrypi kernel: [21438.365374] usb 1-1.3: Product: DataTraveler 2.0
    Jun 22 13:57:46 raspberrypi kernel: [21438.365392] usb 1-1.3: Manufacturer: Kingston
    Jun 22 13:57:46 raspberrypi kernel: [21438.365410] usb 1-1.3: SerialNumber: 00241D8CE480BF20A930289C
    Jun 22 13:57:46 raspberrypi kernel: [21438.366655] usb-storage 1-1.3:1.0: USB Mass Storage device detected
    Jun 22 13:57:46 raspberrypi kernel: [21438.368030] scsi host21: usb-storage 1-1.3:1.0
    Jun 22 13:57:46 raspberrypi kernel: [21438.764632] smsc95xx 1-1.1:1.0 eth0: hardware isn’t capable of remote wakeup
    Jun 22 13:57:47 raspberrypi kernel: [21439.382114] scsi 21:0:0:0: Direct-Access Kingston DataTraveler 2
    Log gekürzt

    1. Hi,
      Könnte auch daran liegen, dass sich dein wlan dongle schlafen legt. Hast das edimax dongle? Goggle mal nach edimax raspberry standby…
      Testweise den pi mit dem router über kabel verbinden, sofern möglich.
      Wenns dann stabil läuft, wars genau das standby problem. Deine Log kopie hab ich etwas gekürzt. Gruß Rustimator

      1. thx, aber ich habe einen Huawei E303 Stick. Es hat schon mal 6 Tage am Stück funktioniert. Aber jetzt macht es echt probleme. Auch auf dem Server sehe ich:
        tgdabfa1@tgdabfa1-virtual-machine:~$ netstat -an | grep „LISTEN “
        tcp 0 0 127.0.1.1:53 0.0.0.0:* LISTEN
        tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
        tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
        tcp6 0 0 :::22 :::* LISTEN
        tcp6 0 0 ::1:631 :::* LISTEN
        tgdabfa1@tgdabfa1-virtual-machine:~$ ps -ef | grep ssh
        root 1662 1 0 11:46 ? 00:00:00 sshd: tgdabfa1 [priv]
        tgdabfa1 1703 1662 0 11:46 ? 00:00:00 sshd: tgdabfa1@pts/6
        root 1816 1 0 11:57 ? 00:00:00 /usr/sbin/sshd -D
        tgdabfa1 1880 1704 0 12:01 pts/6 00:00:00 grep –color=auto ssh

        obwohl ich den tunnel so aufmache wie du:
        /usr/bin/autossh -p2000 -fNC -R 10011:localhost:22 pi@dyn.IP.adresse

        1. sorry kleine anpassung ich mach in mit 9091 auf
          /usr/bin/autossh -p2000 -fNC -R 9091:localhost:22 pi@dyn.IP.adresse

          dann müsste doch unter netstat -an | grep „LISTEN “ auf einen auf 9091 zuhören

          1. Hi,
            ich dachte das Huawei Teil wäre dein Router…

            Versuch mal folgendes:
            sudo nano /etc/network/interfaces
            Dort ans Ende schreiben: wireless-power off

            ggf hilft das ja. Ansonsten würde ich mir den Edimax Dongle EW-7811UN zulegen. Kostet keine 10€, zum Beispiel bei Amazon.
            dann wie in folgendem Artikel von RaspberryPi Spy vorgehen. Die Anleitung dort funktioniert für alle WiFi dongles mit Realtek RTL8192 Chipset. Vielleicht ist das auch in deinem Huawei Stick verbaut…
            Ich hatte mal ähnliche Probleme mit einem TP-Link Dongle, dass wahlfrei ein paar Stunden oder auch Tage lief um sich dann sang und klanglos zu verabschieden. Ich hab es dann gegen ein Edimax Teil getauscht.
            Gruß Chris

  31. Liebe Tunnelgemeinde !
    Ein „Newbie“ dankt herzlich für die tolle Gebrauchsanweisung zum Aufbau eines Reverse-SSH-Tunnels. Funktioniert wunderbar, allerdings kommen nach dem ersten Erfolg meine neuen „Begehrlichkeiten“ – ein SSH-Tunnel-Router:
    Was will ich: Ich möchte von Zu Hause aus über mein Netzwerk und dem angeschlossenen Gateway-Raspi (GPi) über den externen Remote-Raspi (RPi) mit 3G USB-Stick eine Beckhoff-SPS fernwarten: Folgende Topologie liegt vor:
    Laptop mit TwinCat im Heimnetzwerk – GPI – DSL-Router – RPi mit 3G-USB-Stick – Beckhoff SPS (CX8090).
    Den SSH-Tunnel habe ich mittels Port 2000 errichtet.
    Für TwinCAT (SPS-Verbindung) werden (angeblich) die Ports 48898(TCP), 48899(UDP) und 987(TCP) benötigt.
    Kann mir jemand mit dem atossh-Befehl beim Router (RPi) und dem ssh-Verbindungsaufbau am Gateway (GPi) helfen ?
    Muss die Gateway Adresse meines Laptops auf die des GPi gestellt werden ?
    Ich hab‘ schon einiges probiert, bisher ohne Erfolg.
    Danke im Vorhinein für Eure Tipps.

    1. Hallo Reinhold,
      erst einmal Danke für dein Lob. Freut mich, wenn meine Anleitung weiterhelfen konnte.
      Ich kenne mich mit SPS, TwinCat etc. nicht aus. Vielleicht kreist du die Lösung einmal wie folgt ein:
      Kommst du direkt mit dem Remote Pi auf die SPS drauf? Wenn ja, könntest du in einem ersten Schritt über das Reverse Tunnel auf den Remote Pi zugreifen und von dort aus (per Browser?) auf die SPS zugreifen.
      Der Remote Pi ist ein Endgerät. D.h. du kannst dich via Remote Tunnel drauf einloggen und dann Programme laufen lassen, Seiten von einem dort installierten Webserver abrufen oder per rdp auf dem Remote Pi einen Browser starten, der dann auf Komponenten innerhalb des Remote Netzwerks zugreift. Ich mache das, um z.B. auf den Router im Remote Netzwerk zuzugreifen.
      Es gibt sicher auch eine Möglichkeit ein „Doppel Tunnel“ aufzubauen (PC-GatewayPi-RemotePi-SPS) wobei die Pis eigentlich nur dazu dienen, Protokolle durchzureichen. Das übersteigt aber meine Möglichkeiten.
      Vielleicht beschreibst du das, was du vorhast noch etwas genauer. Ggf. gibt es ja einen unter den täglich 60-100 oder so Besuchern auf meinem Blog, der weiß, wie man so etwas bewerkstelligt.
      Grüße
      Chris

      1. Hallo Chris !
        Danke für Deine schnelle Antwort und Deine Tipps.
        Also bei meiner Anforderung sollen die beiden Pis rein zum „durchtunneln“ des Dienstes TwinCAT (es ist eine ADS-Kommunikation) sein.
        Am Desktop-PC zu Hause (IP 192.168.1.55, ADS 192.168.1.55.1.1) läuft TwinCAT.
        Die Verbindung sollte über den Gateway-Pi GPi (IP 192.168.1.81)
        per SSH-Reverse-Tunnel
        über den Heimrouter mit fester externer IP-Adresse zum entfernt liegenden
        Remote-Pi (interne IP 192.168.1.83) mit Internet-USB-Stick zur
        dort per Eth-Kabel angeschlossenen SPS (IP 192.168.1.58, ADS 192.168.1.58.1.1)
        gelangen.
        Es sind dafür nur 2 Ports zuständig:
        48898 TCP (für die Kommunikation)
        48899 UDP (für den ADS-Broadcastsearch).
        Wenn ich mich am Desktop-PC mittels Putty zum RPi anmelde, kann ich erfolgreich einen Ping an die SPS absetzen.
        Es wird wohl nur Deine 2. Möglichkeit des reinen Durchreichens der Protokolle funktionieren. Mir fehlt allerdings auch das Wissen und die Erfahrung für den Aufbau dieser Kommunikation.
        Ich denke, dass
        1. Auf der Seite des Gateways GPi (zu Hause) ich eventuell über Putty am Desktop-PC TwinCat dazu bwegen kann, die richtige (Broadcast-)Route zu beginnen.
        2. Auf der Remote-Seite glaube ich, dass ich den RPi zu einem Port-Forwarding zur SPS bewegen müsste, weiss aber nicht wie….
        Danke im Vorhinein für Eure wertvolle Zeit
        Reinhold

        1. Hallo Reinhold,
          ich kann dir momentan nur ein paar Tipps geben, wie du dein Problem lösen kannst.
          du brauchst in jedem Fall eine Tunnel Lösung, da du ja weder auf dem Gateway noch auf dem Remote Pi irgendwelche Eingaben machen kannst/willst.
          1. die von dir benötigten Portadressen solltest du gemäß Anleitung im Remote SSH Tunnel angeben.
          2. dann suche mal bei DuckDuckGo (oder meinetwegen bei Tante Google) nach dem Begriff „multitunnel ssh“ oder auch „multi hop ssh“
          3. ich habe das hier gefunden, was recht schlüssig und nicht zu kompliziert klingt: http://blog.remibergsma.com/2013/05/28/creating-a-multi-hop-ssh-tunnel-by-chaining-ssh-commands-and-using-a-jump-host/

          Ich werde mal auf meiner Seite versuchen, über eine solche verkettete SSH Verbindung direkt auf den Webserver im Remote Router zuzugreifen. Das kann ich aber erst kommendes Wochenende ausprobieren, wenn mich die Familie lässt.
          Gruß
          Chris

  32. Hallo Chris,
    vorschlagsgemäß habe ich den Eintrag im RemotePi wieder zurückgestellt auf

    autossh -p2000 -fNC -R 10011:localhost:22 pi@dyn.IP.adresse

    und dafür die Datei /etc/ssh/sshd im GatewayPi um die Parameter

    ClientAliveInterval 30
    ClientAliveCountMax 99999
    GatewayPorts yes
    AllowTcpForwarding yes

    ergänzt und alles läuft völlig problemfrei – d.h. ich habe einige Seiten der BILD.de (als Testfall) damit gelesen – die Kommunikation des RDPX über den SSH Reverse Tunnel ist und bleibt absolut stabil.

    Grüße aus Wien
    Hannes

  33. Hi Chris!
    Ich habe die RDP Funktion im RemotePi nochmals ausfürlich getestet. Der bis jetzt härteste Test war einfach der Aufruf der BILD (die Onlineseite der besagten deutschen [Großformat]Zeitung) mit dem WebBrowser, dabei ging die autossh Verbindung in einen Hängezustand über, d.h. diese Seite konnte nie vollständig geladen/angezeigt werden. Einfachere Webseiten zeigen dieses Verhalten dagegen nicht. Das hat mit den default Einstellungen von autossh zu tun. Aber es gibt eine Abhilfe dazu, damit läuft auch dieser (ich gebe zu ein etwas spezieller) Betriebsfall 😉 ohne Probleme.

    Ergänzung der autossh Kommandozeile (aus deinem Beispiel)
    autossh -p2000 -fNC -R 10011:localhost:22 -o „ServerAliveInterval 60“ -o „ServerAliveCountMax 3“ pi@dyn.IP.adresse

    Schöne Weihnachtzeit!
    Gruß
    Hannes

    1. Hi,
      hey prima. Ich hatte diese Probleme bisher nicht. Ich glaube auch, dass du denselben Effekt erreichst, wenn du die Befehle analog auf dem Gateway in die Datei /etc/ssh/sshd_config einträgst. Anstatt Server.. einfach Client.. eintragen. Der entsprechende Bereich sieht bei mir wie folgt aus:

      ClientAliveInterval 30
      ClientAliveCountMax 99999
      GatewayPorts yes
      AllowTcpForwarding yes

      So hatte ich bei mir kaum Probleme, auch bei längeren Sitzungen und großen Datenmengen nicht.

      Frage: könntest du das mal bei dir ausprobieren und mir Rückmeldung geben? Dann würde ich das in meine Anleitung übernehmen.

      Gruß & schöne Feitertage
      Chris

  34. Hi Chris,

    Mit Hilfe eines Portscanners im LAN
    http://www.radmin.com habe ich analysiert welche Ports im LAN bei beiden Pi’s offen sind. Tatsächlich waren im GatewayPi die Ports 22 und 40430 offen, beim RemotePi die Ports 22,3389 und 8082. Damit war klar, die Ports für das SSH Reverse Tunneling waren zu. Nach vielen Googlesuchanfragen habe ich die Antwort zu meinem Problem gefunden. Eigentlich ist die Lösung ganz einfach…

    http://www.alexonlinux.com/reverse-ssh-tunnel-or-connecting-to-computer-behind-nat-router

    Es fehlt der Eintrag „GatewayPorts yes“ im GatewayPi !

    GatewayPi:
    sudo nano /etc/ssh/sshd_config

    Einfügen des Textzeile „GatewayPorts yes“ am Ende des Files sshd_config
    abspeichern mit CNTL-O,Verlassen des Editors mit CNTL-X

    sudo /etc/init.d/ssh restart
    sudo reboot

    RemotePi:
    sudo reboot

    Im RemotePi wieder den SSH Reverse Tunnel eingeben
    ssh -p 40430 -fN -R 40431:localhost:3389 40432:localhost:8082 40433:localhost:22 pi@192.168.0.28

    Ein nochmaliger Test mit dem Portscanner zeigt, dass jetzt am GatewayPI alle relevanten Ports OFFEN sind – Port 22,40430,4041,40432 und 40433
    UND alle Anwendungen funktionieren PERFEKT!

    Von WinPC mit PuTTY auf GatewayPI verbinden d.h. 192.168.0.28:40433 – LÄUFT!

    Von WinPC aus RemoteDesktopVerbindung auf GatewayPI verbinden d.h. 192.168.0.28:40431 – LÄUFT!

    Von WinPC mit Firefox auf GatewayPI verbinden d.h. 192.168.0.28:40432 – LÄUFT!

    Vielen Dank für deinen Support!

    Grüße Hannes

    1. Hi Hannes,
      freut mich, dass das geklappt hat und dass ich dir zumindest etwas helfen konnte. Ich ahbe bei mir nachgeschaut, mein Gateway Pi hat tatsächlich GatewayPorts yes eingestellt gehabt. Meine 4 anderen Pis nicht… ich erinnere mich aber nicht daran, das irgend wann einmal eingestellt zu haben. Der Eintrag befindet sich auch mitten in der Datei. Sei’s drum. Ich werde meine Anleitung entsprechend erweitern. Again what learned 🙂 !

  35. Hi Chris,
    ich habe alles gemacht, was du hier vorgeschlagen hast:

    RemotePi und GatewayPi – beide
    sudo reboot (Neustart)

    RemotePi
    ssh-key (Schlüssel erstellt, default Filename, KEINE Passphrase)
    in .ssh wurden 2 Files erstellt: id_rsa id_rsa.pub

    ssh-copy-id -i ~/.ssh/id_rsa.pub „-p 40430 pi@192.168.0.28
    in GatewayPi .ssh wurde ein neues File erstellt: authorized_keys

    ssh -p 40430 -fN -R 40433:localhost:22 -R 40431:localhost:3389 -R 40432:localhost:8082 pi@192.168.0.28
    dieser Befehl wurde ohne Eingabe eines Passwortes vom GatewayPi verarbeitet,
    was ich so interpretiere, dass die Übertragung der PublicID (PublicKey) des
    RemotePi auf den GatePi fehlerfrei funktioniert hat.
    Für mich hat der Aufbau des SSH Tunnels somit fehlerfrei funktioniert…

    GatewayPi
    keine weiteren Einstellungen

    Test-> Von WinPC aus RemoteDesktopVerbindung auf GatewayPI verbinden d.h. 192.168.0.28:40431
    keine Verbindung, dabei sollte doch der Zugriff mit 40431 auf 3389 gewandelt und
    an RemotePi weitergeleitet werden.
    Gegenprobe -> Von WinPC aus RemoteDesktopVerbindung auf RemotePI verbinden d.h. 192.168.0.55
    Alles läuft super!

    Test-> Von WinPC mit Firefox auf GatewayPI verbinden d.h. 192.168.0.28:40432
    keine Verbindung, dabei sollte doch der Zugriff mit 40432 auf 8082 gewandelt und
    an emotePi weitergeleitet werden.
    Gegenprobe -> Von WinPC mit Firefox auf RemotePI verbinden d.h. 192.168.0.55:8082
    Camerabild ist innerhalb einer Sekunde sichtbar-alles läuft super!

    GatewayPi
    ssh -p 40433 localhost
    pi@localhost’s password: Eingabe des PW vom RemotePi

    Begrüßungstext von RemotePi Terminalfenster
    Linux raspberry 3.12.28+ vom 8.Sept 2014 …..

    exit
    logout
    Connection to localhost closed
    Rückkehr zum GatewayPi Terminalfenster
    Normaler Betrieb möglich

    Test-> Von WinPC mit PuTTY auf GatewayPI verbinden d.h. 192.168.0.28:40433
    keine Verbindung, dabei sollte doch der (remote) Zugriff mit 40433 auf 22
    gewandelt und an RemotePi weitergeleitet werden.
    Gegenprobe1 -> Von WinPC mit PuTTY auf GatewayPI verbinden d.h. 192.168.0.28:40430

    alles läuft super, nach einem Augenblick kommt das Terminalfenster zum
    Einloggen!
    Gegenprobe2 -> Von WinPC mit PuTTY auf RemotePI verbinden d.h. 192.168.0.55:22
    alles läuft super, nach einem Augenblick kommt das Terminalfenster zum
    Einloggen!

    Durch einen unbekannten Umstand wird der Zugriff auf den GatewayPi mit den im SSH Tunnel festgelegten Ports (40431, 40432, 40433) nicht an den RemotePi weitergeleitet. Jetzt macht sich langsam aber leichte Verzweiflung breit ;-((((, was könnte ich noch versuchen?

    lg Hannes

    Anmerkung:

    GatewayPi ist ein Raspberry2 mit 2 USB Anschlüsse und etwas älterer Linux
    Version für Raspberry – Linux raspberry 3.6.11+ vom 30.Aug 2013 …..

    RemotePi ist ein Raspberry2+ mit 4 USB Anschlüsse und der aktuellen
    Version für Raspberry – Linux raspberry 3.12.28+ vom 8.Sept 2014 …..

    Dieser Unterschied sollte aber keine Rolle spielen….

    1. Hallo Hannes,
      hmmm schwierig. Ich würde zu aller erst einmal beide Pis auf den neuesten Stand bringen mit
      sudo apt-get update und dann
      sudo apt-get upgrade
      Das ssh Paket ist zwar ausgereift und hat sich wahrscheinlich kaum verändert, trotzdem ist es wichtg upzudaten, damit andere Faktoren ausgeschlossen werden. Nach Upgrade neu booten
      Dann würde ich einen Schritt nach dem anderen gehen und mich so durchhangeln:
      Zuerst einmal den Remote Desktop via Reverse Tunnel zum Laufen bringen:
      Also auf dem Remote Pi den Reverse Tunnel der einfachsten Art starten – ohne alternativen ssh Port.
      ssh -fN -R 40431:localhost:3389 pi@192.168.0.28
      Da du ja schon die ID kopiert hast, müsste das ohne Passwort klappen.
      Als ssh Port des Gateways muss 22 erlaubt sein.
      Dann mit der Windows Remotesktop Verbindung auf dem PC mit dem Remote Pi via Gateway verbinden.
      Dabei die Adresse des Gateways mit der definierten Portnummer, also 192.168.0.28:40431 eingeben.
      Dann müsste der Remote Desktop aufgebaut werden.

      Troubleshooting:
      Jedes Mal, wenn bevor du einen neuen Tunnel aufbaust, den Remote Pi booten damit der alte tunnel abgebaut wird und keine Portadressen blockiert.
      Versuch mal einen reinen ssh Tunnel ohne Zusatzfunktionen aufzubauen (also auf den Remote Pi z.B.
      ssh -fN -R 10011:localhost:22 pi@192.168.0.28 eingeben)

      Dann mit Putty vom PC aus via Gateway auf dem Remote Pi einloggen. Adresse 192.168.0.28, Port 10011, Connection Type ssh. Geht das?
      Wenn nein, auf dem Gateway Pi versuchen, mit ssh -p 10011 localhost eine Verbindung zum Remote aufzubauen. Geht das?
      So kannst du wenigstens fesstellen, welcher Teil in der Kette versagt.

      Zusätzlich einmal auf dem Remote Pi mit cat /var/log/auth.log die Zugriffe auf den Pi ansehen. Ganz unten in den letzten Zeilen müsste etwas der Art Dec 15 15:27:24 raspberryPi sshd[5603]: pam_unix(sshd:session): session opened for user pi by (uid=0) stehen. ggf. steht da oder eine Zeile darüber noch eine Fehlermeldung, die weitere Hinweise gibt.

      Ich würde anstatt der 40431 auch einmal eine andere Portnummer probieren (ist ja wahlfrei so lange >1024) z.B. 8000 oder so.

      Checken, ob du irgend eine Firewall auf dem Remote Pi aktiviert hast (z.B. fail2ban).

      So mehr weiß ich auch nicht. Außer, in allerletzter Konsequenz nochmal beide Pis komplett neu aufsetzen und von vorne anfangen. Good luck.
      Gruß aus Oberbayern.
      Gruß
      Chris

  36. Eine kleine Story zum Hintergrund der obigen Problembeschreibung:
    In einem kleinen Haus im Ausland habe ich einen ADSL Internetanschluss/Router mit dahinterliegendem LAN. In diesem LAN befinden sich neben weiteren Netzwerkteilnehmern 2 Stück IP Cameras beide ausgeführt mit RaspberryPi und USB Cam. Um auf die Cams zugreifen zu können – muss unbedingt eine Portforwardingfunktion für 2 Ports im Router eingetragen sein. Das funktioniert in der Regel auch ganz gut. Leider verschwinden gelegentlich die Portforwardingeinträge aus völlig unerklärlichen Gründen und daraufhin gibts es dann für mich unfreiwillig eine Aktion „dunkler Bildschirm“ einer oder beider Cams. Die Wiedereinstellung konnte bis jetzt nur händisch gemacht werden indem hilfsbereite Leute mit Laptop zum Haus fahren, sich in das LAN einklinken und mir über Teamviewer einen Zugriff auf den ADSL Router aus dem LAN heraus ermöglichen. Dann ist es ein leichtes Unterfangen sich in den ADSL Router einzuloggen und die Einstellungen zu reparieren – eine Sache von Minuten und die Cams sind wieder super sichtbar ….

    Auf den ADSL Router von aussen zuzugreifen um in der internen Konfiguration etwas zu tun/ändern ist leider aus technischen Gründen nicht möglich, d.h. der Internetprovider lässt das nicht zu.

    Ein RemotePi im LAN mit Reverse SSH Tunnel mit rdpx Server (und weil das so nebenbei noch leicht möglich ist noch eine weitere remote CamFunktion)
    wäre daher für mich ideal um bei Bedarf den ADSL Router von der Ferne zu „reparieren“ ohne wieder Leute bitten zu müssen mit Laptop zum Haus zu fahren etc. etc. …

    Hannes

    1. Hallo,
      ich habe mir versuchsweise xrdp installliert und hatte Erfolg.

      Ansonsten bin ich wie folgt vorgegangen:
      Zum Verbinden im lokalen Netz (also nicht von außen) auf dem Remote Pi folgendes Kommando in eine Zeile eingeben

      ssh -p2000 -fN -R 40431:localhost:3389 pi@gateway.IP.adresse

      die 2000 ist der von mir gewählte SSH Port des Gateways. kann auch weggelassen werden, dann wird defaultmäßig die 22 genommen. Die 22 muss natürlich noch erlaubt sein. Zum Testen würd ich erst mal keine abweichende ssh Portadresse nehmen.

      Sicherheitshalber den Remote und den Gateway Pi vorher mit sudo reboot booten, damit keine alten ssh Sessions noch die Ports belegt haben.
      Public ID des Remote Pi muss wie oben beschrieben auf den Gateway Pi kopiert werden. Am Gateway Pi muss dann nichts mehr eingestellt werden, wenn die ssh Portadresse einmal konfiguriert ist.
      Jetzt müsste der Tunnel Aufbau vom Remote Pi aus hoffentlich geklappt haben.
      Der Gateway Pi lauscht jetzt auf Port 40431 und schickt alles, was da ankommt an den Port 3389 des Remote Pi weiter.
      Vom PC (im lokalen Netz) die Remotedesktopverbindung aufrufen und die IP Adresse des Gateway Pi eingeben gefolgt von einem Doppelpunkt und der Nummer 40431. Es kommt eine Warnmeldung, die wird bestätigt und los gehts.

      Das ganze geht sogar von außen: Remote Pi im Ferienhaus, Gateway Pi daheim und der PC woanders. Hierzu brauchst du eine dynamische IP Adresse, aber die brauchst du für deinen Use Case sowieso. Ferner muss dein Router zuhause die ssh Portadresse (jetzt macht es Sinn, die zu ändern) und die xrdp Adresse (40431) durchlassen.
      In der Remote Desktopverbindung gibst du dann DeineDynIPAdresse:40431 ein.

      Ich hatte den Zugriff auf den Router im Ferienhaus bisher etwas umständlicher mit VNC realisiert. Aber xrdp ist wesentlich eleganter, danke für den Tipp!

      Bzgl remote Cam Lösung: Anstatt einer USB Kamera würde ich empfehlen, die Pi Cam zu verwenden, die macht wesentlich bessere Bilder. Guggst du hier: http://rusticam.eu

      Grüße
      Chris

  37. Die Anleitung zum Einsatz von Reverse SSH Tunnel mit Remote Pi und Gateway Pi ist wirklich gut gemacht. Ich habe einen PC (Win7) und 2 Raspberries im LAN (als Teststufe) und diesen
    Reverse Tunnel nachgebaut und alles funktioniert, wobei ich das Beispiel „Browsen im Tunnel“ mangels Webserver auf dem Remote Pi nicht ausprobiert habe.
    Stattdessen wollte ich in Analogie einen Zugriff vom PC mit Win7 auf einen rdpx Server und motion Server im Remote Pi versuchen, bin aber dabei gescheitert.

    Nun der Reihe nach:
    IP im Lan: RemotePi 192.168.0.55 (Raspberrypi2Plus, alles an Update, Upgrade und Raspi-Config erledigt)
    IP im Lan: RemotePi 192.168.0.28 (Raspberry2, alles an Update, Upgrade und Raspi-Config erledigt)

    Portfestlegung:
    40430 Tunnelport RemotePi zu GatewayPi
    40431 rdpx Port GatewayPi zu RemotePi (wird hier zu Port 3389)
    40432 motion/ip Cam Port GatewayPi zu RemotePi (wird hier zu Port 8082)
    40433 SSH Port GatewayPi zu RemotePi (wird hier zu Port 22)

    RemotePi: Zugang mit PuTTY /login: pi, password …alles okay
    RemotePi: [pi@raspberrypi2plus cmd: sudo apt-get install xrdp ] … Installation eines RDP Servers
    Test: Zugriff von PC Win7 mit RemoteDesktopVerbindung auf RemotePi (hier IP 192.168.0.55, Standardport 3389) – funktioniert einwandfrei -> Raspberry GUI

    RemotePi: [pi@raspberrypi2plus cmd: sudo apt-get install motion ]
    Installation und Konfiguration einer IP Cam Applikation mit USB Camera mit Zugang über Port 8082
    Test: Zugriff von PC Win7 mit Firefox auf RemotePi (hier http://192.168.0.55:8082) – funktioniert einwandfrei – Camerabild wird im Browser angezeigt

    GatwayPi: Zugang mit PuTTY /login: pi, password …alles okay
    Erweiterung des SSH Port 22 mit Port 40430 laut ssh-portadresse-andern

    Neustart mit [pi@raspberrypi cmd: sudo reboot]

    GatwayPi: Zugang mit PuTTY über Port 40430 /login: pi, password …alles okay

    Einrichten eines SSH Reverse Tunnels im RemotePi [pi@raspberrypi2plus cmd: ssh -p40430 -fN -R 40433:localhost:22 pi@192.168.0.28 ]
    pi@192.168.0.28’s password: …Eingabe des PW …alles okay (Verbindung steht)

    GatewayPi: [pi@raspberrypi cmd: ssh -p 40433 localhost ]
    pi@localhost#s password: …Eingabe des PW

    Übergabe des Terminalfenster von RemotePi an GatewayPi —>

    Linux raspberrypi2plus 3.12.28+ #709 PREEMPT Mon Sep 8 15:28:00 BST 2014 armv6l

    The programs included with the Debian GNU/Linux system are free software;
    the exact distribution terms for each program are described in the
    individual files in /usr/share/doc/*/copyright.

    Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
    permitted by applicable law.
    pi@raspberrypi2plus ~ $ ….

    1) Versuch die Camerafunktion von RemotePi durch Tunnel anzusprechen

    RemotePi: [pi@raspberrypi2plus cmd: ssh -p40430 -fN -R 40432:localhost:8082 pi@192.168.0.28 ]
    pi@192.168.0.28’s password: …Eingabe des PW …alles okay (Verbindung steht)
    Test: Zugriff von PC Win7 mit Firefox auf GatewayPi (hier http://192.168.0.28:40432) –> KEINE ANTWORT

    Test: DIREKTER Zugriff von PC Win7 mit Firefox auf RemotePi (hier http://192.168.0.55:8082) – funktioniert einwandfrei

    2) Versuch RemoteDesktopverbindung von PC(Win7) auf RemotePi durch Tunnel

    RemotePi: [pi@raspberrypi2plus cmd: ssh -p40430 -fN -R 40431:localhost:3389 pi@192.168.0.28 ]
    pi@192.168.0.28’s password: …Eingabe des PW …alles okay (Verbindung steht)
    Test: Zugriff von PC Win7 mit RemoteDesktopverbindung auf GatewayPi (hier Computer 192.168.0.28:40431) –> KEINE VERBINDUNG ERREICHBAR

    Test: DIREKTER Zugriff von PC Win7 mit RemoteDesktopverbindung auf RemotePi (hier Computer 192.168.0.55:3389) –> funktioniert einwandfrei -> Raspberry GUI

    Muss ich im GatewayPi zusätzlich etwas oder anders einstellen? oder wo könnte der Fehler liegen?
    Wer hätte eine Idee?
    Danke!

    Hannes

  38. „FEHLER: Bei deinem Kommentar scheint es sich um Spam zu handeln. Spam können wir hier überhaupt nicht leiden.
    Bitte gehe nochmal zurück und versuche, etwas Sinnvolles zu sagen.“

    Sorry, nachdem mein Komentar als SPAM erkannt wurde, aber mit Sicherheit kein unerwünschter Inhalt ist habe ich meine Anfrage in eine einfache Webseite eingetragen – ich bitte um Beachtung, Danke!

    Meine Anfrage/Kommentar

    1. Hallo Hannes,
      tut mir leid, dass dein Post nicht durchgegangen ist. Ich werde mal bei den Leuten von WP-Spamshield nachfragen, warum da ein False Positive aufgetreten ist. Möglicherweise liegt es an den vielen bash Befehlen? Mal sehen.
      Dein Thema klingt recht kompliziert. Da muss ich etwas hirnen.
      Mit rdpx hab‘ ich auch noch nicht gearbeitet.
      Ich hoffe, dass ich mir das dieses Wochenende etwas genauer ansehen kann. Bin aber auch nur Hobbyist und war so stolz auf meine Lösung (nach mehrmonatigem Probieren), dass ich den Post geschrieben habe, um Anderen mit einem ähnlichen Problem etwas Arbeit abzunehmen.
      Gruß
      Chris

    2. Hi,
      ich habe deinen Post von der Website kopiert und versuchshalber noch einmal gepostet. Kam durch ohne Probs.
      WP Spam Shield prüft, ob der User Javascript und Cookies aktiviert hat. Da dein zweiter Post ja durchgegangen ist, hattest du beides wohl aktiviert. Zusätzlich macht WP Spam Shield noch ein paar Berechnungen in Bezug auf die IP Adresse. Vielleicht lags ja daran.
      Vielleicht magst du mir deinen ersten Post nochmal eintragen. Ich schalte den Debugger aktiv, vllt. findet sich ja was.
      Gruß
      Chris

  39. Dein Gedankengang ist fast richtig. Der Superuser darf alles.

    Allerdings ist das hier nicht ganz Zielführend. Du willst dein Script nicht als Superuser starten, was du implizit durch das sudo sagst. Allerdings darf über Crontab jeder Benutzer EIGENE Cronjobs anlegen. Wenn du nun das sudo weglässt legst du einen cron für den User Pi an.

    sudo Crontab entspricht in etwa dem dass du dich als root anmeldest und Crontab ausführst. Es kommt immer auf die Prozesse an die gestartet werden sollen, und mit welchen rechten diese laufen sollen. Hier kann das sudo unter Umständen zu einem Sicherheitsproblem werden, da die gestarteten Scripte mit ROOT-Rechten gestartet werden.

    Gruß,
    Bastian

  40. Wenn du das sudo vor crontab weglässt, wird der cron auch für den richtigen user erstellt. Mit sudo wir der cron für root erstellt!

    1. Hallo Bastian,
      zunächst einmal vielen Dank für den ersten „richtigen“ Komentar in meinem Blog!
      Bisher dachte ich, dass der Superuser alles darf, d.h. auch den eigentlich den „Pi“ gehörenden Tunnel aufbauen. Bei meinen anderen Raspis geht das ja auch genau so – sudo crontab -e
      Mein Workaround ist momentan genau der, dass ich den Tunnel über die crontab des Users „Pi“ aufbauen lasse.
      Danke jedenfalls. Ich komm schon noch drauf.
      Grüße
      Chris

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Wordpress Anti-Spam durch WP-SpamShield