Tunnelblick

Nicht weiter schlimm, schließlich kann die SSH ja auch tunneln, so dass man an seine Mail kommt. Aber wie versenden? Wie an den News-Server kommen?

An die Mail per fetchmail zu kommen, ist kein Problem, denn fetchmail bietet eine Option preconnect, die ein externes Programm aufruft, bevor die eigentliche Verbindung zum POP-Server aufgebaut wird.

Ein kleines Skript zum Aufbau eines SSH-Tunnels ist beispielsweise ssh-tunnel:

#!/bin/sh
 ssh -f  -c blowfish \
    -L 8110:pop.firma.de:110 \
    -L 8025:smtp.firma.de:25 \
    gateway.firma.de sleep 10 </dev/null >/dev/null

Wenn dann in .fetchmailrc steht

poll gateway.firma.de via localhost port 8110 proto POP3
     user XXXXX password "YYYYYY" fetchall:
     preconnect "ssh-tunnel";

dann startet fetchmail brav erst den Tunnel und baut dann eine Verbindung zum lokalen TCP-Port 8110 auf. Die SSH leitet diesen Port verschlüsselt an den POP3-Port des Servers pop.firma.de weiter. Auf die Weise kann man von überall her an den internen Server, und die Daten sind nicht ohne weiteres von jedermann zu lesen.

Das Skript ssh-tunnel deutet schon an, was mit zu verschickender Post passiert: die SSH leitet gleichzeitig den lokalen Port 8025 weiter an den innerhalb der Firmen-Firewall stehenden SMTP-Server. Dazu muss man aber Postfix (oder Sendmail, was auch immer man benutzt) beibringen, alle Mail an Port 8025 auf der lokalen Maschine auszuliefern. Das geht mit einem kleinen Trick in /etc/postfix/main.cf:

relayhost = [127.0.0.1:8025]

Wenn der Benutzer eine Mail schreibt, bleibt die zunächst einmal so lange hängen, bis der Tunnel aufgebaut ist und jemand postfix flush aufruft. Regelmäßig zu pollen, übernimmt wiederum der fetchmail mit der .fetchmailrc-Zeile

set daemon 300

postfix flush benötigt indes Root-Rechte. Als normaler User darf man das Kommando nicht ausführen. Mit einem kleinen Setuid-Wrapper postfixflush geht das aber relativ risikolos:

#include

int main (void) {
   setuid (0);
   return execl ("/usr/sbin/postfix",
     "postfix", "flush", NULL);
 }

Der kurze Schnipsel ist wie üblich mit gcc -o postfixflush postfixflush.c zu übersetzen. Das Binary muss Root gehören und die Rechte 4755 haben. Damit kann dann jeder die Mail-Queue leeren, und nur genau das. Wer ein Sicherheitsproblem hat, sollte das Programm statisch linken, damit niemand mittels LD_PRELOAD eine andere execl-Routine unterschieben kann. Allerdings ist das Binary dann 200 KByte statt deren drei groß. Der Aufruf

/usr/local/sbin/postfixflush

gehört einfach ans Ende des gezeigten Tunnel-Skripts. Sobald also der Tunnel steht, leert das Skript ohne Benutzereingriff die Warteschlange.

Für Sendmail gilt ähnliches, hier heißt das Kommando zum Leeren runq.

News holen und senden geht am einfachsten über suck und einen lokal installierten INN. Sicherlich sind aber auch andere Lösungen denkbar. Wie auch immer, vermutlich wird ein per cron gesteuertes Skript den Vorgang anstoßen, und hier braucht man lediglich

ssh -f  -l hmilz -i ~hmilz/.ssh/identity \
      -c blowfish \
      -L 8119:news.ip-provider.de:119 \
      gateway.firma.de sleep 30 </dev/null >/dev/null

vor dem eigentlichen Saugvorgang. Auf meinem Notebook läuft dieser Vorgang als Root, daher sagt das Skript der SSH explizit, mit welcher Identität sie den Tunnel aufbauen soll. Wenn der News-Austausch als normaler User funktioniert, wäre es auch denkbar, die beiden Lösungen zu kombinieren; das Tunnel-Skript kann zusätzlich den Port-119-Tunnel aufbauen und den News-Austausch anstoßen, vielleicht auch nicht gerade alle fünf Minuten. In dem Fall sind die SSH-Optionen -i und -l nicht nötig.

Ein Pferdefuß dieser Lösung sei aber nicht verschwiegen: um die SSH so nett im Hintergrund aufrufen zu können, muss man einen Schlüssel ohne Passphrase benutzen. Diesen darf man unter gar keinen Umständen aus der Hand geben (beispielsweise auf einem Server lagern, auf dem jemand anders Root-Rechte hat)!

Zu einem tieferen Verständnis dieser Vorgänge lohnt es sich, die Man-Pages zu fetchmail, SSH, Postfix sowie suck zu lesen.