Terminal-Protokolle: Telnet, rlogin, SSH

netplanet Werbung

Die klassischen Remote-Werkzeuge Telnet, rlogin und das verschlüsselnde SSH arbeiten mit der Kommandozeile und gehören zu den universellen Remote-Werkzeugen, mit denen sich nicht nur Computer, sondern auch einfachere Gerätschaften wie Netzwerkgeräte oder andere elektronische Geräte fernbedienen lassen, sofern diese netzwerkfähig sind und die entsprechenden Dienste dort implementiert sind.

Remote-Steuerung

Können Sie sich noch (falls Sie nicht schon zu jung sind) an Fernsehgeräte erinnern, die keine Fernbedienung besaßen und die Änderung der Lautstärke oder die Programmwahl direkt am Gerät vorgenommen werden mussten? Vermutlich war die Fernbedienung moderner Fernseher die erste Fernbedienungstechnik, mit der Konsumenten das erste Mal auf erheblich einfachere Weise ein Gerät bedienen konnten.

Die Remote-Steuerung eines Computers hat seine Wurzeln eher weniger im Komfortanspruch, sondern bei der Kostenersparnis. Damalige Großrechner waren für ihre Käufer eine immens teure Angelegenheit und die kostbare (und vor allem teure) Rechenzeit musste möglichst effizient genutzt werden. Aus diesem Grund war die Fernbedienung von Großrechnern, die teilweise an Standorten viele Kilometer weit entfernt standen und über Stand- oder Wählleitungen mit den Arbeitsplätzen verbunden waren, in vielen Fällen der einzig erschwingliche Weg, überhaupt EDV-Dienstleistungen nutzen zu können. Die Remote-Steuerung von Rechnern hat also eine uralte Geschichte in der Computerwelt und hängt unmittelbar mit ihr zusammen.

Da frühe Benutzeroberflächen zeilenorientiert daherkamen und man von der so genannten Kommandozeilenschnittstelle (englisch "Command Line Interface" oder kurz "CLI") sprach, mussten für heutige Verhältnisse auch nur relativ wenige Daten zur Fernsteuerung übertragen werden, so dass es selbst mit damaligen Modemverbindungen nur geringe Zeitverzögerungen gab, die unmittelbar durch die Datenübertragung bedingt waren.

Exkurs: Was ist eine Shell?

Der Begriff "Shell" hat in der Welt der elektronischen Datenverarbeitung nichts mit dem niederländischen Ölkonzern zu tun, sondern eher mit einer Muschel, wobei die richtige Bedeutung des Begriffes aus der Übersetzung "Gehäuse" oder "Schale" abgeleitet wird. Eine Shell dient als Schnittstelle zwischen einem Benutzer und einem Kern und wird in der elektronischen Datenverarbeitung als Bezeichnung für alle Arten von Benutzerschnittstellen verwendet. Während eine grafische Benutzeroberfläche (Graphical User Interface oder kurz GUI) vornehmlich mit einem Zeigerinstrument wie einer Computermaus bedient wird, ist die weit ältere Form der Benutzerschnittstelle der Kommandozeilenschnittstelle (Command Line Interface oder kurz CLI). Dieser wird rein über eine Tastatur bedient und findet sich beispielsweise unter dem Betriebssystem Windows noch in der DOS-Eingabeaufforderung unter dem Programm "cmd.exe" oder unter modernen Windows-Versionen unter dem Namen PowerShell.

Der ursprüngliche Aufbau einer Großrechnerumgebung, wie sie zu Beginn des Computerzeitalters und vor der Einführung der so genannten Mikrocomputer oder Personal Computer war, ist streng sternförmig. In der "Mitte" eines solchen Aufbaus ist die zentrale Recheneinheit angeordnet, die die eigentlichen Datenverarbeitung vornimmt. Hier werden Rechenoperationen ausgeführt und Daten gespeichert. An diesen Großrechner sind nun die so genannten Terminals angeschlossen, das sind die eigentlichen Arbeitsplätze für Benutzer des Großrechners. Vereinfacht gesehen bestehen diese aus einem Bildschirm, Eingabe- (z.B. Tastatur) und Ausgabewerkzeugen (z.B. Drucker). Die Arbeitsplätze sind räumlich nicht unbedingt unmittelbar am Großrechner, sondern können beispielsweise auch innerhalb eines Gebäudes stationiert sein. Charakteristisch für eine Großrechnerumgebung ist jedoch, dass alle Terminals zwingend ständig mit dem Großrechner verbunden sein müssen, da die Terminals selbst keine eigene Verarbeitungseinheiten haben.

Telnet

Telnet ist der älteste Dienst im Internet und hat seine Ursprünge noch im ARPANet, dem Vorläufer des heutigen Internet (siehe hierzu auch Die Geschichte des Internet). Es wurde mit der Intention entwickelt, Universitäten und Forschungseinrichtungen miteinander durch das ARPANet zu vernetzen und allen angeschlossenen Einrichtungen den Zugang zu Großrechnern ermöglichen, die an einer anderen Stelle im ARPANet standen. Diese Fernzugriffe wurden mit Telnet bewerkstelligt. Das Kunstwort "Telnet" bildet sich aus den jeweils ersten drei Buchstaben der Begriffe "Telecommunication" und "Network".

Arbeitsweise von Telnet

Ein Telnet-Client emuliert ein Terminalprogramm auf Seiten des Benutzers und leitet diese Kommunikation über ein Netzwerk an den entfernten Rechner. Auf diesem entfernten Rechner ist wiederum ein Telnet-Server installiert, der die Kommunikation empfängt und mit dem Server interagiert. Da die Telnet-Kommunikation transparent ist, es also für den Server selbst keinen Unterschied macht, ob ein Benutzer direkt am Gerät sitzt oder über eine Fernsitzung per Telnet arbeitet, ist es für den Benutzer im Normalfall so, als ob er direkt am Gerät sitzen würde. Da dennoch auf dem Server explizit ein Telnet-Dienst und auf dem Rechner des Benutzers ein Telnet-Client vorhanden sein muss, ist eine gute Trennung zwischen Rechner und Telnet-Schnittstellen möglich, was für eine Administration enorm wichtig ist.

Da Telnet grundsätzlich plattformübergreifende Fernsteuerung ermöglicht, also beispielsweise problemlos auf einem Windows-Rechner mit einem Telnet-Client eine Sitzung auf einem Unix-Rechner gestartet werden kann, besitzt Telnet umfangreiche Möglichkeiten und Werkzeuge zum Aushandeln von Verbindungsparametern. Telnet ist deshalb ein sehr universelles Werkzeug zur Fernsteuerung und trotz einer fehlenden Verschlüsselung der Kommunikation ein weit verbreitetes Werkzeug, mit dem viele Gerätschaften ferngesteuert oder konfiguriert werden können.

Quasi als Nebeneffekt nutzbar macht sich ein Telnet-Client auch als Werkzeug zur Analyse von Internet-Diensten. Beispielsweise ist es problemlos möglich, per Telnet eine POP3-Mailbox einzusehen (wenngleich dies nicht sonderlich komfortabel ist). Ist eine Telnet-Sitzung zu einem entsprechenden POP3-Server aufgebaut (wichtig ist hierbei die Telnet-Verbindung auf den entsprechenden POP3-Port 110), kann dieser direkt mit der Eingabe von POP3-Befehlen bedient werden.

Aus der Unix-Welt: rlogin aus den R-Tools

Häufig in der Unix-Welt ist nach wie vor das Werkzeug rlogin zu finden. Es gehört zu den so genannten "R-Tools", einer Sammlung von netzwerkfähigen Abwandlungen von Unix-eigenen Befehlen, die zur besseren Kennzeichnung, dass sie die Netzwerkvariante des jeweiligen Befehles sind, ein vorangestelltes "r" im Befehlnamen tragen. Während der Befehl login den Zugriff über ein direkt angeschlossenes Terminal ermöglicht, ist rlogin in diesem Fall also ein Programm, mit dem über das Netzwerk auf einen Unix-Rechner zugegriffen werden kann.

Oberflächlich betrachtet ähneln sich Telnet und rlogin stark, haben aber doch grundsätzliche Unterschiede. Der größte davon ist, dass rlogin speziell für die Nutzung unter Unix-Betriebssystemen entwickelt wurde und deutlich weniger komplex als Telnet ist. Da ursprünglich bei der Entwicklung der R-Tools davon ausgegangen wurde, dass sowohl der entfernte Rechner, als auch das Zielsystem Unix-Betriebssysteme haben, wurden viele Dinge weggelassen, die Telnet von Hause aus mitbringt, beispielsweise die Notwendigkeit, Übertragungsparameter der Sitzung miteinander auszuhandeln. Vereinfacht gesagt überträgt ein rlogin-Client alles das über das Netzwerk zum fernzusteuernden Zielsystem, was in die Tastatur eingegeben wird und umgekehrt überträgt das Zielsystem die gesamte Ausgabe zeichenweise an den rlogin-Client. Da die R-Tools in vielen Unix-Betriebssystemen zu den Systembefehlen gehören, also von Hause aus zum Befehlsumfang des Betriebssystems dazugehören, muss in vielen Unix-Implementierungen noch nicht einmal ein rlogin-Server installiert, sondern lediglich freigeschaltet werden.

Darüber hinaus bieten die R-Tools noch einige weitere Spezialitäten, beispielsweise die Autorisierung des Fernzugriffes durch die Absenderadresse, ohne dass ein Passwort eingegeben werden müsste. Dies ist freilich in öffentlichen Netzen wie das Internet eine äußerst gefährliche Angelegenheit, da sich die Absenderadresse unter Umständen ohne großen Aufwand fälschen lässt.

Neben rlogin und rsh werden genau genommen noch einige weitere Unix-Befehle zu den "R-Tools" gezählt, die ebenfalls Abwandlungen von Unix-Befehlen sind, die ohne den anführenden Buchstaben "r" bekannt sind:

  • rsh ("Remote Shell")
    Dient zum Starten von Programmen und Befehlen auf entfernten Unix-Rechnern. rsh führt dabei im Hintergrund eine Anmeldung am System durch den Befehl rlogin aus.
  • rcp ("Remote Copy")
    Dient zum Kopieren von Dateien auf einem Unix-Rechner, aber auch zum Kopieren von Dateien zwischen zwei Unix-Rechnern.
  • rexec ("Remote Execute")
    Im Gegensatz zu rsh eine andere Form, Programme und Befehle auf einem Unix-Rechner zu starten, bei dem das Passwort verschlüsselt übertragen wird.
  • rwho ("Remote Who")
    Ausgabe von aktuell angemeldeten Benutzern am Unix-System.
  • ruptime ("Remote Uptime")
    Angabe von Laufzeitdaten aller Systeme im Netzwerk.

Obwohl die R-Tools immer noch häufig im Einsatz sind, muss vor deren Nutzung im Internet und auch in lokalen Netzwerken, die nicht vollständig unter eigener Kontrolle stehen, ausdrücklich gewarnt werden, da die zu übertragenden Daten der Befehle unverschlüsselt sind. Bei den R-Tools kommt erschwerend hinzu, dass deren Nutzung auf Zielsystemen auch so konfiguriert werden kann, dass keine Passwortauthentifizierung notwendig ist. Diese Gefahr darf nicht unterschätzt werden, selbst wenn es sich nur um Verbindungen innerhalb eines lokalen Netzwerks handelt.

Secure Shell (SSH)

Vor allem aufgrund der fehlenden Verschlüsselung der Kommunikation bei Telnet und den R-Tools haben sich Administratoren Gedanken darüber gemacht, wie auch für Fernzugriffe einer Remote Shell eine sichere und verschlüsselte Kommunikation etabliert werden kann. Ergebnis dieser Entwicklungen ist eine Entwicklung eines finnischen Entwicklers namens Tatu Ylönen, der 1995 die so genannte Secure Shell (SSH) vorstellte, die als sichere Ersatzlösung für Telnet und rlogin bzw. rsh gedacht ist und auch empfohlen wird. Von der Architektur her ist SSH ähnlich aufgebaut wie Telnet; ein Benutzer baut von seinem Rechner mit einem SSH-Client zu einem fernzusteuernden Rechner auf, auf dem wiederum ein SSH-Server als Dienst installiert ist. Kernstück von SSH ist die Möglichkeit, die Kommunikation zwischen Client und Server von Hause aus kryptografisch zu verschlüsseln. Angewendet wird hierbei eine hybride Verschlüsselung (siehe hierzu auch Verschlüsselungsverfahren) in mehreren Stufen:

Die Authentifizierung erfolgt mit dem symmetrischen Verschlüsselungsverfahren RSA. Je nach Konfiguration ist es einstellbar, dass der Benutzer sich mit einem Passwort und/oder mit einem eigenen Verschlüsselungszertifikat authentifiziert. Während dieser Authentifizierung wird zwischen SSH-Client und -Server ein geheimer Schlüssel erzeugt, der dann zur Verschlüsselung der Sitzung mit einem symmetrischen Verschlüsselungsverfahren dient. Standardmäßig ist dies das symmetrische Verschlüsselungsverfahren AES, allerdings können auch andere symmetrische Verschlüsselungsverfahren genutzt werden, je nach Verfügbarkeit.

Bei SSH unterscheidet man zwischen mehreren Evolutionsstufen im Laufe der Jahre, die teilweise dramatische Funktionserweiterungen mit sich brachten. Während die erste Version namens SSH-1 weitgehend auf Terminalfunktionen beschränkt war, wurde es mit der zweiten Version SSH-2, die ein Jahr später im Jahre 1996 vorgestellt wurde, möglich, SSH auch als Übertragungstunnel für weitere Anwendungen zu nutzen, beispielsweise für eine verschlüsselte Variante von FTP oder auch zum kompletten Durchleiten (Tunneln) von TCP-Ports, um auf diese Weise ansonsten unverschlüsselt übertragene Kommunikation verschlüsselt zu übertragen. Generell ist SSH-2 der früheren Version vorzuziehen, da SSH-1 einige Schwächen beim Authentifizierungsmechanismus aufweist und SSH-2 modularer in seinen Bestandteilen ist.

Lizenzmäßig war SSH anfänglich Freeware, während Ylönen kurz nach Erscheinen der ersten Version im Dezember 1995 das Unternehmen SSH Communications Security gründete, das die kommerzielle Vermarktung von SSH übernahm. Im Jahre 1999 erfolgte schließlich die Trennung der Softwareentwicklung in einen kommerziellen Ast (mit der Software SSH Tectia von SSH Communications Security) und einen nichtkommerziellen (mit dem OpenSSH-Projekt). Letzterer entwickelt die Software auf Basis von Open Source weiter. In der Zwischenzeit ist SSH mit SSH-2 ein anerkanntes Protokoll, dessen Architektur im Januar 2006 in einem offiziellen RFC (RFC 4251) der IETF im Internet definiert wurde (siehe hierzu auch Standardisierung im Internet).

Weiterführende Links

http://www.openssh.org/de/index.html
Deutschsprachige Homepage des OpenSSH-Projekts

http://www.de.ssh.com/
Deutschsprachige Homepage des Unternehmens SSH Communications Security

WERBUNG
Zum Beginn dieser Seite