www.hollants.com

August 28, 2008

You are here: Home - TUD-Newsgroups per SSH-Tunnel lesen

Print version (soon)

Home

Notebooks

Hard & Software

Webstuff

Projects

Verschiedenes

This site

TUD-Newsgroups per SSH-Tunnel lesen

Hintergrund

Dieses Dokument entstand aus der öfters nachgefragten Problemstellung, daß der Zugriff auf die Newsgroups der TU Darmstadt nur für Rechner der Domain tu-darmstadt.de möglich ist. Aus gutem Grund, schließlich sollen sie nicht wie andere Newsgroups zugespammt werden bzw. sollen Ankündigungen, die TU-interner Natur sind, nicht für die ganze Welt sichtbar sein.

Diese Einschränkung stört einen in den Computerpools natürlich wenig, anders sieht die Situation beim PC zuhause aus. Diesem wird nämlich immer der Zugriff auf den Newsserver verweigert werden, zumindest wenn man dies über einen Internet-Provider versucht. Man könnte sich natürlich über die Uni einwählen, dann hätte der eigene Rechner eine IP-Adresse, die im DNS (Domain Name System) auf irgendwas.tu-darmstadt.de aufgelöst würde. Aber nicht jeder erreicht Darmstadt zum Ortstarif, und ins Internet kommt man ja endlich auch zum Pauschalpreis. Also muß eine andere Lösung her.

Die Idee

Die Lösung des Problems heißt "Port Forwarding". Port Forwarding bedeutet, daß man ein Programm auf einem besonderen Rechner laufen läßt, welches TCP/IP-Pakete, die auf einem bestimmten Port ankommen (z.B. 8080), an einen anderen lokalen Port oder einen Port auf einem fremden Rechner weiterleitet. Jeglicher Proxydienst, z.B. der WWW-Proxy eines Internetproviders, macht im Prinzip nur "Port Forwarding" und holt stellvertretend für andere Rechner Daten aus dem Internet. Allerdings betreibt er meistens noch je nach Dienst mehr Aufwand: ein WWW-Proxy soll die geholten Seiten natürlich zwischenspeichern ("cachen").

Wir könnten uns jetzt dieses Prinzip zu Nutze machen, indem wir auf einem Rechner der TUD eben solch ein Programm laufen lassen, welches auf einem Port größer 1024 lauscht und alle Daten, die dort ankommen, an Port 119 (das ist der TCP/IP-Port für NNTP) des Newsservers weiterleitet. Für den Newsserver sähe das Ganze dann wie eine Verbindung von diesem TUD-Rechner aus.

Das sollten wir aber nicht, dürfen wir nicht und machen wir auch nicht. Warum?

Ohne weitere Sicherheitsmaßnahmen unterseits (sprich Zugriffsbeschränkung) könnte jeder im Internet das Programm ausnutzen, um sich auf dem Zielrechner auszotoben.
Selbst mit Zugriffsbeschränkungen würden wir gegen eine essentielle Regel der Uni verstoßen, indem wir ein Programm permanent laufen lassen, selbst wenn wir es nicht verwenden.
Wenn jeder Programme auf beliebigen Ports lauschen lassen würde, wären die TUD-Rechner was die Sicherheit betrifft unkontrollierbar.
Normale Proxy-Programme überträgen die Daten unverschlüsselt, d.h. jeder, der sich mit seinem Rechnern im Internet zwischen euch und der TU befindet, kann mitlesen.
etc. etc.

Es gibt genug Gründe, die nicht nur etwas mit der Sicherheit sondern auch schlichtweg mit Vernunft zu tun haben, weshalb wir diese Primitivlösung nicht wählen werden. Bitte, spart euch und den Uni-Admins den Ärger!

Es geht nämlich auch anders. Aber zunächst mal ein Argument zum obigen Problem des permant Laufen lassens: man könnte natürlich den Proxy, Bouncer, oder wie auch immer man ein solches Programm noch nennen mag, nur bei Bedarf starten. Hierzu müßte man vor dem Newsreader eben mal "kurz" auf den entsprechenden TUD-Rechner telnetten und den Proxy starten. Nachher würde man ihn ebenso wieder beenden.

Das ist zwar ein Schritt in die richtige Richtung, aber immer noch keine Lösung. Aus Sicherheitssicht spricht nämlich einiges gegen Telnet: Passwörter werden im Klartext übertragen, kriegt dies jemand mit bösen Absichten mit, hat er vollen Zugang zu eurem Account und kann z.B. Attacken auf andere Rechner starten etc.

Lange Reden, kurzer Sinn: SSH. SSH steht für "Secure Shell" und ist eigentlich dasselbe wie Telnet, nur mit fortgeschritteneren Authentifizierungsmethoden (asymmetrische Schlüssel statt Passwörter) und verschlüsselter Kommunikation. Schließlich das Bonbon schlechthin: ssh ermöglicht Port Forwarding, und zwar getunnelt durch die SSH-Verbindung.

Obige Argumente gegen einfache Proxyprogramme waren nicht gegen das Port Forwarding an sich gerichtet. Port Forwarding, oder präziser, Tunneling via SSH stellt meiner Meinung nach einen guten Kompromiß zwischen Einfachheit und Interessen der TUD dar:

es ist sicher, denn die Verbindung selbst als auch die getunnelten Daten bewegen sich nur in verschlüsselter Form über das Internet.
es ist sicher, denn ssh ist im Quelltext verfügbar, der ausgiebig studiert wurde. Sicherer als irgendein schnell zusammengepfriemelter Proxy eines Möchtegernprogrammierers auf alle Fälle.
es ist sicher und spart Resourcen, denn das Port Forwarding findet nur während einer Verbindung statt. Zudem funktioniert das Port Forwarding nur zwischen zwei genau definierten Rechnern statt zwischen potenziell Millionen von Rechnern und dem Newsserver.
es ist besonders sicher, wenn, wie später beschrieben, asymmetrische Schlüssel statt leicht anfangbare oder erratbare Passwörter verwendet werden.

SSH-Clients gibt es fast wie Sand am Meer, ich stelle hier die Schritte für das Programm "SecureCRT" vor, aber es gibt genug Alternativen. Die c't beispielsweise hat öfters mal das Programm "TerraTerm" erwähnt. Am besten, Ihr sucht euch bei WinFiles oder anderen Softwaresites einen Client aus, der SSH unterstützt. Die Schritte sollten ähnlich wie bei SecureCRT sein. Nein, ich werde niemanden irgendetwas zumailen.

Ich erläutere das Ganze hier für Leute mit RBG-Account (sprich, (Wirtschafts-)Informatiker), es lässt sich aber mit veränderten Hostnamen etc. ähnlich auf HRZ-Accounts übertragen.

Eine Verbindung zur TU Darmstadt definieren

Abbildung 1: SecureCRTs Connect-Dialog

Zunächst mal definiert man sich eine Verbindung im "Adressbuch" des jeweiligen Clients (mit dem Button links von der Schere).

Abbildung 2: Eigenschaften der TU Darmstadt-Verbindung

Als Protokoll verwenden wir ssh1, die neuere Version 2 unterliegt einigen Beschränkungen (kein lizenzfreier kommerzieller Einsatz etc.) weswegen die erste immer noch am verbreitesten ist.

Hostname ist irgendeiner der RBG-Rechner, ich habe mir hier einfach mal ultra14.rbg.informatik.tu-darmstadt.de herausgegriffen. Ich kann mir aber vorstellen, dass sich die RBG-Admins freuen wenn ihr euch auch auf ultra15 etc. stürzt, statt alle denselben Server zum Login zu verwenden.

Port 22 ist der Standardport für ssh, den lassen wir also auch so. Username ist der Name eures RBG-Accounts, Cipher bezeichnet den verwendeten Verschlüsselungsalgorithmus, der vom ssh-Daemon auf dem Zielrechner natürlich auch unterstüzt werden muß (dies ist bei 3DES, auch bekannt als Triple-DES, eigentlich immer der Fall).

Authentication könnt ihr zunächst mal der Einfachheit halber auf Password lassen, ich empfehle allerdings die Verwendung von RSA, was nichts anderes als die Verwendung von einem Paar aus öffentlichen und privaten RSA-Schlüssel bedeutet. SecureCRT bietet hier einen kinderleichten Assistenten, der diese Schlüssel generiert, ich hoffe euer Client macht das auch. Mehr hierzu später.

Die "Advanced SSH options"

Abbildung 3: Advanced SSH Options (Seite 1 von 2)

Hinter dem Button Advanced... verstecken sich wichtige Optionen, wobei allerdings die oben abgebildete Seite erst nachher bei Verwendung eines Schlüsselpaars wichtig wird. Hier könnte ich nachher den zu verwendenden (privaten) Schlüssel festlegen bzw. das Schlüsselpaar generieren oder die Passphrase (siehe später) ändern.

Abbildung 4: Advanced SSH Options (Seite 2 von 2)

Hier haben wir, was wir gesucht haben: die "Port Forwarding"-Seite ist nämlich fast das Wichtigste.

Mit obigen Einstellungen konstruieren wir nun folgendes Szenario: all der Verkehr über den lokalen Port 120 (normalerweise unter Windows und Linux unbenutzt) wird durch die ssh-Verbindung zur ultra14 und von dort zum Host news.tu-darmstadt.de auf dessen Port 119 (für NNTP/News) weitergeleitet.

Den Klick auf Save nicht vergessen und schon machen wir...

Die Probe aufs Exempel

Abbildung 5: Verbunden mit der ultra14

So sieht's aus, wenn ihr euer Passwort richtig eingegeben habt und das Ganze läuft (bei der Meldung "Unknown host key" mit Accept & Save antworten). Jetzt könnt ihr euren Newsreader, z.B. Netscape, aufrufen und ihm einen neuen Newsserver hinzufügen, nämlich localhost mit Port 120 (wichtig!). Anschließend geht's ans Newsgroups abonnieren.

Abbildung 6: Newsgroups von news.tu-darmstadt.de abonnieren

Vorsicht, das Abrufen des Newsgroups kann ein paar Minuten dauern! Danach könnt ihr aber nach Herzenslust Newsgroups abonnieren, lesen und natürlich auch etwas hineinschreiben (z.B. über die Ladezeiten dieser Seite beschweren).

Wichtig: ohne laufendem SecureCRT wird Netscape nur "Keine Antwort vom Server" oder eine ähnliche Fehlermeldung bringen! Ihr müsst euch immer erst mit der ultra14 verbinden, damit das Port Forwarding funktioniert.

Schlüsselpaare statt Passwort verwenden

Die Standardmethode, nämlich einfache Passwortabfrage, ist an sich schon recht sicher, da die gesamte Verbindung, und damit auch die Passwortabfrage, verschlüsselt wird. Mit Schlüsselpaaren arbeiten hat aber dennoch seine Vorteile, die ich hier nicht groß aufzählen will.

Man kann sich recht einfach mit SecureCRTs "RSA Key Generation Wizard" ein Schlüsselpaar erzeugen (entspricht dem Linuxbefehl ssh-keygen). Den will ich hier wirklich nicht weiter erklären, zumindest in SecureCRT ist der recht selbsterklärend. Ihr müsst nur den erzeugten öffentlichen (nicht den privaten!) Schlüssel auf konventionellen Wegen zu eurem Account bringen und die Einstellung Cipher auf RSA ändern. Ob ihr eine Passphrase (d.h. ein Passwort, welches den privaten Schlüssel nochmal zusätzlich schützt, und niemals übers Netz übertragen wird) verwenden wollt, überlasse ich euch, sicherer ist es allemal.

Aber wie kriege ich den öffentlichen Schlüssen zu meinem Account? Zum Bleistift per FTP: man nehme einen FTP-Client, verbinde sich wie bereits oben mit ultra14.rbg.informatik.tu-darmstadt.de unter Verwendung seines Accountnamen und Passworts und schiebe die Datei hoch. Anschließend (noch per Telnet) ein Unterverzeichnis ~/.ssh erzeugen (cd ~ && mkdir .ssh ) und den Inhalt des öffentlichen Schlüssels der Datei authorized_keys in diesem Verzeichnis anhängen: cat ~/identity.pub >>~/.ssh/authorized_keys). Schon sollte der Verbindungsaufbau mittels RSA klappen, u.U. mit Abfrage der Passphrase.

This page last changed:
July 26, 2004