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 müssen ö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.