Reverse SSH Tunnel – Schritt für Schritt

Warum brauch‘ ich das?

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.
    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.

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 vorhern 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 demn 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!

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.

 

 

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

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

Schreibe einen Kommentar

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

Wordpress Anti-Spam durch WP-SpamShield