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. 

Dieser Beitrag ist zwar schon ein paar Jahre alt; ich aktualisiere ihn aber laufend nach Erkenntnisfortschritt oder bei Änderungen im Raspberry Pi OS (ehemals Raspbian):

Eingerückte Texte sind zusätzliche Erklärungen und Exkurse. Wenn ihr es eilig habt, dann könnt ihr das auch überlesen.

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 standardmäßig 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.
  • Hinweis zu IPv6 und DS-Lite: diese Anleitung funktioniert nur, wenn das Gateway über eine öffentlich erreichbare IPv4 Adresse im Internet hängt. Der Zugriff auf Heimnetzwerke, welche nur eine öffentliche IPv6 Adresse haben, ist ungleich schwieriger und funktioniert auch nur, wenn der Remote Client ebenfalls mit IPv6 im Internet ist. Bei Mobilfunknetzen wird bislang (Ende 2017) fast nur mit IPv4 gefunkt.  Betroffen sind Alle, die Zuhause (Gateway) mit DS-Lite (ausschließliche IPv6 Verbindung) am Internet angeschlossen sind. Hier nützt meine Anleitung leider nichts. Ggf. kann man beim Provider aber eine IPv4 Adresse nachbuchen – gegen Aufpreis versteht sich.

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.
  • Je nach Setup (DSL oder Mobilfunk) 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.

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. Dort auch die Möglichkeiten einer Absicherung zu Gemüte führen. Durch die Portfreischaltung hat eure Firewall ein Loch bekommen und euer Netz ist somit angreifbar.
  • 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 über den Tunnel mit dem Remote Pi Kontakt aufnehmen, oder ein dritter Rechner (z.B. Putty auf einem Windows PC) greift via Gateway Pi und Tunnel auf den Remote Pi zu.

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.

Im deutschen Raspberry Pi Forum kam im Dezember 2017 eine interessante Diskussion auf – es drehte sich u.a. um die Frage, welchen User man in das obige Kommando einträgt. Ich habe der Einfachheit halber den User “pi” genommen, da der ja sowieso schon auf dem Raspberry Pi vorhanden ist. Natürlich kann hier jeder beliebige Nutzer genommen werden. Wichtig ist nur, dass dieser User auf dem Gateway angelegt wurde – also ein Konto hat.

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.

Hinweis: sollte das nicht funktionieren, kann es sein, dass der Remote Pi den SSH Key vom Gateway noch nicht kennt. In diesem Falle am Remote Pi einfach
ssh pi@dyn.IP.adresse
bzw.
ssh -p2000 pi@dyn.IP.Adresse
und die Abfrage mit yes bestätigen. Es scheint, dass Raspbian Stretch etwas weniger tolerant ist als Jessie oder  Wheezy.

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.

Hier könnte man fragen, warum man da localhost nimmt und nicht die IP Adresse des Gateway Pi. Theoretisch ginge das, allerdings hat das den Nachteil, dass die Verbindung erst nach draußen zum Router oder Switch im lokalen Netzwerk aufgebaut wird und dann wieder zurück zum Gateway geleitet wird. Das ist umständlich und verlangsamt die Geschichte. Außerdem kann es ja sein, dass die IP Adresse neu vergeben wird – dann führt die angegebene IP ins Leere. Bei Verwendung von “localhost” weiß der Pi, dass er das alles lokal bei sich “zu Hause” abwickeln kann.

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 man den Schlüssel erst erzeugen:
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:

Bei älteren Versionen von Raspbian (vor Jessie) musste -p 2000 pi@dyn.IP.adresse  in Anführungszeichen gefasst sein.

Testen kannst du das auf dieselbe Weise wie oben.

Sollte das Kopieren der ID mit einem Berechtigungsfehler scheitern, musst du dich mit SSH vom Remote aus einmal beim Gateway einloggen. Damit kennt der Remote das Gateway und akzeptiert auch den Copy Befehl.

Wichtig:
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.
Merke: Außer für Schritt 1a brauchst du den superuser sudo nicht!! Alle Eingaben erfolgen als User Pi bzw. mit dem User, den du für deinen Tunnel verwenden willst.

Für Spezialisten: Wollt ihr irgendwann später ein neues/anderes Gateway installieren, z.B. wg. HW-Tausch, dann könnt ihr das auch ohne Zugriff auf den Remote Pi durchführen. Dazu die Dateien in ~/.ssh an dieselbe Stelle des neuen Rechners kopieren – damit erkennt das Gateway den Remote Pi. Außerdem noch alle Dateien in /etc/ssh auch in das Verzeichnis /etc/ssh des neuen Gateways – damit erkennt der Remote Pi das Gateway als alten Bekannten. Dabei beachten, dass die Permissions und Besitzer mitkopiert bzw. hinterher entsprechend auf identische Werte umgestellt werden müssen.

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 setzt der Provider die Verbindung zurück.) 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. Schickt man beim Gateway etwas an Port 8000, kommt es beim Remote Pi an Port 80 wieder an. Und 80 ist der Port, mit dem der Webserver normalerweise kommuniziert.
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:

Damit das funktioniert, braucht man logischerweise einen installierten Webserver auf dem Pi – z.B.  Apache oder Lighttpd.

Im Zuge des allgemeinen Trends, den User für unmüdig zu halten, hat Firefox spätestens ab Version 75 geruht,  den Zugriff auf http Seiten (also ohne SSL Verschlüsselung) zu erschweren. Will man “von außen” mit Firefox für Windows über Router Portfreischaltung und das Gateway einen auf dem Remote gehosteten Webserver erreichen, (sinngemäß http://deine Website.net:7555) kann es passieren, dass die Remote Website nicht funktioniert. Das passiert dann, wenn man unter deineWebsite.net auch noch eine SSL verschlüsselte Website (z.B. auf dem Gateway) betreibt.
Abhilfe geht wie folgt: Im Firefox Profilordner die Datei

sitesecurityservicestate.txt

editieren und die Zeile, welche deineWebsite.net enthält, rauslöschen. Dumerweise wird Firefox beim nächsten Zugriff auf die SSL verschlüsselte Seite diesen Eintrag wiederherstellen. Falls das zu sehr nervt,

sitesecurityservicestate.txt

als Readonly einstellen (Rechtsklick auf Dateinamen – Eigenschaften – schreibgeschützt).  Wie man das mit FF für iOS hinbekommt, habe ich noch nicht herausgefunden.

Firefox hat noch ein paar andere Schweinereien auf Lager, die künftig https erzwingen und unverschlüsselte Seiten ins Abseits stellen. Infos hierzu z.B. bei Heise.de

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 http 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:

Auch hier braucht ihr natürlich einen Webserver auf dem Remote Pi.

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

  1. Hi Chris,

    Tunnel funktioniert, allerdings muss ich auf dem Remote Pi die Verbindung initiieren obwohl es über autossh beim reboot hergestellt werden soll.
    Die Crypto Keys sind angelegt und auch auf das Gateway kopiert, trotzdem muss ich das Passwort eingeben.
    Hats du eine Idee?
    Danke
    Gruß
    Klaus

    1. Hallo Klaus,
      könnte es sein, dass du mit verschiedenen Usern gearbeitet hast? Wie in der Anleitung steht, muss der User, der die Keys generiert hat, auch derjenige sein, der den Tunnel vom Remote aus startet.
      Wie immer hilft es, sich Stück für Stück nach vorne zu hangeln: d.h. erst auf Remote Keys anlegen (sofern noch nötig), dann auf das Gateway kopieren, dann einfach mal vom Remote aus probieren, ob ein passwortloser ssh login auf dem Gateway funktioniert – ssh urlOderIPdesGateways. Dabei immer denselben User verwenden und auch kein sudo davor. Das muss(!) funktionieren, sonst klappt der Rest nicht. Sobald das okay ist, mit der Anleitung fortfahren.
      Gruß
      Chris

  2. Hallo Chris,
    Der Reverse SSH Tunnel läuft perfekt. Nun wollte ich eine verschlankte Version des GatewayPI an den Start bringen. Hierfür habe ich einen Raspberry Zero hergenommen und Debian (stretch) neu aufgesetzt. Nachdem alles von der IP Adresse bis sshd_config und deren Einträge angepasst habe, wollte ich die SSH Files aus dem Verzeichnis .ssh ( von dem alten funktionierenden GatewayPI ) einfach übernehmen, also kopieren. Dachte mir, dass hier alle Keys hinterlegt sind.
    Betroffen sind die authorized_keys und known_hosts, leider baut er damit keinen Tunnel mehr auf. Die entsprechenden Rechte habe ich vergeben. Ich muss dazu noch sagen, dass ich momentan ( physikalisch ) auf den Remote PI keinen Zugriff habe, weil er außerhalb meiner Reichweite ist. Gibt es dafür eine einfache Lösung?
    Gruß
    Robert

    1. Hallo,
      da muss ich auch etwas hirnen. Bei mir hat diese Vorgehensweise geklappt. Kontrolliere mal, ob die /etc/ssh/sshd_config auf dem Gateway den Eintrag PubkeyAuthentication yes enthält. Gateway anschließend neu starten. Ich weiß nicht, ob ich heute noch dazu komme, das rauszufinden. Zur Not halt das bisherige Gateway verwenden und damit auf den Remote Pi zugreifen, um das neue Gateway zu konfigurieren.
      Viele Grüße
      Chris

      1. Hallo Chris,

        der Eintrag war bei beiden Versionen ( PubkeyAuthentication yes ) gerautet. Hab ihn jetzt mal scharf geschalten. Das bisherige Gateway funktioniert ja noch prima, deshalb ist es nicht dringlich. War mir halt nicht sicher ob ich da in die richtige Richtung denke und handle.
        Danke für die Rückmeldung.
        Gruß
        Robert

    2. Okay, in der Mittagspause noch etwas Zeit gehabt: Die Lösung könnte hier zu finden sein: https://serverfault.com/questions/250887/process-to-move-ssh-server-keys-to-new-server
      Da steht, dass du alle Dateien in /etc/ssh vom alten auf das neue Gateway kopieren musst. Unbedingt darauf achten, dass du die jeweilige Permissions (root) auch mitkopierst. am besten als Sudo arbeiten mit sudo bash wirst du zum Superuser mit exit wieder zum Normaluser

      Sag mir bei Gelegenheit, ob das funktioniert.
      Chris

      1. Hallo Chris,

        das hat wunderbar geklappt. Wichtig ist, wie du geschrieben hast, die “Berechtigungen” zu setzen.
        Jetzt rennt die Kiste auch auf dem Raspi-Zero mit minimal Anforderungen.
        Besten Dank für deine Hilfe.
        Gruß
        Robert

  3. Hallo Chris,

    ich habe deine Anleitung studiert und mir ist nicht ganz klar, warum ich einen Remote Router benötige !!

    Meine Konstellation ist folgende. Ein Raspi hängt weit entfernt an einem USB-Suftstick. Dieser Raspi sendet Wetterdaten auf die Homepage des Vereins.

    Leider hängt sich die Wetterstation hin und wieder auf und wurde deshalb immer händisch geresetet.
    Es würde jedoch auch über einen Befehl im Terminalfenster funktionieren.

    Dazu benötige ich jedoch die Remote Verbindung.

    Reicht es aus, wenn ich mir für Zuhause einen zusätzlichen Raspi anschaffe und diesen nur “online” stelle wenn ein Problem auftritt oder muss dieser ständig online sein?

    Könnte ich ohne Raspi als Gateway auch einen Linuxrechner verwenden der bei bedarf eingeschaltet wird?
    Danke für die Antwort.

    1. Hallo,
      auf der Remote Seite musst du nur irgendwie ins Internet kommen. Ob da ein Router dazwischen hängt, oder du direkt vom Remote Raspi per Internet Stick ins Internet gehst ist egal.
      Hatte ich aber auch so beschrieben:

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

      Wie immer führen viele Wege nach Rom. Im Prinzip kannst du den Gateway Pi ausgeschaltet lassen und nur aktivieren, wenn du auf den Remote Pi zugreifen willst. Ich habe das streckenweise über mehrere Tage machen müssen, weil ich Probleme mit meinem Kabelanschluss zuhause hatte. Es kannn natürlich sein, dass ssh bzw. autossh auf dem Remote Pi irgendwann aussteigt, wenn es über sehr lange Zeit keine Verbindung aufbauen kann. Da gibt es sicher auch ein paar Einstellungsparameter die das verhindern – man pages lesen…
      Natürlich brauchst du weder auf der Gateway Seite noch auf der Remote Seite einen Raspberry Pi. Es tut auch ein ganz normaler Linux/Unix Rechner oder ggf. Windows oder Apple, wenn du da ssh zum Laufen bringst. Mit dem Pi ist das halt alles sehr viel bequemer, kostengünstig und auch relativ nachhaltig, was den Stromverbrauch angeht.
      Du könntest auch überlegen, den Pi, an dem die Wetterstation hängt, autark die Wetterstation zu resetten zu lassen, wenn sie keine Daten liefert.
      Viele Grüße
      Chris

      1. Hallo Chris,

        jetzt hab ich den Aufbau mit zwei Raspis durchgezogen. Anfänglich schien es so, als wenn alles klappen würde, solange das Lan angeschlossen war.
        Über Putty bin ich per pi@dyn.IP.adresse auf den Remote gekommen, nur wenn ich den Surfstick anstecke und das LAN entferne gibt es keine Verbindung mehr.
        Portfreigabe sollte passen sonst wäre ich mich auch nicht mit pi@dyn.IP.adresse anmelden können.
        Rebooten und abwarten hat auch zu nichts geführt.

        1. Hallo Chris,

          ich bin jetzt einen Schritt weiter.
          Wenn ich mit RDP oder direkt auf den Gateway PI ( Desktop )gehe, bekomme ich eine Verbindung
          über den Surf Stick auf den Remote PI. Dazu gebe ich im Desktop Terminal “ssh -p 10011 localhost” ein. Alles gut 🙂

          Nur wie kann ich direkt über Putty, von der Winoberfläche aus, auf den Remote PI erreichen?
          Wenn ich den Remote PI an’s Lan hänge, dann funktioniert es mit Putty im Adressfeld “pi@dyn.IP.adresse” ohne Probleme. Nur wenn der Remote PI über den Surfstick laufen lasse, bekomme ich keine Verbindung. Wo liegt mein Denkfehler?
          Oder besser gefragt, was muss ich tun damit ich direkt über Putty auf den Remote PI komme?

          Gruß
          Robert

          1. Hallo,
            kann es sein, dass du Remote und Gateway Kommandos vertauscht hast?
            Bitte befolge Schritt 1a und 1b meiner Anleitung. Auf dem Remote Pi das Reverse SSH Kommando gemäß 1b eingeben.
            ssh -fN -R 10011:localhost:22 pi@dyn.IP.adresse
            Damit baut Remote seinen Tunnel zum Gateway auf.

            Jetzt mit dem PC und Putty auf dem Gateway einloggen oder dort direkt eine Terminalsession starten. Dann in den Tunnel einsteigen mit
            ssh -p10011 localhost

            Wenn alles klappt kommst du damit beim Remote Pi raus und du kannst dich dort einloggen.

            Anschließend die weiteren Stabilisierungssschritte durcharbeiten.
            Gruß
            Chris

            1. Hallo Chris,
              ich weiß nicht was jetzt anders ist, nun funktioniert es. Habe nichts verändert. Das einloggen auf den Remote PI klappt jetzt auch über Putty, direkt über das Gateway PI Terminal mit
              ssh -p10011 localhost und PW.
              Danke für deine Hilfe, danke für die Geduld, danke für die tolle Anleitung.
              Gruß
              Robert

  4. Hi Christoph,

    erst einmal ein riesiges Lob an diese unglaublich ausführliche Anleitung. Da ich zwar ziemlich technikaffin bin, aber bisher noch keine Erfahrung mit Linux und Pis habe, habe ich momentan noch etliche Fragezeichen in meinem Kopf.
    Ich würde nur gerne einmal zunächst erfahren, ob deine Anleitung für meinen Wunsch genau das richtige ist:

    – Vor Ort 4G Flat Tarif, bzw. min. 100 GB Volumen
    – Momentaner Router ZTE 283+ (zwei Stück habe ich davon)
    – Den hier habe ich bereits gekauft: Fritzbox LTE 6842
    – Huawei E5577C mobiler LTE Router
    – Wansview NVR 903 (noch nicht angeschlossen)
    – 3x Conceptview IP-Kameras
    – Free DTDNS Account, über den ich zu DSL-Zeiten vor Ort Port Forwarding nutzen konnte

    Ich möchte also in Zukunft von Außen auf meine 3 Kameras bzw. den NVR (und dann auf die 3 Kameras) zugreifen. Dies über PC (Programm oder Chrome) und Android App.

    Die Verbindung vor Ort ist meistens stabil, jedoch gibt es ab und zu einen Stromausfall. Mit autossh genügt das aber trotzdem?

    Kann ich auch etwas direkt auf die Fritzbox flashen oder benötige ich in jedem Fall einen Pi und einen weiteren als Gateway?

    Vielen Dank für deine Rückmeldung.

    Schöne Grüße

    1. Hallo Danni,
      danke für dein Feedback. Autossh ist genau dafür da, die Verbindung wieder aufzubauen, wenn z.B. der Strom ausgefallen ist oder der Internetprovider seinen täglichen Connection Reset macht.
      Auch wenn die Fritzbox eigentlich ein kleiner Linux Rechner ist, würde ich dringend davon abraten, hier etwas (z.b. eine Reverse SSH Routine) draufzuflashen. Du verlierst die Garantie, die Box ist eh ziemlich vernagelt und teilweise proprietär aufgebaut. Ein Pi Zero kostet keine 15€, mit 50€ inkl Netzteilen für zwei Pis bist du dabei. Ich würde allerdings vor allem das Gateway und ggf. auch den Remote Pi mit Ethernet (Kabel) anschließen. Pi Zero braucht dafür einen USB Ethernet Adapter.
      Für den Zugriff auf deine diversen Gerätschaften und den Router würde ich dir noch meinen Artikel Reverse SSH Tunnel – Remote Router administrieren ans Herz legen. Wen du Fragen hast, einfach melden.
      Phrohe Ostern
      Chris

  5. Hallo Bastian,

    funktioniert dar oben beschriebene SSH-Tunnel auch für HTTPS-Verbindungen (Port 443)?

    Beispielszenario:
    Der Remote-Pi ist im Mobilfunknetz. Der Gateway-Pi ist global zugreifbar und kann mitsamt Router/Firewall konfiguriert werden. Auf dem Remote-Pi läuft ein SSL/TLS-verschlüsselter Webserver, den ich über den Gateway-Pi von außen zugreifbar machen möchte.

    Die Einrichtung von SSH und HTTP gemäß deinem Tutorial ist erfolgreich verlaufen, bei HTTPS klappt es jedoch bislang nicht. Eventuell müsste man auf dem Remote-Pi selbst noch eine Weiterleitung konfigurieren – das ist zumindest mein nächster Versuch, um eine HTTPS-Verbindung herzustellen.

    Vielleicht hast du einen hilfreichen Vorschlag oder bereits getestet, ob HTTPS-Verbindungen “im Dreieck” herstellbar sind. Bin für jede Art der Rückmeldung dankbar. (;

    Beste Grüße
    Mikel aus Clauthal

    1. Hallo Mikel,
      ich bin zwar der Chris – einen Bastian kenne ich nicht. Trotzdem freue ich mich über dein Interesse.
      Schau dir doch mal meinen Beitrag Remote Router administrieren an. Da steht wie sowas mit einem weiteren Gerät im Remote Netz gemacht wird. Klappt aber auch, wenn du den Remote Pi direkt ansprichst.
      Du musst den Router beim Gateway für eine frei gewählte Portadresse z.B. 8899 freischalten. Diese ist dann der Eingangsport für deine Weiterleitung. Der Remote Pi mit den https Seiten baut dann den Reverse Tunnel mit -R 8899:localhost:443 auf. Mit https://ipAdresseGateway:8899 oder https://URLDesGateways:8899 landest du auf dem Gateway was dich dann automatisch auf den Remote weiterleitet und dort beim https Port rauskommt. Ich nehme an, du hast zumindest selbsterstellte Zertifikate auf dem Remote Pi installiert – ohne Zertifikate funktionierts nicht. Trotzdem wird es voraussichtlich zu Zertifikatsproblemen kommen, da das Zertifikat auf dem Remote nicht mit der IP Adresse des Gateways harmoniert. d.h. es gibt also immer eine Zertifikatswarnung (ungültiges Zertifikat oder so). Je zugenagelter die Browser sind, kann es sein, dass eine Verbindung über mehrere Hops gar nicht funktioniert. Ich habe deshalb bei mir die Remote Webserver ohne https installiert.

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

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

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

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

Schreibe einen Kommentar zu Danni Antworten abbrechen

Ich freue mich über Lob und Kritik.
Falls du Probleme mit der hier vorgestellten Anleitung hast und nicht weiter kommst:
Bitte das Problem oder die Fehlermeldung(en) möglichst genau beschreiben, auch an welcher Stelle (z.B. in welchem Node oder Befehl) und unter welchen Umständen der Fehler auftritt.
Gerne kannst du mir auch ein Mail schreiben. Die Adresse findest du im Impressum.
Ich gebe mir viel Mühe, meinen Lesern weiterzuhelfen. Je konkreter du bist, desto einfacher und schneller kann ich versuchen zu helfen.
Deine E-Mail-Adresse wird nicht veröffentlicht.
Erforderliche Felder sind mit * markiert