Category Archives: Verschlüsselung – SSH – SFTP – TLS – E-Mails

Beiträge zu Verschlüsselungsverfahren

Mails im Ausland über deutsche SMTP-Server

Posted on by

Immer wieder begegnet man dem Problem, dass man bei Auslandsaufenthalten genötigt wird, für den Mailversand den SMTP-Server desjenigen Providers zu verwenden, an dessen Netzwerk man gerade angebunden ist. Ich stosse auf dieses Problem u.a. immer wieder in Norwegen (Telenor, Tele2) und Frankreich (Orange, France Telekom, Bouygues, Free(box)).

Die Provider filtern Zieladressen für eine SMTP-Kommunikation (Port 25), die sich nicht auf den Provider-eigenen SMTP-Server beziehen. Angeblich, weil man auf diesem Wege Spam-Probleme besser in den Griff bekommen will. Na ja, wer’s glauben mag ….

Das Problem ist der dadurch für den Anwender generierte Aufwand. In der Regel hat man den Mail-Client (MUA, bei mir Kmail) auf seinem Notebook/Laptop ja so vorkonfiguriert, dass als SMTP-Server in der Regel ein Server des hauseigenen deutschen Providers eingestellt ist.

[Es kann aber auch auf Laptops noch komplizierter sein – nämlich dann, wenn ein eigener SMTP-Server, evtl. sogar ein lokaler SMTP-Server auf dem Laptop mit einer Relay-Server-Anbindung die SMTP-Kommunikation handhabt (z.B. in Form eines lokalen Postfix MTA mit einem IMAP MDA wie Cyrus) ].

In jedem Fall aber ärgert man sich bei Auslandsreisen jedesmal über die Notwendigkeit einer Re- oder Zusatzkonfiguration des Mail-Clients oder aber anderer Mailkomponenten (wie Postfix).

Am Schluss schleppt man eine Liste ausländischer SMTP-Server in seinen Mail-Programmen herum, aus der man je nach Standort einen bestimmten Server als den aktuellen Standard definieren muss. Schon bei manchen MUAs ist das ein Thema, denn der Mailclient sollte dann so intelligent ist, mehrere account-übergreifende SMTP-Server verwalten zu können ….

Bei einigen der ausländischen Netze habe ich deshalb mal mit einigen Linux-Tools überprüft, ob tatsächlich nur der Port 25 gefiltert wird. Dies war der Fall. Da kommt man dann auf den Gedanken, ob nicht ein anderer Port den Zugang zum SMTP-Server eines meiner deutschen Provider ermöglichen würde.

Man denkt dabei an eine TLS/SSL-Anbindung – in Frage kommen die Ports 465 und 587.

Und ja, tatsächlich ist bei zweien meiner deutschen Provider entweder der Port 465 (SMTP via SSL) oder der Port 587 zugänglich. Einer der Provider verwendet 465 in Kombination mit SMTP-AUTH, beim Port 587 ist eine Authentifizierung sowieso zwingend vorgeschrieben. Auf dem Mail-Client müssen dann natürlich die notwendigen Einstellungen für eine SMTP-Authentifizierung vorgenommen werden – was bei Kmail kein Problem darstellt.

Eine Anbindung über einen der beiden Ports 465 oder 587 kann man natürlich auch aus dem Inland vornehmen. Damit ist dann die Chance gegeben, im Inland wie auch in vielen ausländischen Netzwerken seinen Mailversand über den gewohnten SMTP-Server seines Vertrauens abzuwickeln. Standortspezifische Einstellungen entfallen dann. (Nebenbei finde ich, dass nicht jeden Provider mein Mail-Gebaren etwas angeht).

Nach meinen Erfahrungen klappt das Verwenden der Alternativports mindestens mal in Norwegen und Frankreich bestens – gefiltert wird dort nur der Port 25. Natürlich muss aber auch der eigene deutsche Provider mitspielen und die genannten Ports anbieten …..

Es lohnt sich bei häufigen Auslandsaufenthalten aber wirklich, das abzufragen und seine Mailprogramme (einmalig) auf einen der Ports 465 opder 587 umzustellen. Viel Spaß nun beim Mailen im Ausland !

Links:

http://de.wikipedia.org/wiki/E-Mail-Programm
http://de.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol
http://de.wikipedia.org/wiki/SMTPS
http://de.wikipedia.org/wiki/SMTP-Auth
http://forum.df.
eu/forum/showthread.php?t=49183

Remote Administration – VNC oder ssh -X ?

Posted on by

Es gibt eine Reihe von Situation bei der Remote-Wartung eines Rechners, in denen es nicht damit getan ist, nur auf eine Shell zuzugreifen. Manchmal benötigt man den graphischen Zugriff – zumindest auf einzelne Applikationen. Dies gilt vor allem dann, wenn der User des Remote-Rechners Fehler im graphischen Bereich meldet. Genau so einen Fall hatten wir gestern, als wir auf einen Linux-PC (SUSE 10.2) in Frankreich zugreifen mussten, um das ordnungsgemäße Wirken von Firefox zu überprüfen.

Als rettender Engel steht man nun vor der Frage, wie man den Zugriff am besten erledigt. Mit einer verschlüsselten Verbindung natürlich. Klar. Aber ist im Einzelfall eine SSH-verschlüsselte X-Sitzung sinnvoller als eine VNC-Sitzung? Ich meine, dass man das nicht pauschal sagen kann. In unserem Fall erwies sich einen verschlüsselte VNC-Sitzung als die bessere und schnellere Lösung. Wir diskutieren nachfolgend kurz beide Möglichkeiten, da wir schon mehrfach gefragt wurden, wie man für Remote-Sitzungen vorgeht.

Möglichkeit 1: SSH -X

Eine einfache Möglichkeit ist zunächst einmal die, den Output der kritischen Applikation auf den eigenen lokalen X-Server umzulenken. Dies erreicht man bequem dadurch, dass man sich auf dem Remote-Rechner mit

ssh -X remote-rechner

oder

ssh -X user@remote-rechner

anmeldet. Die auf jeden Fall erforderliche SSH-Verschlüsselung für die Verbindung erhält man dann inklusive. In vielen Fällen genügt dies, um ein Problem zu lösen. Man startet einfach in der geöffneten Shell die zu untersuchenden Applikationen, die ihren graphischen Output dann (i.d.R.) auch brav auf dem lokal laufenden X-Server des Administrator-PCs darstellen. Zur Klarstellung: Der X-Server läuft hier auf dem eigenen lokalen System des Admins und nicht auf dem zu untersuchenden Remote-System! Der Remote-Rechner sendet den graphischen Output der Applikation über das Netz zum X-Server des lokalen Rechners, von dem aus der Administrator auf das Remote-System zugreift. (Beim nachfolgend diskutierten VNC-Verfahren ist dies anders!).

Nun gibt es u.U. leider Bedingungen, unter denen das Vorgehen über “ssh -X” nicht funktioniert oder der Datentransfer einfach zu unbequem wird.

Hindernis 1 – Performance: Bei einer X-Session werden (applikationsabhängig) relativ viele Daten übertragen. Das kann u.U. zu einem erheblichen Geduldspiel werden. Tödlich sind meiner Erfahrung nach bei rel. langsamen Remote-Rechnern und begrenzter Verbindungsbandbreite solche Applikationen wie Yast (z.B zur Paketverwaltung). Auch Anwendungen, deren Inhalt selbst komplex ist (Browser mit Flash) führen ggf. zu Zuständen wie in der Warteschlange bei großen Telekommunikationsanbietern.

Hindernis 2 – Sicherheitseinstellungen: Die Applikation lässt ggf. oder unter bestimmten Umständen keinen Output auf dem Remote-Xserver zu.

Hindernis 3 – fehlerhafte Anwendungen: Die Anwendung weist Fehler auf oder ist mit dem Remote X-Server nicht kompatibel.

In unserem Fall war es wie gesagt so, dass wir das Verhalten von Firefox auf dem Remote-Rechner testen mussten. Leider ließ sich der von uns remote gestartete Firefox-Prozess unter keinen Umständen dazu bewegen, sich auf unserem lokalen X-Server zu präsentieren. (Nach Aussagen des Remote-Anwenders ging Firefox auf dem Remote KDE-Desktop aber sehr wohl auf! Siehe zum seltsamen Verhalten von Firefox weiter unten!). Zudem wurde das Update von Software über Yast2 zu einer erheblichen Geduldsprobe.

In solchen Fällen liegt es nahe, zumindest testhalber eine VNC-Verbindung über KDEs “krdc” aufzubauen und diese VNC-Verbindung ggf. für langsame Leitungen zu konfigurieren.

Möglichkeit 2: VNC
Auf dem Remote-System muss ein VNC-Server laufen. Die meisten Distributionen haben ein entsprechendes Paket, das man mit dem Paketmanager seiner Wahl installiert. Dann richtet man den VNC-Server und IPtables (oder die aktive Firewall) auf dem Remote-Rechner so ein, dass die Kommunikation überhaupt möglich wird. Typischerweise verwendet der VNC-Server auf dem Remote-Rechner als Default-Port den Port 5901.

Dieser Port muss für eingehende Verbindungen vom System des Administrators aus freigeschaltet werden – am besten nur für Verbindungen von diesem System aus! (Eine Diskussion der zugehörigen IPtables-Konfiguration führt an dieser Stelle zu weit – ich empfehle hierfür das sehr schöne Programm FWbuilder!). Unter Opensuse hilft einem Yast (s. den Punkt Netzwerkdienste). Nachteilig empfinde ich dabei allerdings die pauschale Freigabe des Ports auf allen Interfaces und für alle potentiellen IP-Adressen.

Nach dem Einrichten des VNC-Servers auf dem Remote-System ist ggf. ein Neustart von xdm, kdm oder gdm für den Anmeldebildschirm erforderlich (für SUSE und KDE hilft z.B.: “rckdm restart”). Das Einrichten des VNC-Servers macht man am besten über eine Standard SSH-Sitzung, wenn der Remote-Anwender sich mit der Konfiguration nicht auskennt.

Die Verbindung zwischen Administrator-System und dem Remote-Rechner (Port 5901) muss vor Beginn der VNC-Sitzung natürlich verschlüsselt werden. Hierzu baut man einen SSH-Tunnel vom eigenen Rechner zum Zielsystem auf. Wir setzen voraus, dass SSH auf beiden Systemen eingerichtet ist und dass der ssh-agent für eine automatische Passwortübergabe vorbereitet wurde. Der Tunnel wird dann vom PC des Administrators aus durch nachfolgenden Befehl aufgebaut:

z.B.: ssh -f -N -L8787:remote-rechner:5901 user@remote-rechner

Hierbei gilt Folgendes: “user” ist der Username unter dem die ssh-Sitzung auf dem Remote-Rechner aufgebaut wird. “remote-Rechner” ist durch den Namen oder die IP-Adresse des Remote-Systems zu ersetzen. Die Option “-f” bedingt die Option “-N”. “-f” sorgt für einen Fork-Prozess von ssh in den Hintergrund, “-N” sorgt dafür, dass kein Shell-Fenster geöffnet wird. Der ssh-agent muss hierbei – wie gesagt – in der Lage sein, Passwörter automatisch im Hintergrund auszutauschen. Als Zielport ist hier der Defaultport 5901 gewählt worden. Ob dieser gültig ist, muss man natürlich vorher wissen (Einrichtung des VNC-Servers). “8787” ist im Beispiel der Dummy-Port auf dem lokalen System, über den der lokale VNC-Client dann den Remote-Rechner auf Port 5901 – und damit den VNC-Server – anspricht.

Der SSH-Tunnel hat in diesem Beispiel also als Anfangspunkt den Port 8787 auf dem lokalen System des Administrators und als Endpunkt den Port 5901 auf dem Remote-System “remote-rechner”. Dort loggt sich der User ja gerade für die SSH-Sitzung ein. (Sonderfälle wie den Umweg über einen SSH-Relay-Rechner lassen wir hier mal der Einfachheit halber weg. )

Wichtiger Hinweis: Zu beachten ist, dass man nach getaner Arbeit nicht vergisst, den SSH-Tunnel (der ja im Hintergund läuft) wieder abzubauen und auch den Port 5901 wieder zu schließen !!!

Weitere Hinweise zum Tunneln: Schlägt der Fork-Prozess in den Hintergrund fehl, oder will man die Passwort-Verankerung in den Systemen nicht dem ssh-agent überlassen, so hilft

z.B.: ssh -L8787:remote-rechner:5901 user@remote-rechner

Allerdings öffnet man damit eine bleibende Remote-Shell im Vordergrund des lokalen eigenen Systems. Verwendet man

ssh -X -L8787:remote-rechner:5901 user@remote-rechner

so hat das den Vorteil, dass man bei Bedarf schnell noch eine Remote-Applikation für den eigen X-Server öffnen kann – zusätzlich zu den Vorgängen, die im VNC-Client dargestellt werden (also Vorgänge, die in einer X-Session auf dem Remote-System laufen).

Konfiguration des lokalen VNC-Clients: Im VNC-Client (z.B.
“krdc”) muss man im gegebenen Beispiel als Zielrechner natürlich “localhost:8787” eingeben, um die VNC-Sitzung über den Tunnel aufzubauen. Der Client spricht über den lokalen Port 8787 den Remote-Rechner an und erhält vom dortigen VNC-Server die Bilddaten der dortigen X-Sitzung zugeschickt. (Die X-Sitzung läuft auf dem Remote-Rechner ab! Der lokale VNC-Client erhält hiervon nur die Bilddaten, die er auf dem Schirm des Admin-PCs als spezielle lokale X-Applikation darstellt.).

Hat man bisher alles richtig gemacht, so öffnet sich im lokalen VNC-Client der graphische Anmeldeschirm des Remote-Systems und man gelangt nach dem Login in eine graphische X-Sitzung des Remote-Systems unter dem dortigen Window-Manager (z.B. KDE).

In unserem Fall stellten wir tatsächlich fest, dass das Arbeiten über VNC relativ zügig vonstatten ging und zwar schneller als mit einer “ssh -X” – Sitzung. Ob das allgemeingültig ist, trauen wir uns aber keinesfalls zu sagen.

Hinweis zu Remote-Tests von Firefox:
Firefox für Linux stellt fest, auf welchem X-Server und Screen ein bestimmter User eine erste Instanz des Firefox-Programms geöffnet hat und lässt die Öffnung weiterer Instanzen für andere X-Server nicht zu (vermutlich aus Sicherheitsgründen). Das führt für Remote-Zugriffe aber zu folgender unguter Situation:

Hat der Remote-User (nennen wir ihn “James”) noch irgendein Firefox-Fenster offen, so lässt sich auf dem lokalen X-Server des Administrators keine weitere Firefox-Instanz öffnen, wenn der Administrator als “James” auf dem Remote-System eingeloggt ist. Umgekehrt gilt das Gleiche: Hat der Administrator als User “James” auf dem Remote-System eine Firefox-Instanz für den lokalen X-Server geöffnet, so kann der User James auf dem Remote-System und in seiner eigenen X-Sitzung keine neue Firefox-Instanz öffnen, sondern erhält eine Warnung !
Man lernt nie aus!
Merke: Will man Firefox als Remote Administrator auf seinem eigenen lokalen X-Server testen, so muss der User auf dem entfernten Remote-Rechner alle Firefox-Fenster (Firefox-Programme) vollständig geschlossen haben – oder der Administrator muss unter einer anderen User ID eingeloggt sein.

Thunderbird und verschlüsselte Mail-Anhänge

Posted on by

Als Linux-Anwender verwende ich neben Kmail manchmal Thunderbird unter Linux. Dort wird zur Verschlüsselung die Linux-OpenPGP Software herangezogen. Unter Windows hingegen kommt das Enigmail Plugin mit der OpenPGP Software im Hintergrund zum Zuge. Hier gibt es ein kleines Problemchen, dass auch für Linux Anwender als Verfasser verschlüsselter Mails interessant ist, wenn der Empfänger Windows Anwender ist.

Ein Bekannter, der Thunderbird unter MS Windows einsetzt, hatte nun das Problem, dass er Anhänge von Mails, die ich ihm verschlüsselt geschickt hatte, nicht öffnen konnte. Vielmehr erhielt er die Fehlermeldung “IMAP-Nachricht ist zu groß zum Entschlüsseln”. Man möge es mir glauben: Die Mail und der Anhang waren winzig. Unter Linux hatte ich dieses Problem nicht. Der Kollege greift tatsächlich, wie die Fehlermeldung es andeutet, auf einen IMAP-Server zu.

Als Ursache entpuppte sich eine Einstellung des Enigmail Plugins unter Windows. Klickt man in Thunderbird unter MS-Windows den Menüpunkt “OpenPGP” an, und geht man dann weiter zu “Einstellungen” und zum Reiter “Erweitert”, so findet man eine Checkbox für den Punkt

“Anhänge nur herunterladen, wenn diese geöffnet werden sollen (nur bei IMAP)”.

Dieser Punkt muss deaktiviert werden, wenn die Anhänge verschlüsselter Mails in Thunderbird geöffnet werden sollen. Ich meine, die Fehlermeldung ist wirklich irreführend. Als Versender verschlüsselter Mails sollte man daher seine Windows-Adressaten auf diesen Punkt hinweisen.