Linux – Cannot find device „tun0“

Ihr wollt z.B. mit SSH ein VPN und dazu einen Tunnel aufbauen, könnt aber nicht, weil Ihr diese Fehlermeldung bekommt: Cannot find device „tun0“ ? Ja, na dann auf ins neue Netstackventure!

Tunneldevice mit Linux nutzen

Ihr erinnert Euch noch an den Artikel: SSH VPN mit den iproute2 Tools ? Da haben wir ein SSH VPN aus dem Hut gezaubert und mußten dazu mit Tunneln arbeiten. Da hat sich einiges getan, deswegen müssen wir uns leider erneut damit befassen.

Schritt 1 und 2 sind klar, ein TUN Modul laden und Device erzeugen, aber was ist das…?? :

[root@backup ~]# modprobe tun
[root@backup ~]# ip link set tun0 up;
Cannot find device "tun0"

Cannot find device „tun0““ ist ein echter Kopfschmerzenerzeuger, weil so unnötig. Also das Modul „tun“ ist wie der Name nahelegt, für Tunneldevices zuständig. Es sollte eigentlich ein Tunneldevice tun0 erzeugen, tuts aber nicht und mit normalen Fedora Bordmitteln ist das auch nicht so einfach machbar.

Ihr braucht das Paket „tunctl“ ( dnf install tunctl ) und müßt Euch erstmal ein tundevice bauen:

tunctl -t tun0

Wie man sieht, ist das nicht schwer. Jetzt, wo das Gerät persistent gemacht wurde, seht Ihr an der Ausgabe von dem Befehl oben, klappt das dann auch mit dem „ip link set tun0 up“ und Ihr könnt der Anleitung aus SSH VPN mit den iproute2 Tools weiter folgen. Ihr müßt nur dran denken, daß Ihr das auch bei Euch auf dem Client PC macht und nicht nur auf dem Server.

Eine Bewertung, wieso das nicht mehr defaultmäßig bei Fedora dabei ist, verkneif ich mir, es wird merkwürdige Gründe haben 🙂

How to Linux – Webserver lokal mounten

Icon des Webservers auf dem DesktopIcon des Webservers auf dem DesktopWer seine Webseiten entwickeln will, muß die irgendwie auf seinen Webspace bekommen. Je nachdem was man programmiert und welche Serverumgebung man hat, kann es auch sein, daß einem der Server einen Deploy Mechanismus anbietet. Das ist z.B. im WebApplicationServer Tomcat so vorgesehen. PHP Anwendungen werden üblicherweise einfach nur in das Public_html des Webspace kopiert und direkt aufgerufen.

Schritt 1 – SSH Keys einrichten

Voraussetzung für dies Verfahren ist, daß man sich auf seinem Webspace per SSH einloggen kann. Könnt Ihr das nicht, sucht Euch einen neuen Anbieter.

Das tun wir hier mal ( den Domainnamen habe ich mal exemplarisch gewählt, den gibt es zwar wirklich, aber nicht bei mir 😉 )

[marius@eve ~]$ ssh webdemode@webdemo.de
webdemode@webdemo.de's password: 

Passwort eingeben, weil noch geht ja kein Key.

Last login: Sat Mar 31 12:38:16 2018 from 79.239.240.108
[webdemode@s113 ~]$ ls -la
total 14
drwxr-x--- 3 webdemode services 4096 Mär 31 09:59 .
drwxr-xr-x 13 root root 4096 Mär 31 09:59 ..
-rw-r--r-- 1 webdemode webdemode 18 Aug 8 2017 .bash_logout
-rw-r--r-- 1 webdemode webdemode 193 Aug 8 2017 .bash_profile
-rw-r--r-- 1 webdemode webdemode 231 Aug 8 2017 .bashrc
drwxr-xr-x 3 webdemode webdemode 4096 Mär 31 09:59 public_html

Es fehlt das Verzeichnis „.ssh“, also anlegen:

[webdemode@s113 ~]$ mkdir .ssh
[webdemode@s113 ~]$ ls -la
total 18
drwxr-x--- 4 webdemode services 4096 Mär 31 10:09 .
drwxr-xr-x 13 root root 4096 Mär 31 09:59 ..
-rw------- 1 webdemode webdemode 229 Mär 31 10:39 .bash_history
-rw-r--r-- 1 webdemode webdemode 18 Aug 8 2017 .bash_logout
-rw-r--r-- 1 webdemode webdemode 193 Aug 8 2017 .bash_profile
-rw-r--r-- 1 webdemode webdemode 231 Aug 8 2017 .bashrc
drwxr-xr-x 3 webdemode webdemode 4096 Mär 31 09:59 public_html
drwxrwxr-x 2 webdemode webdemode 4096 Mär 31 10:02 .ssh

Noch hat es falsche Rechte, da würde SSH meckern :

[webdemode@s113 ~]$ chmod 700 .ssh
[webdemode@s113 ~]$ cd .ssh/
[webdemode@s113 .ssh]$ vi authorized_keys2

Dann den Fingerprint von Eurem Key in die Datei authorized_keys2 reinschreiben:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAEAQ7v3LaRyRjbm...... Rqr9L8IjxAEeT7bzZ/VH20ksRNwSEU5jnTE7S2Jcvk2u/7CnmipAp/uE2SvOdEVm7Lgku4y9EgSNlNi+QVbGFkzQ788AsiMHHULacHZRT9w== marius@meinlinuxrechner

(hier eine stark gekürzte Fassung, Eurer muß komplett da rein)

Nun noch die Rechte von der Datei ändern:

[webdemode@s113 .ssh]$ ls -la
total 10
drwx------ 2 webdemode webdemode 4096 Mär 31 11:03 .
drwxr-x--- 4 webdemode services 4096 Mär 31 10:09 ..
-rw-rw-r-- 1 webdemode webdemode 1435 Mär 31 11:03 authorized_keys2
[webdemode@s113 .ssh]$ chmod 644 authorized_keys2 
[webdemode@s113 .ssh]$

Das wars. Ab jetzt kann man mit seinem Key einloggen :

[webdemode@s113 .ssh]$ exit
Abgemeldet
Connection to webdemo.de closed.
[marius@eve ~]$ ssh webdemode@webdemo.de
Last login: Sat Mar 31 12:39:39 2018 from 79.239.240.108

Schritt 2 – SSHFS benutzen

Damit man sich seinen Webspace per SSH direkt in seinen Arbeitsbereich auf dem Desktop mounten kann, möglichst ohne dauernd Passwörter eingeben zu müssen, braucht man einen SSH-Agent z.b. den Gnome-Keyringdämonen. Diesem gebe ich meinen Key und statt mich jedesmal zu fragen, schickt der Agent dann einfach den Schlüssel an den Server.

ssh-add /pfad/zu/meinem/SSH-Schlüssel_rsa

ggf. Passwort eingeben.

sshfs webdemode@webdemo.de:/home/webdemode/ mnt

und schon kann man im Filesystem seines Desktops einfach auf den Webserver zugreifen, als wenn es Lokal wäre :

[marius@eve ~]$ ls -la mnt/
 insgesamt 52
 drwxr-x---. 1 testuser 500 4096 31. Mär 12:09 .
 drwx------. 106 marius marius 20480 31. Mär 11:57 ..
 -rw-------. 1 testuser testuser 356 31. Mär 13:05 .bash_history
 -rw-r--r--. 1 testuser testuser 18 8. Aug 2017 .bash_logout
 -rw-r--r--. 1 testuser testuser 193 8. Aug 2017 .bash_profile
 -rw-r--r--. 1 testuser testuser 231 8. Aug 2017 .bashrc
 drwxr-xr-x. 1 testuser testuser 4096 31. Mär 11:59 public_html
 drwx------. 1 testuser testuser 4096 31. Mär 13:03 .ssh

Welcher User einem da jetzt angezeigt wird, hängt von Eurem System ab, aber i.d.R. werden es nur die UID und GID des Serverusers sein. SSH kümmert sich dabei um alles, also auch, daß man die UID transponiert wird, es gibt am Ende also keine Probleme mit dem Lesen oder Schreiben von Dateien.

Das kann man dann einfach mit Gedit oder einem anderen Programm öffnen (BlueFish z.b. ):

Datei des Webservers in GEdit

Datei des Webservers in GEdit

Linux – wenn ssh nicht portforwarden will

Wenn SSH Euren Port trotz richtiger Angabe der Parameter nicht forwarden will, könntet Ihr Opfer des Fortschritts geworden sein.

Das Problem

Der Befehl :

ssh -g -R *:24007:192.168.178.1:24007 root@remoteserver.de

sagt dem entfernen Server normalerweise, daß der Remote-Server einen Port 24007 für alle zugänglich auf 0.0.0.0 binden soll und alles was reinkommt, soll an die lokale IP 192.168.178.1 Port 24007 weitergeleitet werden.

Wenn das aber immer im Netstat auf 127.0.0.1 angezeigt wird:

tcp 0 0 127.0.0.1:24007 0.0.0.0:* LISTEN 13927/sshd: root@pt….

dann ist Eure SSHD-Config zu alt 🙂 Vor einigen Jahren wurde eine neue Option eingeführt, so daß der SSHD zwingend konfiguriert sein muß, globale Ports binden zu können.

Die Lösung

Fügt in die /etc/ssh/sshd_config  die folgende Zeile ein und startet den Dienst neu:

GatewayPorts yes

Damit darf der SSHD das wieder für Euch erledigen und die Tunnelwelt funktioniert für Euch wieder.

Das könnte auch interessant sein:

SSH VPN mit den iproute2 Tools
UDP Traffic per SSH tunneln
TAR erfolgreich per SSH tunneln

Directcopy mit SSH

Für alte SSH Hasen ist es nichts Unbekanntes, daß man von einem dritten PC aus, direkt Files zwischen zwei anderen SSH-Servern hinundher kopieren kann. Dazu muß lediglich zwei vollständige Logins angeben:

scp user@server1:/path/foo user@server2:/path/

Solange man die schwache Passwortauthentifizierung benutzt, bekommt man zwei Abfragen zu den Passwörtern der beiden Zugänge. Nachvollziehbar, weil Server 1 das Passwort für Server 2 nicht kennt.

Was aber, wenn man das nicht mehr benutzen kann, weil man sich nur noch mit Key authentifizieren kann ?

Der erste Server, dem man das Kommando zum Kopieren von Daten gibt, akzeptiert klaglos den Schlüssel den unser SSH-Agent ( das ist der Gnome-Keyring-Manager der bei Euch auf dem Desktop läuft ) zur Verfügung stellt. Damit kann man zwar das Kopieren starten, wird sofort ausgebremst, weil Server 1 das Passwort von Server 2 wissen will.

Wenn Server 2 jetzt auch nur noch Keys akzeptiert, weil die PasswortAuth im SSHD deaktiviert wurden, und das solltet Ihr immer einstellen:

PermitRootLogin without-password

Dann habt Ihr ein Problem, denn den nötigen Key kann man nicht vom heimischen PC zum ersten Server senden und dann zur Auth bei Server 2 nutzen.  Um das zu umschiffen gibt es eine unschöne Lösung, die „mal“ geht, wenn es sich um wenige Daten handelt: die Option “ -3 “ (Minus Drei) .

Diese Option sagt SCP , daß es die Daten erst zum eigenen PC überträgt und dann erst zum Server 2. Man kann also nicht mehr von einem Directcopy reden. Am spart sich so lediglich, daß die Dateien erstmal im Temp-Ordner vom System landen und später von Hand gelöscht werden müssen. So gesehen, macht es den Kopierprozess schon einfacher.

Die Lösung mit den Bauchschmerzen

Das es SSH-Agenten gibt, hatte ich ja schon erwähnt. Auf einem normalen Server kann man das Tool auch mit genau dem Namen starten : ssh-agent . Das Programm installieren wir auf Server 1 und rufen es auf. Es gibt uns einige Umgebungsvariablen aus :

#!/bin/bash
SSH_AUTH_SOCK=/tmp/ssh-tqJtR00AWwOq/agent.2040; export SSH_AUTH_SOCK;
SSH_AGENT_PID=2048; export SSH_AGENT_PID;

Die müssen wir z.B. mit „export“ aktivieren, damit ssh den ssh-agent findet. Das obige Beispiel ist aus einem kleinen Script, daß beim Starten der Root-Shell ausgeführt wird. Damit ist man dann als Root automatisch an den ssh-agenten gebunden und muß sich nicht mehr um diese Details kümmern. Da man dem ssh-agent sagen kann, wie lange die Authentifizierungsdaten gecached werden sollen, kann man z.B. den ganzen Tag ohne Eingabe von Passwörtern für Keys arbeiten.

Auszug aus der /root/.bashrc

# Source ssh user agent
if [ -f /root/.sshagent ]; then
        .  /root/.sshagent
fi

Damit eröffnet sich eine Möglichkeit, die Daten von Server 1 auf Server 2 direkt zu kopieren, ohne schwache Passwörter benutzen zu müssen.  Man aktiviert also auf dem Server 1 den RSA/DSA – Schlüssel/key  für Server 2 im ssh-agent und kann dann mit SCP den ganzen Tag Aufträge verteilen.

ssh-add -i /path/foo/key.rsa

Wenn man Keys nutzt, sollte der jeweilige Key noch mit einem Passwort gesichert sein, damit nicht jeder den Key, so er denn erbeutet wurde, benutzen kann.

Und wieso Bauchschmerzen ?

Wenn man vernünftig Arbeiten will, muß der Agent die Authdaten mal min. für einen Arbeitstag cachen. Je länger desto mehr Bauchschmerzen sollte man bekommen, denn in der Zeit könnte jeder, der auf dem Server root wird, sich ungestört in allen Systemen einloggen oder Daten kopieren, zu denen der Schlüssel Einlass gewährt. Der Vorgang das einer Root wird, ist natürlich schon Horror pur, aber wenn die ganze Serverfarm betroffen ist, also wer bei dem Gedanken keine Bauchschmerzen bekommt, dem kann man nicht mehr helfen.

Wenn so ein Server sicher ist, braucht man natürlich keine Bauchschmerzen haben, aber bei den vielen Bugs die in allem möglichen drin ist…. puhh.. Ein bisschen Angst schwingt immer mit. Das mich keiner falsch versteht, ich liebe meinen ssh-agent, aber ich nutze ihn nur, wenn es unbedingt sein muß 🙂

Der logistische Teil

Der ssh-agent müßte auf allen Servern laufen und dort den Schlüssel aktiviert haben, von dem Daten irgendwohinanders kopiert werden sollen. Das kann im Detail recht aufwendig werden, wenn man nicht überall den gleichen Key benutzt.

Das es keine so gute Idee ist, überall den gleichen Key in jede Richtung zu benutzen, sollte Euch klar sein.

SSH VPN mit den iproute2 Tools

Vor einiger Zeit habe ich gezeigt, wie man ein SSH VPN erstellt. Heute gibt es nun die verbesserte Version, die auch iproute2 Tools benutzt, die ifconfig & Co. abgelöst haben.

Es gelten die gleichen Regeln wie für den alten Beitrag. Als kleine Abweichung nutzen wir diesmal das tun0 Interface, aber das ist reine Kosmetik.

Vorbereitungen

Auf dem VPN Server muß der SSH Tunnel erlaubt sein. Dazu tragen wir „PermitTunnel yes“ in /etc/ssh/sshd_config ein und starten den sshd neu.

Auf dem Clienten

Als erstes öffnen wir den Tunnelverbinder und wie man an den neuen Optionen sehen kann, brauchen wir kein Sleep mehr, denn das macht SSH jetzt für uns von ganz alleine :

ssh -NTCf -w 0:0 root@2te.vpn.server.ip

auf dem VPN Server

 ip link set tun0 up;
 ip addr add 10.0.1.1/32 peer 10.0.1.2 dev tun0;
 echo 1 > /proc/sys/net/ipv4/ip_forward ;iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE;

Da der SSH Befehl im Hintergrund anbleibt, können wir auf das Sleep verzichten und direkt zum Clienten wechseln.

Auf dem Clienten

ip link set tun0 up;
ip addr add 10.0.1.2/32 peer 10.0.1.1 dev tun0;
route add 2te.vpn.server.ip gw alte.gw.ip;
route del default gw alte.gw.ip;
route add default gw 10.0.1.1 dev tun0;

Das wars schon wieder, sofern Ihr keine Fehlermeldung bekommen habt. Wichtig ist die Reihenfolge der Aktionen, also daß SSH zuerst gestartet wird, damit das Tunnelinterface auf der Serverseite vorbereitet werden kann. Wenn man nach SSH z.b. „ip link delete tun0“ eingibt, war alles umsonst und es wird nicht funktionieren.

 

UDP Traffic per SSH tunneln

SSH Tunnel sind eine gängige Methode um Traffic sicher von einer Maschine auf die andere umzuleiten, aber SSH kann nur TCP Traffic tunneln. Wie bekommt man jetzt UDP über SSH getunnelt ?

Die Antwort lautet : gar nicht! Man muß TCP Traffic draus machen 🙂

Als ersten Schritt öffnen wir mal den Tunnel:    (alle Befehle als Root ausführen versteht sich)

root# ssh -L 8080:localhost:8080 username@zielserver.de „sleep 10000“

Dies schiebt alle Daten die auf Port 8080 ankommen, an den Port 8080 des Zielserver. Der Einfachheit halber, belassen wir die Port auf Quell- und Zielsystem bei der gleichen Nummer, aber das kann man auch nach Bedarf anpassen.

Als erstes brauchen wir einen FIFO ( First In – First Out ) Speicher auf dem Zielserver. Damit kann man die Daten lesen und schreiben, was bei einer PIPE nicht geht.

root@Ziel# mkfifo /tmp/fifo

Nun leiten wir den UDP Traffic per nc von Port 8080 um :

root@Ziel# nc -l -p 8080 < /tmp/fifo | nc -u ip.des.dns.servers 53 > /tmp/fifo

Alles was wir auf Port 8080 lesen, geht über die PIP an den NC Befehl, der es an den DNS Server schickt. Seine Antwort geht über das FIFO File zurück zum „Server nc Befehl“ .

Das Gleiche, nur anders rum, brauchen wir auf dem lokalen Server:

root@local# mkfifo /tmp/fifo
root@local# nc -l -u -p 53 < /tmp/fifo | nc localhost 8080 > /tmp/fifo

Auf unserem lokalen Server binden wir uns an den Port 53 und schicken alles, was in dem FIFO File steht an den, der sich auf Port 53 verbunden hat, also z.b. der Befehl dig . Alles was von dig an den Port 53 gesendet wird, geht über die PIPE zum zweiten nc und der leitet das an den Startpunkt unseres Tunnels.

Entweder, man trägt jetzt 127.0.0.1 in die /etc/resolv.conf ein :

nameserver 127.0.0.1

oder man fragt mit dig 127.0.0.1 direkt ab:

dig @127.0.0.1 marius.bloggt-in-braunschweig.de

Das wars schon.

FireFox per SSH zum X11 forwarden

Serverfarmen bei Hostern und Unirechenzentren haben zwei Dinge gemeinsam: Es ist dort ziemlich ungemütlich und die Mitarbeiter müssen auf den Servern trotzdem ab und an Desktopanwendungen ausführen. Jeder der mal als studentische Hilfskraft gearbeitet hat kennt das, wenn ihn sein Mitarbeiter da hinschickt, um was zu machen.

Es gibt dazu allerdings Alternativen:

Man könnte heute sowas wie TeamViewer, VNC oder RemoteDesktop benutzen. Wenn man den ganzen Desktop sehen will, ist das eine feine und sehr nützliche Sache. Oft aber möchte man nur ein Programm ausführen und das unkompliziert und schnell. Den ganzen Desktop ständig zu übermitteln, ist nicht hilfreich. Also haben sich die UNIX Entwickler bereits in den 80zigern des letzten Jahrtausends eine Lösung einfallen lassen, die auch heute noch funktioniert:

das X11-Forwarding

X11-Forwarding leitet Anfragen an den lokalen X11-Display-Server ( der sorgt für das Bild auf einem Linuxrechner )  an eine externe IP Adresse um. Das geht, weil Linuxprogramme von vornherein in einer Client-Server-Umgebung arbeiten. D.b. daß die Programme im Gegensatz zu Windows eine Netzwerkschnittstelle aufrufen um mit dem Display zu sprechen. Damit kann das Display an einem anderen Ort stehen als wo das Programm ausgeführt wird und wenn es auf der anderen Seite der Erde oder im Weltraum ist.

Einziger Haken der Sache, je weiter die Geräte auseinander sind, desto langsamer reagiert das Programm auf Eingaben, weil die Daten erstmal auf die Reise geschickt werden müssen. Die resultierenden Wartezeiten nennt man Latenz.

WOW oder EVE-Online wollen Sie so nicht unbedingt spielen 😉 ( aber es wäre möglich )

Sie brauchen:

einen Linux/Unix Server mit installierten X11 Komponenten und einem SSH-Server. Den nennen wir mal „E“ für Entfernt.
Passend dazu einen Linux/Unix Rechner an dem man das Ergebnis sehen will, den nennen wir mal „L“ für Lokal.

Auf L sollte SSH installiert sein und ein X11-Server laufen. Wenn Sie grade davor sitzen und das hier lesen können, dürfte das bereits der Fall sein. Wenn Sie nur einen Windowsrechner haben, installieren Sie sich XMING ( Nein, nicht verwandt mit Xing ).

Achtung Windowsuser: Sie brauchen auch ein vollwertiges SSH Programm um weiter machen zu können und zwar eins, daß in der Konsole ausgeführt wird. Wenn Sie nur ein SSH Terminalprogramm haben, wärs möglich daß dies X11 Forwarding für Sie unterstützt. Machen Sie sich bitte schlau wie Sie das dort aktivieren.

Die Konfiguration

Auf E ändern wir zunächst die /etc/ssh/ssh_config und aktiveren dort Trustedforwarding:

X11TrustedForwarding yes

Das wars schon.

Von L aus verbinden wir uns mit dieser Option zu E :

ssh -C -Y username@servername

Je nach lokaler SSH Umgebung müssen Sie hier noch Ihr Passwort eingeben, ich kann Ihnen nur einen SSH-Agent empfehlen, da sparen Sie sich sehr viel Getippe.

-Y aktiviert X11TrustedForwarding
-C aktiviert die Kompression, damit geht es etwas schneller.

Auf E geben Sie jetzt mal ein :

echo $DISPLAY

da müßte kommen :

localhost:10.0

jetzt starten Sie einfach das gewünschte Programm, z.b. Firefox. Das geht auch direkt in einem Rutsch:

[marius@eve ~]$ ssh -C -Y root@c1 "firefox"

(process:31671): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed
Gtk-Message: Failed to load module "pk-gtk-module"
Gtk-Message: Failed to load module "canberra-gtk-module"

An Fehlermeldungen müssen Sie sich jetzt leider gewöhnen, die sieht man normalerweise ja nicht, weil man die Programme nicht in der Konsole startet. Diese erwarten zurecht eine korrekte X11 Umgebung, die SSH aber nicht gehen kann. Das macht aber i.d.R. keine Probleme. Einfach ignorieren 😉

Das wars schon. Die X11 Verbindung wird durch SSH getunnelt und dabei praktischerweise noch verschlüsselt.

Warum könnte man sowas brauchen ?

Stellen Sie sich mal vor, Sie möchten ein Programm A von einem Server B auf Ihren Server E bekommen, daß 2-5 GB groß ist.

Wenn Sie das jetzt erstmal zu sich und dann auf den Server E kopieren, dauert das Stunden bis Tage, je nach DSL Leitung.

Wenn Sie das aber direkt auf E machen, dauert es ggf. nur Minuten, weil Sie dort 100 Mb/s oder gar Gb/s Anbindungen haben.

Normalerweise würde man sowas mit WGET machen, aber z.b. Oracle gängelt Webseitenbesucher erst noch mit  Cookies und Javascripten, nur damit man Java nicht direkt kopieren kann. Da kommt ein vollwertiger Firefox sehr gelegen.