Tag Archives: SSH

Directcopy mit SSH

Posted on by

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

Posted on by

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.

Update:

Falls ihr ein „Cannot find device „tun0““ bekommt, dann führt mal mit Rootrechten “ tunctl -t tun0 -n “ aus.

 

UDP Traffic per SSH tunneln

Posted on by

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.