TCP/IP Dienste

Willemers Informatik-Ecke

TCP/IP bietet eine Vielfalt von Diensten. Der Umfang wird bereits deutlich, wenn man einmal die Datei /etc/services überfliegt. In diesem Abschnitt werden die prominentesten von ihnen vorgestellt.

inet-Dämon

inetd reduziert die Zahl der Dämonen

Die meisten Serverprozesse einer UNIX-Maschine werden relativ selten benötigt. Soll deren Dienst aber angeboten werden, muss ein Prozess ständig den Port abhorchen, ob Anfragen vorliegen. Jeder dieser Prozesse benötigt Hauptspeicher. Zwar wird der Prozess bei Inaktivität bald in den Swapbereich verschoben, aber auch dieser ist nicht unerschöpflich. Zur Lösung dieses Problems gibt es den Internet-Dämon, der mehrere Ports parallel abfragt und sobald auf einem dieser Ports eine Anfrage vorliegt, den entsprechenden Server startet.

/etc/inetd.conf

Gesteuert wird inetd durch die Datei /etc/inetd.conf. Hierin stehen die überwachten Dienste und die zugehörigen Serverprogramme. Jede Zeile hat den folgenden Aufbau:

Name  Typ  Protokoll  Wartestatus  UserID  Server  Argumente

Dabei bedeuten

Name
Name des Dienstes wie er in der /etc/services steht.
Typ
stream, dgram, oder raw
Wartestatus
Hier kann wait oder nowait stehen. Es legt fest, ob eine neue Anfrage des Dienstes wartet, bis die vorherige Anfrage ausgeführt ist. Dies würde die die Parallelität der Anfragen beschränken.
UserID
meist ist die UserID, unter der der Dämon läuft root. Bei finger beispielsweise nobody.
Server
Dateiname inkl. Pfad des Serverprozesses
Argumente
Kommandozeile des Serveraufrufs

Hier als Beispiel die Auszüge aus der inetd.conf für ftp und telnet:

ftp     stream  tcp    nowait  root   /usr/sbin/tcpd  in.ftpd
telnet  stream  tcp    nowait  root   /usr/sbin/tcpd  in.telnetd

Dienst stoppen durch Auskommentieren

Will man aus Sicherheitsgründen keinen Zugang für telnet oder ftp, reicht es aus, den Eintrag in der inetd.conf mit einem Hashzeichen (#) auszukommentieren. Änderungen in der inetd.conf liest der inetd ein, wenn man ihm das Signal SIGHUP sendet.

gaston# ps -ax | grep inetd
  566 ?        S      0:00 /usr/sbin/inetd
gaston# kill -SIGHUP 566

File Transfer Protocol (FTP)

Dateitransfer, nicht Verzeichnisdienst

Wie der Name sagt, dient FTP dem Übertragen von Dateien. Es ist aber nicht ein Verzeichnisdienst wie NFS oder im PC-Bereich Novell oder NT-Server, bei dem der Verzeichnisbaum des entfernten Rechners in den eigenen Baum eingebunden wird. Beim FTP werden einzelne Dateien explizit per Befehl übertragen.

Der Client

Login

Für FTP gibt es einige Clients mit einer grafischen Oberfläche. Hier soll aber das Kommandozeilentool ftp mit seinen Kommandos interessieren. Den FTP-Client startet man es unter Angabe der Internetnummer oder des Hostnamen. Es führt zunächst einen normalen Login aus. Der Anwender wird also aufgefordert, Benutzernamen und Passwort einzugeben. Danach ist man auf dem fremden Rechner angemeldet und erhält einen eigenen ftp-Prompt.

silver> ftp gaston
Connected to gaston.willemer.edu.
220 gaston.willemer.edu FTP server (Version 6.5/OpenBSD, linux port 0.3.2) ready.
Name (gaston:arnold): arnold
331 Password required for arnold.
Password:
230- Have a lot of fun...
230 User arnold logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> quit
221 Goodbye.
silver>

Kommandos

Vom ftp-Prompt kann man wie auf einer Shell verschiedene Kommandos geben.

Daneben kennt ftp noch eine Reihe von Kommandos, die man natürlich in der Manpage findet. Letztlich reichen die vorgestellten Kommandos, um so ziemlich jeder Situation gewachsen zu sein.

time out

Eine Sitzung, über die keine Daten mehr fließen, wird nach 900 Sekunden automatisch beendet.

Mit der Option -P kann ein anderer Port angesprochen werden. Das ist besonders wichtig bei dem Zugriff über Proxies.

Automatisieren des Einloggens

~/.netrc

In manchen Fällen soll der Austausch von Dateien automatisiert werden, also beispielsweise durch Programme oder Skripten gesteuert und auch zeitversetzt durch
cron oder at gestartet werden. In solchen Situationen stört die Passwortnachfrage. Durch eine Datei namens .netrc im Heimatverzeichnis kann das Einloggen automatisiert werden. Dabei enthält diese Datei in jeder Zeile die Einträge:

Host    Benutzerkennung   Passwort

Zuerst wird der Host angegeben. Wird dieser Host als Argument des ftp genannt, gilt diese Zeile. Es wird dann automatisch die angegebene Benutzerkennung verwendet und nicht wie sonst, die gleiche, die auf dem lokalen Rechner verwendet wird. Der Eintrag des Passworts ist optional. Ist ein Passwort eingetragen, muss die Datei mit chmod auf 600 gestellt werden. Sie darf also von niemandem gelesen werden können außer dem Besitzer.

Anonymes ftp

Die ftp-Server im Internet erfordern üblicherweise keine Zugangsberechtigung, sondern lassen das so genannte anonyme ftp zu. Dazu meldet man sich mit anonymous an. Als Passwort pflegt man die eigene E-Mail Adresse anzugeben.

Konfiguration des ftp-Servers

Der tandardmäßig auf jedem UNIX System vorzufindende ftp-Server heißt ftpd und wird normalerweise über den inetd gestartet. Man kann ihn aber auch als Dämon aus den rc-Dateien starten. Dann muss ftpd allerdings mit der Option -D aufgerufen werden.

Abklemmen des ftp-Servers

Da ein ungeschützter ftp-Zugriff durchaus sicherheitskritisch ist, kann der Zugang beschränkt werden. Man kann durch Auskommentieren des ftp-Dienstes in der inetd.conf den FTP komplett abschalten.

Abschalten mit Begründung

Existiert eine Datei namens /etc/nologin, wird diese einem Client angezeigt und dann der Zugriff verweigert. Dies ist ideal für kurzfristig abgeschaltete ftp-Zugänge oder wenn man auf einen anderen Rechner verweisen will.

Benutzerausschluss

Einzelne Benutzer können ausgeschlossen werden, indem man sie in der Datei /etc/ftpusers aufführt. Trotz der anders lautenden Intention stehen hier die Anwender, die keinen Zugriff auf den ftp-Server haben sollen.

Anonymer ftp-Server

Der normale ftp-Zugang erfolgt über das Anmelden als Benutzer des Systems. Im Internet gibt es viele ftp-Server, die öffentlich Dateien zur Verfügung stellen. Man spricht von anonymem ftp, weil man sich mit der Kennung >>anonymous<< anmeldet und seine E-Mailadresse als Passwort eingibt. Letzteres ist allerdings freiwillig und nicht zwingend.

Ein Rechner kann nur entweder ein anonymes oder reguläres ftp anbieten. Ist ein anonymer Server aktiv, kann man sich nicht mehr über das normale ftp einwählen. Ein solcher Zugriff wird abgewiesen mit dem Hinweis, dass nur anonymes ftp zugelassen ist.

Der Benutzer ftp

Um ftpd als anonymen Dienst zu starten, wird der ftp-Dämon in der inetd.conf oder in der rc-Datei mit der Option -A gestartet. Es muss außerdem ein Benutzer namens ftp auf dem System existieren. Beim Login als >>anonymous<< werden die Benutzer in dessen Heimatverzeichnis gesetzt. Dort wird intern ein chroot aufgerufen, der verhindert, dass der Benutzer andere Bereiche des Verzeichnisbaums erreichen kann.

# /etc/inetd.conf
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -A
#

Es gibt noch andere FTP-Server, wie beispielsweise der WuFTP-Server, der vor allem sicherheitskritische Einstellungen ermöglicht.

TFTP, schnell und vertrauensvoll

Das Trivial File Transfer Protocol wird auch manchmal Trusted FTP genannt. Der Grund liegt darin, dass es keine Authentifizierung verlangt. Der Zugriff ist nur auf Dateien erlaubt, deren Rechte auf dem System den Zugriff für alle erlauben.

Auf den meisten Systemen ist TFTP in der inetd.conf abgeschaltet. Seine Hauptbedeutung erlangte TFTP im Zusammenhang mit Workstations, die keine eigene Festplatte besaßen, den >>diskless workstations<<. Diese haben per TFTP ihre Grunddaten von anderen Maschinen bezogen. Heutzutage findet man selten solche Geräte und aus Sicherheitsaspekten ist TFTP wenig ratsam.

Der größte Unterschied zu FTP ist eigentlich in der Realisierung. TFTP basiert auf udp, während FTP ein tcp Dienst ist.

Terminaldienst (telnet)

Mit dem Programm telnet kann man eine Terminalsitzung über das Netz auf einem fernen Rechner aufbauen. Aus Sicht des Anwenders unterscheidet sich solch eine Sitzung kaum von einer Terminalsitzung.

telnet überträgt im Klartext.

Da telnet alle Tastendrücke und Bildschirmausgaben direkt über das Netz überträgt, werden auch Passwörter im Klartext über das Netzwerk übertragen. In sicherheitskritischen Umgebungen werden darum Zugriffe per telnet ausgeschlossen. Statt dessen wird
ssh (secure shell) verwendet, das die gleiche Leistung bringt, nur dass die übertragenen Daten verschlüsselt werden.

telnet-Client

Als Argument wird \verb+telnet+ die Internetnummer oder der Hostname des Zielrechners angegeben. Auf dem Zielrechner wird ein login wie bei einem normalen Terminal gestartet. Nach der erfolgreichen Anmeldung wird auf dem Zielrechner eine Shell eröffnet und der Benutzer kann so arbeiten, als hätte er eine Terminalsitzung auf der fremden Maschine eröffnet.

Funktionstasten unzuverlässig

telnet leidet unter dem gleichen Problem wie die Terminals, nämlich dass die Terminalemulationen leider auf den Funktionstasten immer wieder versagen. In vielen Fällen werden Terminals emuliert, die gar keine Funktionstasten hatten, als sie gebaut wurden. Wie beim Terminal auch, wird die Terminalemulation über die Umgebungsvariable TERM und die Einträge in der termcap oder der terminfo gesteuert.

Testen textorientierter Server

Mit telnet kann man sehr gut textorierentierte Protokolle testen, wie sie von den meisten Internet-Services verwandt werden (beispielsweise HTTP oder NNTP). Beim Aufruf wird hinter dem Hostnamen als weiterer Parameter die Portnummer des Services angegeben und man sieht die Meldungen des Servers im Klartext. Man kann Antworten und so das Protokoll verfolgen.

Die Sitzung wird durch das Ausloggen auf dem fremden Rechner beendet.

telnet-Dämon

/etc/securetty

In der Datei /etc/securetty wird hinterlegt, welche Terminals so sicher sind, dass sich auch der Anwender root dort einloggen darf. Im Normalfall werden dort die virtuellen Terminals, die telnet verwendet dort nicht aufgeführt. Aus diesem Grund ist es meist nicht möglich, sich als root per telnet direkt anzumelden. Statt dessen verwendet der Administrator eine >>zivile<< Kennung und wechselt per su zum root.

Abschalten des Dämons

Auch der telnet-Server wird über den inetd gestartet. Dementsprechend gibt es auch einen Eintrag in der inetd.conf. Soll es keinen Zugriff per telnet auf die Maschine mehr geben, wird der Eintrag einfach auskommentiert, indem ein # an den Anfang der Zeile gesetzt wird.

r-Kommandos

Da das ständige Authentifizieren beim Anmelden innerhalb eines LANs (Local Area Network) in der Praxis sehr störend ist, gibt es die Möglichkeit, direkt auf die ferne Maschine zuzugreifen. Dabei erteilt der Anwender einem Benutzer einer anderen Maschine die Berechtigung, seinen Zugang zu benutzen. Er erteilt diese Berechtigung, indem er eine Datei namens .rhosts anlegt und in ihr die Computer und Benutzer aufzählt, die ein direktes Zugriffsrecht über die Kommandos rcp, rlogin und rsh haben sollen.

Die Befehle fragen nach der korrekten Konfiguration nicht mehr nach dem Passwort. Wie immer stehen Bequemlichkeit und Sicherheit umgekehrt proportional zueinander. Darum sind diese Protokolle auch sinnvollerweise im LAN und nicht im Internet einzusetzen. Die drei r-Kom­man­dos rcp (remote copy), rsh (remote shell) und rlogin (remote login) entstammen dem BSD und sind auf allen UNIX-Derivaten zu finden.

Die Datei .rhosts und hosts.equiv

~/.rhosts

Die r-Kommandos sollen Anwendern, die auf zwei Hosts ein Benutzerkonto haben, erlauben, sich selbst den direkten Zugang zu den eigenen Ressourcen auf dem anderen Rechner zu erlauben. Dazu legt man im Wurzelverzeichnis des eigenen Heimatverzeichnisses eine Datei namens .rhosts an. Sie darf nur für den Besitzer schreib- und lesbar sein. In dieser Datei stehen die Namen der Rechner, von denen ein Zugriff über rlogin, rcp oder rsh auf diesen Rechner erlaubt sein soll.

Da der Anwender vielleicht einen anderen Benutzernamen auf dem fremden Rechner haben könnte, ist es auch möglich, hinter dem Rechnernamen noch eine Anwenderkennung aufzuführen. Jeder eingetragene Benutzer darf von dem fremden Rechner ohne Passwort auf dem lokalen Rechner einloggen und darf frei Daten hin und her kopieren.

/etc/hosts.equiv

Alternativ kann der Systemadministrator in der Datei /etc/hosts.equiv Maschinen aufführen, denen er eine pauschale Gleichstellung bzgl. rlogin und rcp einräumen möchte. Dabei werden auch die Drucker freigegeben. Auch diese Datei darf nur Schreib- und Leserecht für den Besitzer haben und muss root gehören. Eine solche pauschale Freischaltung wird aber normalerweise nur dann gemacht, wenn beispielsweise mit zwei parallelen Servern gearbeitet wird oder wenn man im privaten Netz ohne Internetzugang arbeitet. Beispiel für eine /etc/hosts.equiv:

+gaston willemer
+idefix
+ pm7500
+@awfriends

Die erste Zeile erlaubt dem Anwender willemer auf gaston den freien Zugriff ohne Passwort. In der zweiten Zeile wird allen Anwendern von idefix der freie Eintritt gestattet.

Die dritte Zeile enthält einen gravierenden Fehler: Hier steht ein Leerzeichen zwischen dem Plus und dem pm7500. Das einzelne + wird so interpretiert, dass jeder(!) Rechner freien Zugriff hat. Dass der alleinstehende pm7500 dieses Recht auch hat, versteht sich dann von selbst.

In der vierten Zeile wird der Netzgruppe awfriends ein solcher Zugriff eingeräumt. Sie muss in der Datei /etc/netgroup definiert sein.

In allen Fällen müssen die Rechnernamen natürlich in der /etc/hosts stehen oder durch einen Namensdienst aufgelöst werden.

Das Sicherheitsproblem

Das Risiko liegt nicht in erster Linie darin, dass neben dem Administrator auch Benutzer Rechte weitergeben können. Denn letztlich ist das Eintragen eines Rechnernamens in der .rhosts immer noch wesentlich besser als die Weitergabe des Passwortes. rlogin hat sogar gegenüber telnet den Vorteil, dass das Passwort bei der Kommunikation nicht über das Netz geht. Es kann also nicht abgehört werden. Das kleinere Problem besteht darin, dass wenn ein Zugang des Benutzers geknackt ist, die anderen Zugänge auch offen sind. Das hört sich schlimmer an als es ist. Normalerweise verwendet der Benutzer auf verschiedenen Rechnern des LAN vermutlich sowieso die gleichen Passwörter und wenn der Eindringling einen Zugang kennt, kennt er alle. Problematischer ist der Angriff mit einer gefälschten IP-Nummer. Ist in der .rhosts ein Notebook oder ein Rechner eingetragen, der nicht ständig im Netz steht, kann ein Angreifer seinerseits mit einem Notebook mit eben dieser IP-Nummer ins Netz gehen und sich direkt einloggen ohne das Passwort zu kennen.

Remote Copy (rcp)

Das Programm rcp soll das Kopieren über Rechnergrenzen hinweg mit der Einfachheit eines normalen Kopierbefehls realisieren. Der Syntax ist sehr eng an den cp angelegt.

rcp Optionen  Quelle   Ziel

Lediglich die Argumentbeschreibung ist etwas verändert. Ist Quelle oder Ziel auf einem anderen Rechner, wird vor den Pfadnamen der Rechnername gefolgt von einem Doppelpunkt gesetzt. Dies kann sowohl bei der Quelle als auch beim Ziel erfolgen. Werden bei Quelle und Ziel fremde Rechner angegeben, ist rcp so clever zu erkennen, dass es effizienter ist, die Kopie direkt zwischen den beiden Rechnern auszutauschen, ohne den Umweg über den Auftraggeber zu gehen.

rcp idefix:/etc/hosts* ./test

Mit diesem Befehl werden vom Rechner idefix alle Dateien, die auf die Maske /etc/hosts* passen, an das im aktuellen Verzeichnis liegende test kopiert. test muss natürlich ein Verzeichnis sein, da zu erwarten steht, dass der Befehl mehrere Dateien kopieren wird. Werden die Dateien auf dem fremden Rechner nicht mit vollständigem Verzeichnis angegeben, wird vom Heimatverzeichnis auf der anderen Seite ausgegangen.

Server ist rshd

rcp verwendet als Serverdienst den rshd, also eine Remote Shell. Über diese wird auf der Gegenstation der rcp-Client aufgerufen, mit dem die eigentliche Übertragung stattfindet. Es gibt also keinen rcpd.

rlogin

Terminalsitzung

Per rlogin eröffnet man eine Terminalsitzung auf dem fremden Rechner unter der eigenen Benutzerkennung. Voraussetzung ist hier, dass der einloggende Benutzer auf der fremden Maschine ebenfalls eine Benutzerkennung besitzt und die Datei .rhosts auf dem fremden Rechner den aktuellen Computer eingetragen hat. In diesem Fall wird kein Kennwort und kein Passwort ausgetauscht und damit kann es auch nicht abgehorcht werden. Versucht man einen rlogin auf einen nicht entsprechend vorbereiteten Rechner, wird rlogin davon ausgehen, dass die Kennung die gleiche ist wie auf dem aktuellen Rechner und das Passwort für die Zielmaschine anfordern.

Rechnernamen als rlogin

Man kann das Einloggen auf eine fremde Maschine noch weiter vereinfachen, indem man einen Link von rlogin erstellt und dem Link den Namen eines Rechners gibt. rlogin prüft beim Aufruf, ob es unter einem anderen Namen aufgerufen wurde und verwendet dann diesen Namen als Zielmaschine.

silver> ln -s `which rlogin` gaston
silver> gaston
Last login: Thu Mar 21 09:52:09 from gaston.willemer.edu
Have a lot of fun...
gaston>

In der ersten Zeile wird ein symbolischer Link von dem Dateinamen gebildet, den der Befehl which liefert, mit dem Ziel gaston. Dieser zeigt dann auf den vollständigen Pfad von rlogin. Nun kann man gaston aufrufen. Über den symbolischen Link wird rlogin gestartet. Das Programm rlogin stellt fest, dass der Name unter dem es gerufen wurde, gaston lautet und verbindet zu gaston.

Befehlsausführung (rsh, rcmd und rexec)

Das Programm rsh dient dazu, ein Kommando auf einem fremden Rechner ausführen zu können. Auf einigen Systemen hat rsh den Namen rexec. SCO nennt den Befehl rcmd (remote command). Der Name rsh ist hier für die restricted shell, einer lokalen Shell mit eingeschränkten Rechten vergeben.

rsh host Befehl

rsh versus rlogin

Gegenüber rlogin hat rsh seine Vorteile, wenn Skripten oder einzelne Programme auf anderen Maschinen Prozesse gestartet werden sollen. Das kann beispielsweise im Zusammenhang mit einer Fernsteuerung der Fall sein. Auch wenn ein Login aufgrund begrenzter Lizenzen ein weiteres Mal nicht möglich ist, kann man noch ein paar Abläufe starten.

Mit der Option -l kann der Benutzer angegeben werden, unter dessen Kennung der Befehl ausgeführt werden soll.

Wenn Sicherheit vorgeht: die ssh und scp

Die SSH hat als freie Software begonnen. Inzwischen hat der Autor eine kommerzielle Version herausgegeben und pflegt die freie Version nicht mehr. Dies hat dagegen die Gruppe OpenSSH übernommen, so dass es eine aktuelle, freie Version gibt. SSH basiert auf Verschlüsselungsalgorithmen, die an dieser Stelle nicht behandelt werden. Der Fokus des weiteren Abschnitts wendet sich auf die Konfiguration einer solchen Umgebung.

Verschlüsselte Terminalsitzung

Als Client gibt es ssh, das einem rlogin oder telnet entspricht, also die Möglichkeit bietet, eine Sitzung auf einer fernen Maschine abzuhalten. Als zweiten Client gibt es scp, der im Syntax vollständig dem rcp entspricht. Für den Client gibt es die Konfigurationsdatei ssh_config, die sich in /etc oder /etc/ssh befindet.

Der Server heißt sshd. Seine Konfigurationsdatei heißt sshd_config und befindet sich analog ebenfalls in /etc oder /etc/ssh.

Terminalsitzung mit Login

Es gibt verschiedene Arten, ssh zu betreiben. Man kann ssh als telnet-Ersatz verwenden. Dazu muss an der Standardkonfiguration nichts geändert werden. Der Vorteil liegt einfach darin, dass man den Datenverkehr nicht abhören kann. Wer nicht möchte, dass man sich von einer beliebigen Maschine einloggen kann, kann dies in der Konfigurationsdatei sperren und somit nur den Zugriff von explizit erlaubten Systemen oder Netzen ermöglichen.

Authentifizierung per .rhosts

Die zweite Variante arbeitet über die gleiche Methode wie die r-Tools, also die Dateien .rhosts oder hosts.equiv. Der Sicherheitsgewinn ist minimal, da das Hauptproblem bei den r-Tools nicht die Passwörter im Klartext sind, sondern die Möglichkeit, mit einer gefälschten IP-Nummer in den Genuss fremder Rechte zu kommen. Da dieser Angriff unter ssh mit Rhostsauthentifizierung genauso funktionieren würde, wird ssh in dieser Weise auch kaum eingesetzt. Will man, wie bei den r-Tools den Aufruf ohne die Bestätigung durch die Eingabe von Passwörtern realisieren, verwendet man eine Art von Fingerabdruck, den man zwischen den Maschinen austauscht. Zu guter Letzt gibt es noch eine Konfiguration, die eine Mischform aus rhosts und Fingerabdruck darstellt, in der Praxis aber keine Vorteile bietet.

ssh als telnet-Ersatz

Die einfachste Verwendung des ssh ist seine Verwendung als telnet-Ersatz. In der Datei sshd_config, die sich je nach System in /etc oder in /etc/ssh befindet, muss lediglich gewährleistet sein, dass PasswordAuthentication nicht auf no steht. Wird diese nicht erwähnt, ist das auch korrekt, da der Default auf yes steht. Tritt von außen ein ssh-Client an die Maschine herantreten, wird es wie beim telnet eine Aufforderung des Einloggens geben. Allerdings wird von Anfang an verschlüsselt gearbeitet. Der Eintrag in der /etc/sshd_config:

PasswordAuthentication yes

Terminalemulation

Insofern gibt es eigentlich nur einen Grund, den telnet-Zugang zur Maschine weiterhin offen zu halten, nämlich, wenn es keine vernünftige Terminalemulation für den ssh-Client gibt. Da unter UNIX-Systemen ssh die gleichen Mechanismen zur Terminalemulation verwendet wie telnet, ist dies mehr ein Problem bei anderen Systemen.

Das Abschalten der Option PasswordAuthentication ist möglich und macht auch Sinn, wenn beispielsweise ein Webserver, der im Zugriff des Internets steht, nicht von außen per ssh ansprechbar sein soll, sondern nur von internen Rechnern der Firma, die man entsprechend ausweist.

Für MS-Windows gibt es das freie Programm PUTTy, das einen ssh-Client mit und einen scp beinhaltet. Quelle:

http://www.chiark.greenend.org.uk/~sgtatham/putty

RSA-Authentifizierung

RSA ist ein asymmetrisches Kryptoverfahren, das der Schlüsselverwaltung von SSH zugrunde liegt.

Vorbereitungen

Soll eine Maschine als SSH-Client operieren, muss sie vom Server eindeutig identifizierbar sein. Da eine IP-Nummer leicht zu ändern ist, reicht diese Art der Identifikation nicht aus. Man generiert mit dem Programm ssh-keygen zwei Schlüssel für eine Maschine. Der eine Schlüssel ist privat und der zweite ist öffentlich. Der öffentliche Schlüssel wird dem Server für eine Liste der berechtigten Clients gegeben.

Im Beispiel soll der Rechner gaston per ssh oder scp auf den Rechner silver zugreifen können. Bisher sind beide Rechner per rsh und rcp erreichbar. Das soll aber nach der Installation von ssh aufgelöst werden. Mit dem Kommando ssh-keygen wird auf gaston ein Schlüssel erzeugt.

gaston> ssh-keygen
Generating public/private rsa1 key pair.
Enter file in which to save the key (/home/arnold/.ssh/identity)
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/arnold/.ssh/identity
Your public key has been saved in /home/arnold/.ssh/identity.pub
The key fingerprint is:
3b:a2:62:ed:02:ef:30:79:a1:4b:0b:b6:35:21:d8:f1 arnold@gaston
gaston>

Öffentlichen Schlüssel kopieren

Wie aus den Meldungen zu entnehmen ist, befinden sich die Dateien mit den Informationen im Unterverzeichnis .ssh des Heimatverzeichnisses. Die Datei identity.pub enthält den öffentlichen Schlüssel in einer Textzeile kodiert. In dieser Datei befindet sich nur die eine Zeile, die auf arnold@gaston endet. Diese Zeile wird auf dem Zielrechner an die Datei .ssh/authorized_keys angehängt.

silver> cd
silver> rcp gaston:.ssh/identity.pub .
silver> cat .ssh/identity.pub >> .ssh/authorized_keys
silver> rm .ssh/identity.pub

In hochsicherheitskritischen Umgebungen sollte man die Übertragung nicht unbedingt per rcp durchführen. Wenn die Konfigurationsdateien auf dem Standard stehen, kann sich nun der Benutzer arnold von gaston aus auf dem Rechner silver anmelden, ohne ein Passwort einzugeben.

gaston> ssh silver
Last login: Mon Feb 25 00:04:06 2002 from mail.willemer.edu
Have a lot of fun...
silver>

scp: Sicheres Kopieren übers Netz

Das Kopieren erfolgt ähnlich wie beim rcp, allerdings ist scp von Haus aus wesentlich geschwätziger. Es zeigt einen Verlaufsbalken beim Kopieren an. Dieses unterhaltsame Feature kann man allerdings auch mit -q abschalten. Mit -B kann man verhindern, dass scp plötzlich in einem im Hintergrund laufenden Prozess nach dem Kennwort fragt.

gaston> scp silver:/etc/passwd .
passwd     100% |*****************************|  2071     00:00
gaston>

Konfigurationsdatei des Client

Bei einer Standardinstallation von ssh finden Sie eine fast vollständig auskommentierte Datei ssh_config. Dabei sind die Defaultwerte hinter den Variablen angegeben.

Host *
#   ForwardAgent no
#   ForwardX11 no
#   RhostsAuthentication no
#   RhostsRSAAuthentication yes
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   FallBackToRsh no
#   UseRsh no
#   BatchMode no
#   CheckHostIP yes
#   StrictHostKeyChecking yes
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_rsa
#   Port 22
  Protocol 1,2
#   Cipher blowfish
#   EscapeChar ~

In der hier aufgestellten Umgebung würde man RhostsRSAAuthentication auf no stellen. Die Werte hinter Host bezeichnen die vom Client ansprechbaren SSH-Server. In diesem Fall sind das alle. Die Werte hinter Protocol bezeichnen, welche SSH Protokollversionen in welcher Reihenfolge unterstützt werden sollen.

Konfiguration sshd

Die Konfiguration für den Server sshd ist deutlich umfangreicher, so dass hier nur ein Ausschnitt aus der sshd_configbetrachtet werden soll.

IgnoreRhosts yes
RhostsAuthentication no 
RhostsRSAAuthentication no 
RSAAuthentication yes 
PasswordAuthentication yes

Mit diesen Werten ist das Einloggen ohne Passwort nur erlaubt, wenn eine Schlüsselübergabe stattgefunden hat. Alle rhosts-Mischformen sind ausgeschlossen. Ein direktes Einloggen mit der Eingabe eines Passwortes ist aber erlaubt.

Tunnelbau: andere Protokolle sichern

Mit ssh kann man Netzverbindungen anderer TCP/IP-Dienste sichern. Die Basis ist eine gewöhnliche Sitzung mit ssh, der man allerdings die Ports zuordnet. Dazu gibt es die Option -L. Als weitere Parameter wird ein Tripel aus eigener Portnummer, dem Benutzer auf dem Zielrechner und dem Zielport angefügt. Als Beispiel wird eine Sitzung aufgesetzt, die vom Rechner silver zu gaston führt. Der Zielport ist 110, der für POP3 verwendet wird.

silver>  ssh gaston  -L 2002:gaston:110
Last login: Sun Jul  7 11:32:27 2002 from silver.willemer.edu
Have a lot of fun...
gaston>

Sobald diese Sitzung steht, kann auf dem Rechner silver ein Mailclient aufgerufen werden. In der Konfiguration des Mailprogramms wird als Server localhost, also silver angegeben. Der Port wird von 110 auf 2002 umgestellt. Versucht man nun nach Mail zu fragen, wird der Mailclient lokal auf silver den Port 2002 anfragen. Der ist aber über die ssh-Sitzung über eine gesicherte Verbindung mit dem Port 110 von gaston verbunden. Dieser Tunnel bleibt so lange bestehen, wie die ssh-Sitzung besteht. Mit dem Ausloggen ist auch der Tunnel nicht mehr zugreifbar.

Durch Firewall und Proxy

Da die Verbindung durch SSH getunnelt wird, kann sie überall da aufgebaut werden, wo eine solche Verbindung erlaubt ist. Damit hat die Freigabe des SSH zur Konsequenz, dass die Berechtigten auch beinahe jede andere Verbindung zwischen den Rechnern aufbauen können, für die SSH gestattet ist. Eine Firewall wie auch ein Proxy können die Verbindung zwar als SSH identifizieren. Es bleibt ihnen aber unsichtbar, welcher Protokolltyp darin getunnelt wird.

rhosts oder doch nicht?

Es gibt einen Modus, in dem ssh und scp wie rlogin und rcp über .rhosts konfiguriert werden können. So jedenfalls steht es in der Dokumentation. In der Literatur wird sogar von plug-in kompatibel gesprochen. Interessanterweise schweigt sich die entsprechende Literatur aber auch über die korrekte Konfiguration aus. Ich habe dies einmal schnell aufbauen wollen und nach einiger Zeit aufgegeben. In der Zwischenzeit hatte ich bequem die RSA-Variante konfigurieren können und es dann noch einmal erfolglos mit .rhosts probiert.

scp ist nicht rcp plug-in kompatibel

Ganz so einfach ist das Ersetzen der r-Tools durch die s-Tools nicht, dass man von Umstöpseln sprechen könnte. Immerhin muss zumindest die Datei sshd_config noch korrekt konfiguriert werden. Da bei richtig konfigurierten r-Tools gar keine Passwörter über die Leitung gehen und das potentielle Angriffsziel der Fälschung der IP-Nummern bei beiden Tools möglich ist, stellt sich auch die Frage nach dem Wert einer solchen Konfiguration.

Wer also die r-Tools aufgrund von Sicherheitsbedenken durch die s-Tools ersetzen will, sollte sich selbst den Gefallen tun, gleich auf die Konfiguration mit RSA umzuschwenken.

Diese Seite basiert auf Inhalten aus dem Buch
Arnold Willemer: Wie werde ich UNIX-Guru
und dem Nachfolgebuch
Arnold Willemer: UNIX - Das umfassende Handbuch
Verlagsrechte bei galileo computing


Homepage (C) Copyright 2002-2009 Arnold Willemer