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

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

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

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

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

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

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

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

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

Schreibe einen Kommentar zu Rustimator 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