Client - Telnet & Co.

Übersicht

Die in diesem Abschnitt vorgestellten Client-Anwendungen arbeiten alle auf der Konsole. Ihre Gemeinsamkeit liegt im Versuch, die Ausführung von Kommandos auf entfernten Rechnern dem lokalen Verfahren anzugleichen. Der wesentliche Unterschied aus Sicht eines Anwenders ist die Sicherheit der einzelnen Mechanismen.

Telnet ermöglicht dabei »nur« eine Sitzung auf dem entfernten Rechner, während die r-Utilities und die Secure Shell auch Kommandos zum Kopieren zwischen Rechnern und zum entfernten Ausführen von Programmen beinhalten.

Etwas genauer werden die dahinter stehenden Prinzipien im Abschnitt Server - Telnet&Co beleuchtet.

Telnet

Telnet ermöglicht das Eröffnen einer Sitzung auf einem entfernten Rechner. Das zu Grunde liegende Protokoll TELNET wurde so entworfen, dass es auch in heterogenen Umgebungen zuverlässig arbeiten kann. Als Folge daraus ist die Arbeit über telnet halt doch nicht ganz so, als würde man lokal seine Eingaben tätigen.

In der Hauptsache ist es die Verfügbarkeit einiger Tastenkombinationen, die bei lokalem Aufruf eventuelle Sonderfunktionen implementieren, während einer Telnet-Sitzung allerdings als Steuerzeichen interpretiert werden und damit dort in der gewohnten Terminologie nicht zur Verfügung stehen.

Das Mapping zwischen den lokalen Einstellungen und denen auf dem Server wird daher auch als Terminalemulation bezeichnet und es existieren eine Reihe von Standards (bspw. vt100, vt220, xterm), die alle Clients und Server unterstützen sollten.

Zahlreiche Optionen des Telnet-Clients telnet beschäftigen sich daher auch mit den Einstellungen der Emulation und bei Initiieren einer neuen Telnet-Sitzung handeln Client und Server zunächst die Sitzungsparameter aus:

Anhand der Ausgaben ist das Frage-Anwort-Spiel zwischen Client und Server leicht nachzuvollziehen. Der Client sendet »SENT« zum einen, bittend »WILL« (ich möchte...), zum anderen, fordernd »DO« (ich mache...) oder auch ablehnend »WONT« (ich möchte nicht...) seine Verhandlungspositionen zum Server, welcher antwortet und seinerseits Vorschläge zur Sitzungsgestaltung einbringt. Im Beispiel strebt der Client den »Linemode« an (SENT WILL LINEMODE), der Server lehnt den Wunsch ab (RCVD DONT LINEMODE)... Sind alle Parameter der Sitzung geklärt, sendet der Server die Login-Aufforderung.

Das Anmelden mit der Nutzerkennung »root« wird in den meisten Fällen scheitern, da der Terminal-Zugang nicht als sicher einzustufen ist. Die Terminals für das Root-Login müssen explizit in der Datei /etc/securetty benannt sein.

Während einer Sitzung kann die Terminalemulation des Servers beeinflusst werden, indem die dortige Shellvariable $TERM mit einem neuen Wert exportiert wird, auch kann der Kommandomodus von telnet über das so genannte Fluchsymbol [Ctrl][AltGr][9] erreicht werden. Nach Eingabe der meisten Kommandos gelangen Sie zur aktuellen Sitzung zurück:

Die wichtigsten Optionen beim Start

Wichtige Optionen beim Start von telnet sind neben der Angabe des Zielrechners eine nachfolgende Portnummer, falls Telnet sich nicht an den Standardport 23 des Zielrechners verbinden soll. Diese Möglichkeit spielt vor allem zum Debuggen bestimmter Dienste eine Rolle, allerdings lassen sich nicht alle Dienste auf so einen interaktiven Plausch ein.

Das nachfolgende Beispiel zeigt eine andere Art Mails zu versenden, den direkten Dialog mit Sendmail (SMTP an Port 25)...

Mit der Option -a wird das automatische Anmelden beim Server versucht, d.h. der lokale oder der mit der Option -l Name angegebene Nutzername wird automatisch als Loginname gesetzt (indem die Variable $USER gesetzt und exportiert wird) und es erscheint nur noch die Passwortabfrage. Bei Eingabe eines falschen Passwortes erscheint ein neues Login-Prompt. Wie viele Fehlversuche zulässig sind, bevor der Server die Verbindung kappt, hängt von dessen Konfiguration ab.

Zum Debuggen einer Sitzung kann die Option -d angegeben werden, sie erfordert allerdings Root-Rechte.

Neuere Telnet-Versionen sollen auch verschlüsselte Sitzungen unterstützen, indem sie mit der Option -x initiiert werden, allerdings erntete ich bislang immer die Ausschrift «telnet: Warning: -x ignored, no ENCRYPT support.«.

Die wichtigsten Kommandos im interaktiven Modus

Um innerhalb einer Telnet-Sitzung Verbindung zu einem Server aufzunehmen, dient das Kommando open:

Die Kommandos logout und close besitzen dieselbe Bedeutung und beenden die aktuelle Verbindung. Ein quit beendet zusätzlich die Telnet-Sitzung.

Mit set bzw. unset lassen sich Variablen von Telnet setzen bzw. löschen. Variablen beeinflussen u.a. die Wirkungsweise von Kommandos oder sie steuern die Behandlung von Sonderzeichen. Geben Sie innerhalb von Telnet »set ?« ein und Sie erhalten eine Liste der unterstützten Variablen nebst kurzer Erläuterung.

Das Kommando status wurde im letzten Beispiel schon benutzt und zeigt die wichtigsten Eigenschaften der aktuellen Sitzung an. Auch toggle war bereits in Erscheinung getreten. Es schaltet einfach die Flags des Arguments um (zwischen TRUE und FALSE). Zwei interessante Argumente zur Überwachung des Datenaustauschs zwischen Client und Server sind options, das die Protokollbearbeitung veranschaulicht, und netdata, womit der Netzwerkverkehr in hexadezimaler Form überwacht werden kann.

Die r-Utilities

Die r-Utilities sind eine Sammlung von Netzwerkkommandos, die einige wichtige Unix-Kommandos um die Netzwerkfähigkeit erweitern. Zu den Kommandos zählen: rlogin, rsh, rcp, ruptime, rwho und rexec. Trotz der mit den Kommandos verbundenen Sicherheitsrisiken ist ihr Einsatz in geschlossenen Unix-Netzwerken weit verbreitet.

Vorab sei bemerkt, dass die in Form der Manuals beiliegenden Dokumentationen zu den nachfolgenden Kommandos nicht mit den Möglichkeiten dieser übereinstimmen. Rufen Sie »<Kommando> --help« auf und vergleichen Sie die Liste der Argumente mit denen aus dem Manual.

Gleichsetzung von Benutzerkennungen

Diese Möglichkeit betrifft die Kommandos rlogin, rsh und rcp und erlaubt bei entsprechender Konfiguration das passwortfreie Anmelden auf dem Zielrechner. Die Authentifizierung eines Benutzers erfolgt dabei anhand von Tabellen, die Paare von Rechnernamen und Benutzerkennzeichen enthalten. Der Administrator des Servers kann hierzu eine global gültige Datei /etc/hosts.equiv anlegen, so dass ein in ihr enthaltener Benutzer, der vom benannten Rechner aus die Anmeldung unter dem selben Benutzernamen versucht, sofortigen Zugang erhält. Einziges Benutzerkennzeichen, dem niemals passwortfreier Zugang gewährt wird, ist root.

Sollte in der Datei »/etc/hosts.equiv« keine Übereinstimmung eines Rechner-Benutzer-Paares gefunden werden, so wird im Heimatverzeichnis des Benutzers nach einer Datei .rhosts gesucht. Der Inhalt der Datei ist allerdings nur relevant, wenn diese Datei root oder dem Benutzer selbst gehört und sie nur vom Eigentümer beschreibbar ist. Der Aufbau dieser Datei ist analog zum Aufbau der /etc/hosts.equiv:

Der Benutzer »tux« erhält von den Rechnern »erde.galaxis.de« und »melmac.outside.all« aus passwortfreien Zugang unter der Kennung »user« auf dem Rechner »sonne.galaxis.de«. »alf« darf nur von »melmac.outside.all« aus ohne Angabe des Passwortes zugreifen und damit es auch lokal für den Benutzer selbst funktioniert, ist auch ein lokaler Eintrag enthalten.

rlogin

Remote Login gleicht funktioniell sehr stark dem Kommando telnet. Es verbindet sich zu einem Server (rlogind, TCP-Port 513), der eine Login-Prozedur startet und die Verbindung über ein Pseudoterminal betreibt. Im Unterschied zu telnet kennt rlogin kein Protokoll, um Übertragungsparameter mit dem Server auszuhandeln.

Verbinden Sie sich recht häufig mit einunddemselben Server, so lässt sich der Tippaufwand verringern, indem Sie einen Link unter dem Rechnernamen des Servers auf das Programm rlogin angelegen:

Zum Beenden einer rlogin-Sitzung geben Sie entweder [Ctrl][D] oder das Escape-Zeichen (Voreinstellung ist die Tilde) gefolgt von einem Punkt ("~.") ein. Alternativ endet die Sitzung, sobald Sie die Shell auf dem Server beenden (exit).

Wichtigste Kommandozeilenoptionen sind -l <Nutzername>, das die Anmeldung auf dem Server unter dem angegebenem Namen versucht, und -e <Escape-Zeichen<, um ein anderes Zeichen (als die Tilde) als »Fluchtsymbol« zu vereinbaren.

rsh

Remote Shell ermöglicht das Ausführen von Kommandos auf einem anderen Rechner. Serverseitig wartet der Dämon rshd auf TCP-Port 514. Wird rsh ohne Argumente aufgerufen, so ruft das Kommando implizit rlogin auf, um eine Sitzung auf dem Server einzuleiten. rsh wird normalerweise mit dem Servernamen und dem zu startenden Kommando aufgerufen. Letzterem können beliebig viele Argumente folgen, die direkt dem Server übergeben werden. Vergessen Sie nicht, enthaltene Sonderzeichen vor der Interpretation durch die lokale Shell zu schützen.

rsh bedingt den passwortfreien Zugang auf dem Server, sonst hagelt es nur ein »Permission denied«. Mit der Option -l <Nutzername> können Sie sich unter einem anderen Namen anmelden.

Einschränkungen: Ein paar Unterschiede zum lokalen Kommandostart gibt es dann doch... Zum einen geht der Rückgabewert des Kommandos verloren. Auch sollten Sie keine Editoren oder andere interaktiv arbeitende Kommandos entfernt starten, da Sie keine Möglichkeit haben, diese mit Eingaben zu füttern (der Start gelingt schon...).

rcp

Remote Copy ist das Netzwerkpedant zum lokalen cp. Nahezu alle Optionen (die im Netzwerk sinnvoll sind) des lokalen Vorbildes sind implementiert, u.a. auch -r zum rekursiven Kopieren ganzer Verzeichnisstrukturen. rcp vermag Dateien vom lokalen Rechner zu einem anderen zu übertragen, ebenso kann der umgekehrte Weg gegangen werden und es besteht sogar die Möglichkeit, den Kopiervorgang zwischen zwei entfernen Rechnern von der lokalen Konsole aus zu veranlassen.

Der Aufruf des Kommandos lautet:

»user« ist nur anzugeben, wenn sich das Nutzerkennzeichen des lokalen Benutzers von denen auf den entfernen Rechnern unterscheidet. Ist der lokale Rechner Ort der Quellen oder des Zieles, so kann auch die Angabe dessen Namens entfallen. Quelle und Ziel können die üblichen Metazeichen enthalten, jedoch müssen diese vor der Interpretation durch die Shell geschützt werden. Wird bei der Angabe der Dateinamen auf die Pfade verzichtet, bezieht sich diese immer auf das Heimatverzeichnis.

rexec

Remote Execute ist eine weitere Möglichkeit, um Kommandos auf einem anderen Rechner auszuführen. Im Unterschied zu rsh wird hier mit einer Login-Prozedur begonnen und ein verschlüsseltes Passwort gesendet. Das Kommando selbst ist mit Vorsicht zu genießen, da das permanente Prozedere mit dem Anmeldevorgang oft verleitet, die Option -p <Passwort> zu verwenden. Dieses Passwort muss auf der Kommandozeile im Klartext angeben werden, d.h. ggf. für in der Nähe befindliche Personen lesbar!

Um die Abfrage des Loginnamens zu unterdrücken, kann dieser mit der Option -l <Nutzername> als Argument angegeben werden.

rwho und ruptime

Remote Who und Remote Uptime erweitern die gleichnamigen Kommandos auf die Netzwerkumgebung, d.h. mit rwho erhalten Sie Informationen über alle im lokalen Netzwerk angemeldeten Benutzer (analog zum lokalen who) und ruptime zeigt u.a. die Laufzeit aller Rechner des Netzes an (Zeit seit dem letzten Systemstart).

Beide Kommandos werten die Informationen der Dateien im Verzeichnis »/var/spool/rwho« aus.

Diese Datei wird in regelmäßigen Abständen vom rwhod aktualisiert, der die lokalen Informationen per Broadcast ins Netz entlässt und die Nachrichten anderer Dämonen empfängt. In großen Netzen kann dadurch die Netzlast enorm anwachsen. Deshalb und auch aus Sicherheitgründen werden diese Dienste meist deaktiviert.

Secure Shell

Solange wie es die Secure Shell schon gibt, sollte man meinen, angesichts der gravierenden Sicherheitslücken von Telnet und Remote Shell, sie hätte mit den Altlasten von Unix schon längst aufgeräumt. Doch leider ist Ihr Einsatz, trotz hoher Verfügbarkeit, noch nicht zur Selbstverständlichkeit erhoben worden.

Dabei sind verschlüsselte Übertragungen und passwortfreies Anmelden auf entfernten Rechnern doch genau das, was der Anwender sich wünscht. In diesem Abschnitt lernen Sie die Belange des ssh-Clients kennen.

Die Konfiguration des Clients

Die default-Einstellungen zum Secure Shell Client legt der Systemverwalter in der Datei /etc/ssh_config fest, dem Benutzer bleibt es überlassen, eigene Konfigurationen in einer Datei ~/.ssh/config vorzunehmen. Existiert letztere Datei im Heimatverzeichnis des Benutzers, so wird das Kommando ssh diese beim Start einlesen, ansonsten entnimmt es die Informationen der globalen Datei.

In der Beispieldatei sind alle Zeilen auskommentiert. In den allermeisten Fällen sollte dies die praktischen Bedürfnisse auch abdecken. Was sich hier dennoch konfigurieren lässt, möchten wir Ihnen nicht vorenthalten (eine Beschränkung auf ausgewählte Einträge sei uns gestattet):

Die Verwendung des Clients

Es ist an der Zeit, eine ssh-Sitzung zu eröffnen. Um einen Eindruck vom Ablauf das Anmeldens zu erhalten, schalten wir die erweiterte Ausgabe ein (Option -v):

Angenommen, unser Passwort besitzt nur 3 Zeichen...:

Offensichtlich verfügt der Server über eingebaute Regeln bezüglich der Passwort-Sicherheit. Ein Zugangsversuch mit »starkem« Passwort provoziert folgende Reaktion:

Die folgende Sitzung läuft analog zur Arbeit am lokalen Terminal ab. Sämtlicher Datenverkehr geht verschlüsselt übers Netz.

Die Optionen zum Start von ssh sind vielfältig und die meisten werden Sie vermutlich niemals benutzen. Eine kleine Auswahl stellt die folgende Tabelle zusammen:

Passwortfreies Login

Prinzipiell ist eine derartige Konfiguration auf drei Wegen möglich. Zum einen über die Gleichsetzung von Nutzerkennungen über Rechnergrenzen hinweg (analog dem Vorgehen in der »/etc/hosts.equiv«) und zum anderen durch die Authentifizierung mittels der Hostschlüssel und zum dritten durch eine Kombination aus beiden. Die Konfiguration der beiden erstgenannten Methoden sei nun vorgestellt:

Gleichsetzung von Nutzerkennungen

Diese Methode gilt als unsicher und wird deswegen in der Standardkonfiguration des Servers nicht unterstützt. Dennoch sei das Vorgehen auf Clientseite hier skizziert:

Root hat nun die Möglichkeit, in einer Datei »/etc/shosts.equiv« Paare aus Rechner- und optionalem Nutzernamen einzutragen. Einem Nutzer, der sich unter einem solchen Namen vom entsprechenden Rechner aus anmeldet, wird der Zugang ohne Angabe eines Passwortes gewährt. Er gilt als »vertrauenswürdig«. Der Aufbau der Datei »/etc/shosts.equiv« ist analog zur »/etc/hosts.equiv«.

Der gewöhnliche Nutzer kann ein analoges Verhalten durch Anlegen einer Datei ».shosts« in seinem Heimatverzeichnis auf dem Zielrechner erreichen. Dazu trägt er in dieser Datei Paare von Rechner- und Nutzernamen ein. Von einem solchen Rechner aus ist das passwortfreie Anmelden unter der spezifizierten Nutzerkennung möglich.

Authentifizierung mittels Hostschlüssel

Das Vorgehen ist einfach:

1. Der Nutzer generiert ein Paar aus öffentlichem und privaten Hostschlüssel:

    

   user@sonne> ssh-keygen Initializing random number generator... Generating p: ............................++ (distance 502) Generating q: ........................++ (distance 364) Computing the keys... Testing the keys... Key generation complete. Enter file in which to save the key (/home/user/.ssh/identity): Enter passphrase: Enter the same passphrase again: Your identification has been saved in /home/user/.ssh/identity. Your public key is: 1024 33 144548000807386124839939532430378957162277213079174901455237068977\ 13993164454787934083112964351134658543398198173290652861110361504461204252\ 86082551580924057298394318368461834360161039475113029221975820200295146587\ 33721792996155067287672215631707383807208031906784470444967930777546158765\ 712311197196260549233 user@sonne Your public key has been saved in /home/user/.ssh/identity.pub

    

   Tipp: Drücken Sie bei der Frage nach den Passphrasen [ENTER]. Wenn Sie dort etwas eingeben, müssen Sie die Eingabe bei jedem Login über ssh wiederholen. Somit ermöglichen Sie ein von Ihrem eigentlichen Passwort unabhängiges Passwort.

    

2. Der Nutzer meldet sich auf dem Zielrechner an:

    

   user@sonne> ssh erde Last login: Sat Apr 1 11:38:19 2000 Have a lot of fun... No mail.

    

3. Den öffentlichen Schlüssel ~/.ssh/identity.pub des lokalen Rechners (sonne) fügt der Nutzer an die Datei ~/.ssh/authorized_keys in seinem Heimatverzeichnis auf dem Zielrechner (erde) an.

   Zum Kopieren zwischen den Rechnern existieren zahlreiche Möglichkeiten:

   • Über FTP
   • Per Mail
   • Unter X: Kopieren mittels Maus
   • Mittels scp (Secure Copy):
     
     

     user@erde> scp user@sonne:~/.ssh/identity.pub user@erde:~/temp.key user@erde> cat temp.key >> .ssh/authorized_keys

Zukünftige Sitzungen sollten ohne Angabe eines Passwortes möglich sein.

Secure Copy

Während einer Secure Shell Sitzung würde der Aufruf des Kommandos cp nur das Kopieren von Dateien innerhalb des Dateisystems des Zielrechners ermöglichen. Um dennoch Daten zwischen Ziel- und Heimatrechner auszutauschen, ohne auf FTP oder rcp zurückgreifen zu müssen, steht das Kommando scp zur Verfügung.

scp verwendet zum Datentransfer die Secure Shell und bietet damit dieselben Authentifizierungsmechanismen und dieselbe Sicherheit. Der Aufruf besitzt folgendes Format:

Die Angabe der Dateinamen unterscheidet sich nicht vom Vorgehen des »lokalen« cp, auch lassen sich wie gewohnt Verzeichnisse rekursiv mit der Option -r kopieren. Allerdings kommen nun noch die Namen der Nutzer und Rechner hinzu.

Der Nutzer (user) ist anzugeben, wenn sich das Nutzerkennzeichen auf dem Quell- bzw. Zielrechner vom lokalen Nutzerkennzeichen unterscheidet. Sonst kann die Angabe entfallen.

Der Rechnername (host) ist anzugeben, wenn es sich nicht um den lokalen Rechner handelt.

Im nachfolgenden Beispiel kopieren wir eine Datei vom Rechner »erde« unter dem dortigen Login »tux« auf den lokalen Rechner. Es sei vorausgesetzt, dass uns das passwortfreie Anmelden auf »erde« als »tux« möglich ist (falls dem nicht so ist, würden wir zur Eingabe eines Passwortes aufgefordert werden:

Neben dem schon genannten -r zum rekursiven Kopieren sind noch die Optionen -q und -C nützlich, die die Statistikausgabe verhindern bzw. eine Komprimierung der zu übertragenen Daten vornehmen.