Wer sein System permanent überwacht, hat den Grundstein dafür gelegt Engpässe zu vermeiden und Fehler frühzeitig zu erkennen. Neben dem Platzhirsch Nagios ... (mehr)

X11-Forwarding

Das sogenannte X11-Forwarding (Abbildung 10) erlaubt es, Programme mit grafischer Oberfläche via SSH auf einem entfernten Rechner zu starten, die Ein- und Ausgaben aber auf dem lokalen Desktop anzeigen zu lassen. Das funktioniert prinzipiell sogar unabhängig vom Betriebssystem des entfernten Rechners, sofern sich das Programm an den X11-Standard hält, womit sich die Auswahl in der Praxis auf Linux, BSD und Unix beschränkt.

Abbildung 10: Die Abbildung zeigt zweimal den grafischen GNOME-Editor Gedit unter Ubuntu 11.10, links via X11-Forwarding auf einem Server im lokalen Netz gestartet, rechts lokal gestartet.

Zwar gib es heute ein ganzes Bündel leistungsfähiger grafischer Fernzugriffs-Lösungen, SSH ist aber bei jedem Linux-System gratis an Bord, wenn auch nicht sonderlich schnell. Für den gelegentlichen Einsatz, etwa zur Systemadministration, reicht X11-Forwarding aber allemal. Zum Aktivieren von X11-Forwarding dient die Option »-X« , nicht zu verwechseln mit »-x« zum Deaktivieren von Port-Forwarding. Die Option gewährt dem auf dem entfernten Rechner zu startenden Programm nur eingeschränkte Rechte am lokalen Display, was bei der einen oder anderen Anwendung zu einem Abbruch führen kann. In diesem Fall kann der Admin dem Programm immer noch mit der Option »-Y« volle Rechte einräumen, was aber nur in Ausnahmefällen zu empfehlen ist.

Tabu ist die Option »-Y« , wenn der Admin dem Administrator des entfernten Hosts nicht vertraut, weil die Option einen Tunnel installiert, der sich von böswilligen Zeitgenossen auch in umgekehrter Richtung für einen Angriff auf das eigene Display nutzen ließe. Übrigens kann der Admin SSH als Alternative zum Parameter »-X« auch mit dem Parameter »-o« aufrufen und diesem den Wert »ForwardX11=yes« mitgeben. Wahlweise ist es auch möglich, in »$HOME/.ssh/config« die Zeile »ForwardX11 yes« einzutragen.

Tunnelbau mit SSH

Mit SSH lassen sich sogar (beinahe) beliebige andere Protokolle absichern, etwa das alte POP3-Protokoll oder eine unsichere VNC-Verbindung. Mit Port Forwarding kann der Admin einzelne Ports durch eine sichere SSH-Verbindung umleiten, wobei SSH selbst quasi als Proxy fungiert, der auf der einen Seite des SSH-Tunnels die Verbindung entgegennimmt und auf der anderen Seite mit dem adressierten Server, dem Verbindungsendpunkt, verbindet.

SSH kennt zwei unterschiedliche Betriebsarten, nämlich Local Port Forwarding, und Remote Port Forwarding, oft auch als ausgehender und eingehender Tunnel bezeichnet, wobei Local Port Forwarding weitaus häufiger zum Einsatz kommt. Die Richtung des Tunnels-Aufbaus, also Local oder Remote Port Forwarding, geben die Parameter »-L« und »-R« an. Local Port Forwarding leitet eine Verbindung, die bei einem frei wählbaren lokalen Client-Port eintrifft, durch den sicheren SSH-Kanal auf einen Port eines entfernten Servers weiter – ein klassischer "ausgehender" Tunnel. Die allgemeine Syntax für Local Port Forwarding lautet:

ssh remoteuser@remotehost -L localport:remotehost:remoteport

Das folgende Beispiel tunnelt eine unsichere FTP-Verbindung mit Standard-Port 21 über eine gesicherte SSH-Verbindung, wobei auf dem Rechner »www.thomas-drilling.de« ein FTP-Server läuft und der Client-Rechner »ws1-kubu« die sichere SSH-Verbindung aufbaut sowie anschließend in einer separaten Terminal-Sitzung den FTP-Client startet, und zwar mit der Zieladresse »localhost« auf dem Port 4444.

drilling@ws1-kubu:~$ sudo ssh dilli@www.thomas-drilling.de -L 4444:www.thomas-drilling.de:21

Mit dem Befehl baut der Admin am SSH-Client eine sichere SSH-Verbindung als Benutzer »dilli« zum entfernten Rechner »www.thomas-drilling.de« auf und lauscht außerdem auf sämtliche Anfragen, die auf dem lokalen Port 4444 von »ws1-kubu« eingehen, um sie dem entfernten Rechner »www.thomas-drilling.de« auf Port 21 weiterzuleiten, wobei die Kommunikation über die zuvor aufgebaute SSH-Verbindung läuft. Jetzt kann der Admin am lokalen Rechner »ws1-kubu« seine FTP-Verbindung wie folgt aufbauen (Abbildung 11):

drilling@ws1-kubu:~$ sudo ftp localhost 4444

Leider ist die Syntaxbeschreibung zum Port Forwarding in der Manpage etwas missverständlich: »ssh -L [bind_address:]port:host:port user@remotehost« . Die Parameter »host« und »remotehost« dieser Syntax-Schreibweise stehen im obigen Beispiel für den gleichen entfernten Server, weil »host« aus der Sicht des betreffenden Systems anzugeben ist. Daher könnte man in der praktischen Umsetzung statt »www.thomas-drilling.de:21« auch »localhost:21« schreiben, weil sich »localhost« dann auf die Perspektive des Remote Host bezieht.

Bei der Wahl des Einstiegsports (SSH) ist zu beachten, dass die Verwendung von privilegierten Ports kleiner 1024 nur Root gestattet ist. Daher nutzt man für Local Port Forwarding normalerweise höhere Ports. Der zweite Port-Parameter gibt schließlich an, auf welchen Port auf Remotehost (sshd) beziehungsweise »host« die Weiterleitung führen soll und hängt demnach vom zu tunnelnden Dienst ab. Möchte der Admin nur die Port-Weiterleitung nutzen, aber remote keine Shell starten, kann er den Parameter »-N« anhängen (Abbildung 12).

Abbildung 11: Die Abbildung demonstriert den Aufbau eines SSH-Tunnels für das an sich unsichere FTP-Protokoll. Der Admin kann die jetzt gesicherte FTP-Verbindung vom Client aus komfortabel über den selbst gewählten lokalen Port aufbauen.
Abbildung 12: Der Parameter

Möchte er etwa einen POP3-Mailserver auf seinem virtuellen Server über eine verschlüsselte Verbindung abfragen, richtet er mittels Local Port Forwarding einen verschlüsselten SSH-Tunnel für Port 110 auf seinen Vserver ein:

ssh Benutzer@Remotehost -L 20110:Remotehost:110

Jetzt muss er nur noch in seinem Mailclient, etwa Thunderbird, den Host »localhost« mit der Portnummer 4444 als POP-Server konfigurieren, und Mails lassen sich ab sofort verschlüsselt übertragen, ohne das der Mailserver selber SSL unterstützt (Abbildung 13).

Abbildung 13: Via Local Port Forwarding lässt sich beispielsweise auch das unsichere POP3-Protokoll zum Abfragen eines entfernten Mailservers via SSH absichern, auch wenn der POP-Server kein SSL unterstützt.

Remote Port Forwarding funktioniert übrigens genau umgekehrt zu Local Port Forwarding, das heißt, die Verbindung kommt an einem Port auf dem Host an, auf dem »sshd« läuft. Dieser leitet die Daten dann durch den SSH-Tunnel an einen beliebig wählbaren Port am Client. Die Syntax lautet:

ssh Remoteuser@Remotehost -R Remoteport:localhost:Localport

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2020