Copyright © 1996 by O'Reilly/International Thomson Verlag
Bitte denken Sie daran: Sie dürfen zwar die Online-Version
ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen.
Wünschen Sie mehr Informationen zu der gedruckten
Version des Buches "Linux: Wegweiser durch das Netzwerk"
dann klicken Sie
hier.
Nachdem Sie IP und den Resolver erfolgreich eingerichtet haben, müssen Sie sich den Diensten zuwenden, die Sie in Ihrem Netzwerk anbieten wollen. Dieses Kapitel behandelt die Konfiguration einiger einfacher Netzwerk-Anwendungen, einschließlich des inetd-Servers und der Programme der rlogin-Familie. Das »Remote Procedure Call«-Interface, auf dem Dienste wie das Network File System (NFS) und das Network Information System (NIS) basieren, wird auch kurz behandelt. Die Konfiguration von NFS und NIS nimmt aber wesentlich mehr Raum in Anspruch und wird daher in separaten Kapiteln besprochen. Das gleiche gilt auch für Elektronische Post und Netnews.
Leider können wir in diesem Buch nicht alle Netzwerk-Anwendungen besprechen. Wenn Sie eine der hier nicht behandelten Anwendungen wie talk, gopher oder Mosaic installieren wollen, müssen wir Sie auf die entsprechenden Manpages verweisen.
Häufig werden Dienste durch sogenannte Dämonen bereitgestellt. Ein Dämon ist ein Programm, das einen bestimmten Port öffnet und auf eingehende Verbindungen wartet. Wird eine solche Verbindung aufgebaut, erzeugt der Dämon einen Kind-Prozeß, der die Verbindung übernimmt, während der Parent selbst weiter nach eingehenden Anforderungen Ausschau hält. Dieses Konzept hat den Nachteil, daß für jeden angebotenen Service ein entsprechender Dämon laufen muß, der am Port nach Anforderungen horcht, was grundsätzlich eine Verschwendung von Systemressourcen nach sich zieht, wie beispielsweise den Verbrauch von Swap-Speicher.
Daher verwenden nahezu alle UNIX-Installationen einen »Super-Server«, der Sockets für eine Reihe von Diensten erzeugt und mit Hilfe des select(2)-Systemaufrufs simultan abhört. Fordert ein entfernter Host einen Dienst an, wird dies vom Super-Server registriert, und er startet den für diesen Port zuständigen Server.
Der im allgemeinen verwendete Super-Server ist inetd, der »Internet Dämon«. Er wird während der Bootphase des Systems gestartet und liest eine Liste der Dienste, die er verwalten soll, aus der Datei /etc/inetd.conf. Zusätzlich zu den von inetd gesteuerten Servern gibt es eine Reihe trivialer Dienste, sogenannte interne Dienste, die inetd selbständig ausführt. Dazu gehören beispielsweise chargen, das einfach eine Zeichenkette erzeugt, und daytime, das die nach Meinung des Systems aktuelle Tageszeit zurückliefert.
Ein Eintrag in dieser Datei besteht aus einer einzelnen Zeile, die sich aus den folgenden Feldern zusammensetzt:
service type protocol wait user server cmdline
Die Bedeutung der einzelnen Felder wird nachfolgend erklärt:
- service
Enthält den Namen des Dienstes. Dieser Name muß in eine Portnummer übersetzt werden, was durch einen Lookup in der Datei /etc/services geschieht. Diese Datei wird im Abschnitt »Die Dateien services und protocols« beschrieben.
- type
Bestimmt den Socket-Typ entweder als
stream (bei verbindungsorientierten Protokollen) oder als dgram (für Datagramm-Protokolle). TCP-basierte Dienste sollten daher immer stream verwenden, während UDP-basierte Dienste immer dgram verwenden sollten.
- protocol
Benennt das vom Dienst verwendete Transportprotokoll. Hier muß ein gültiger, in der (weiter unten erläuterten) Datei protocols enthaltener Name stehen.
- wait
Diese Option gilt nur für
dgram-Sockets gültig. Sie kann entweder wait oder nowait lauten. Wird wait angegeben, führt inetd nur jeweils einen Server für den angegebenen Port aus. Anderenfalls beginnt es wieder umgehend an diesem Port zu horchen, sobald der Server gestartet wurde.
Das ist sinnvoll bei sog. »Single-Threaded-Servern«, die alle eingehenden Datagramme lesen, bis keine weiteren mehr ankommen, und sich dann automatisch beenden. Die meisten RPC-Server sind von dieser Art und sollten daher immer wait verwenden. Der entgegengesetzte Typ, der »Multi-Threaded-Server«, erlaubt eine unbeschränkte Anzahl von gleichzeitig laufenden Instanzen und wird nur selten benutzt. Dieser Server-Typ sollte nowait angeben.
stream-Sockets sollten immer nowait verwenden.
- user
Hier steht die Login-ID des Benutzers, unter der der Prozeß ausgeführt wird. Das wird häufig root sein, einige Dienste verwenden aber auch andere Accounts. Sie sollten übrigens immer das Prinzip der geringsten Privilegien anwenden, d.h, ein Befehl sollte nur mit Privilegien ausgestattet sein, die er zur fehlerfreien Ausführung unbedingt benötigt. Zum Beispiel läuft der NNTP-News-Server als news, während Dienste, die ein Sicherheitsrisiko darstellen (z. B. tftp oder finger), häufig als nobody laufen.
- server
Enthält den vollen Pfadnamen auf das auszuführende Server-Programm. Interne Dienste werden mit dem Schlüsselwort
internal gekennzeichnet.
- cmdline
Die an den Server zu übergebende Befehlszeile. Diese enthält auch das Argument 0, den Befehlsnamen. Üblicherweise ist dies der Programmname des Servers, es sei denn, der Server verhält sich anders, wenn er unter einem anderen Namen gestartet wird.
Dieses Feld ist bei internen Diensten leer.
Ein Beispiel für inetd.conf ist in Beispiel 9--1 zu sehen. Der finger-Service ist auskommentiert, so daß er nicht zur Verfügung steht. Dies wird häufig aus Sicherheitsgründen getan, weil er von Eindringlingen dazu verwendet werden kann, Namen der Benutzer Ihres Systems zu ermitteln.
Beispiel 9-1. /etc/inetd.conf Beispieldatei
#
# inetd-Dienste
ftp stream tcp nowait root /usr/sbin/ftpd in.ftpd -l
telnet stream tcp nowait root /usr/sbin/telnetd in.telnetd -b/etc/issue
#finger stream tcp nowait bin /usr/sbin/fingerd in.fingerd
#tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd
#tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd /boot/diskless
login stream tcp nowait root /usr/sbin/rlogind in.rlogind
shell stream tcp nowait root /usr/sbin/rshd in.rshd
exec stream tcp nowait root /usr/sbin/rexecd in.rexecd
#
# inetd-interne Dienste
#
daytime stream tcp nowait root internal
daytime dgram udp nowait root internal
time stream tcp nowait root internal
time dgram udp nowait root internal
echo stream tcp nowait root internal
echo dgram udp nowait root internal
discard stream tcp nowait root internal
discard dgram udp nowait root internal
chargen stream tcp nowait root internal
chargen dgram udp nowait root internal
tftp ist ebenfalls auskommentiert. tftp implementiert das Trivial File Transfer Protocol (TFTP), das es einem erlaubt, allgemein lesbare Dateien ohne Paßwortprüfung etc. von Ihrem System zu übertragen. Das ist besonders bei der Datei /etc/passwd gefährlich, um so mehr, wenn Sie nicht mit Shadow-Paßwörtern arbeiten.
TFTP wird üblicherweise von Clients ohne eigenes Diskettenlaufwerk und von X-Terminals genutzt, um deren Kode vom einem Bootserver herunterzuladen. Muß tftpd aus diesem Grund ausgeführt werden, sollten Sie sicherstellen, daß Sie den Zugriff nur auf solche Verzeichnisse erlauben, aus denen die Clients die entsprechenden Dateien lesen. Diese Verzeichnisse können Sie in der tftpd-Kommandozeile angeben, was in der zweiten tftp-Zeile des Beispiels zu erkennen ist.
Weil das Erweitern eines Computers um den Netzwerkzugriff viele Sicherheitsrisiken in sich birgt, sind die Anwendungen so entwickelt worden, daß sie sich vor verschiedenen Arten von Angriffen schützen können. Allerdings sind einige Sicherheitsmerkmale mangelhaft (was der RTM Internet-Wurm auf drastische Weise demonstriert hat), oder es wird nicht unterschieden zwischen einem sicheren Host, von dem Anforderungen nach einem bestimmten Service akzeptiert werden können, und einem unsicheren Host, dessen Anforderungen abgelehnt werden müssen. Die Dienste finger und tftp haben wir oben ja bereits angesprochen. Sicher würden Sie den Zugriff auf diese Dienste gerne auf »vertrauenswürdige Hosts« beschränken, was aber mit dem normalen Setup nicht möglich ist, bei dem inetd den Dienst entweder allen Clients anbietet, oder keinem.
Ein für solche Fälle nützliches Werkzeug ist tcpd, ein sogenannter Dämon-Wrapper. Bei TCP-Diensten, die Sie überwachen oder sichern wollen, wird es anstelle des normalen Server-Programms gestartet. tcpd schickt eine Meldung über die Anforderungen an den syslog-Dämon, prüft, ob der entfernte Host diesen Dienst überhaupt benutzen darf und führt nur dann das eigentliche Server-Programm aus. Beachten Sie, daß dies bei UDP-basierten Diensten leider nicht funktioniert.(1)
Um beispielsweise den finger-Dämon mit einem Wrapper zu schützen, müssen Sie die entsprechende Zeile in der inetd.conf wie folgt ändern:
# finger-Dämon mit Wrapper schützen
finger stream tcp nowait root /usr/sbin/tcpd in.fingerd
Ohne eine zusätzliche Zugriffskontrolle erscheint dies für den Client wie ein ganz gewöhnliches finger-Setup, mit der Ausnahme, daß alle Anforderungen in der auth-Einrichtung von syslog aufgezeichnet werden.
Die Zugriffskontrolle wird mit Hilfe der beiden Dateien /etc/hosts.allow und /etc /hosts.deny implementiert. Sie enthalten Einträge, die den Zugriff auf bestimmte Dienste und Hosts erlauben bzw. sperren. Erhält tcpd eine Anforderung für einen Dienst wie finger von einem Client-Host namens biff.foobar.com, durchsucht es hosts.allow und hosts.deny (in dieser Reihenfolge) nach einem Eintrag, bei dem sowohl der Dienst als auch der Client übereinstimmen. Wird ein passender Eintrag in hosts.allow gefunden, wird der Zugriff freigegeben, gleichgültig, ob es noch einen Eintrag in hosts.deny gibt. Wird eine Übereinstimmung in hosts.deny gefunden, wird die Anforderung abgewiesen, und die Verbindung wird unterbrochen. Wird überhaupt kein passender Eintrag gefunden, wird die Anforderung ebenfalls akzeptiert.
Die Einträge in den Zugriffsdateien sehen wie folgt aus:
servicelist: hostlist [:shellcmd]
servicelist ist eine Liste mit Servicenamen aus /etc/services oder das Schlüsselwort ALL. Um alle Dienste außer finger und tftp zu akzeptieren, müssen Sie »ALL EXCEPT finger, tftp« eingeben.
hostlist ist eine Liste mit Hostnamen oder IP-Adressen oder den Schlüsselwörtern ALL, LOCAL oder UNKNOWN. ALL steht für alle Hosts, während LOCAL nur Hostnamen vergleicht, die keinen Punkt enthalten.(2) UNKNOWN gilt für jeden Host, dessen Name oder Adresse durch einen Lookup nicht ermittelt werden konnte. Ein mit einem Punkt beginnender Name steht für eine Domain und wählt alle Hosts aus, die zu dieser Domain gehören. Zum Beispiel würde der Eintrag .foobar.com das System biff.foobar.com akzeptieren. IP-Netzwerk-Adressen und Subnetz-Nummern werden ebenfalls unterstützt.
Um den Zugriff auf finger und tftp für alle Hosts, mit Ausnahme der lokalen Hosts, zu unterbinden, müssen Sie den folgenden Eintrag in die /etc/hosts.deny eintragen, wobei /etc/hosts.allow nicht verändert wird:
in.tftpd, in.fingerd: ALL EXCEPT LOCAL, .Ihre.Domain
Das optionale Feld shellcmd kann einen Shell-Befehl enthalten, der ausgeführt wird, wenn der Vergleich erfolgreich war. Dies ist sinnvoll, wenn Sie zusätzliche Fallen einbauen wollen, um mögliche Angreifer zu enttarnen:
in.ftpd: ALL EXCEPT LOCAL, .vbrew.com : \
echo "request from %d@%h: >> /var/log/finger.log; \
if [ %h != "vlager.vbrew.com:" ]; then \
finger -l @%h >> /var/log/finger.log \
fi
Die Argumente %h und %d werden von tcpd durch den Client-Hostnamen und den Servicenamen ersetzt. Details entnehmen Sie bitte der Manpage hosts_access(5).
Die Portnummer, über die einige der »Standarddienste« angeboten werden, sind im »Assigned Numbers RFC« definiert. Um es Server- und Client-Programmen zu ermöglichen, die Servicenamen in diese Nummern umzuwandeln, ist zumindest einTeil dieser Liste auf jedem Host vorhanden und wird in einer Datei namens /etc/services gespeichert. Ein Eintrag setzt sich aus den folgenden Feldern zusammen:
Service Port/Protokoll [Aliase]
Service gibt den Namen des Dienstes an, Port beschreibt, auf welchem Port dieser Dienst angeboten wird, und Protokoll definiert das zu verwendende Transportprotokoll. Üblicherweise ist dies entweder udp oder tcp. Ein Dienst kann auch für mehr als ein Protokoll angeboten werden. Verschiedene Dienste können denselben Port benutzen, solange die Protokolle verschieden sind. Im Feld Aliase können Sie alternative Namen für denselben Service definieren.
Normalerweise müssen Sie die Services-Datei nicht ändern, die mit der Netzwerk-Software für Ihr Linux-System geliefert wird. Dennoch wollen wir Ihnen in Beispiel 9--2 einen kleinen Ausschnitt dieser Datei zeigen.
Beispiel 9-2. Ausschnitt aus /etc/services (Beispiel)
# Services-Datei:
#
# bekannte Dienste:
echo 7/tcp # Echo
echo 7/udp #
discard 9/tcp sink null # Discard
discard 9/udp sink null #
daytime 13/tcp # Daytime
daytime 13/udp #
chargen 19/tcp ttytst source # Character Generator
chargen 19/udp ttytst source #
ftp-data 20/tcp # File Transfer Protocol (Data)
ftp 21/tcp # File Transfer Protocol (Control)
telnet 23/tcp # Virtual Terminal Protocol
smtp 25/tcp # Simple Mail Transfer Protocol
nntp 119/tcp readnews # Network News Transfer Protocol
#
# UNIX services
exec 512/tcp # rexecd (BSD)
biff 512/udp comsat # Mail-Benachrichtigung
login 513/tcp # remote Login
who 513/udp whod # who und uptime (remote)
shell 514/tcp cmd # Befehl (remote) ohne Paßworteingabe
syslog 514/udp # System-Logging (remote)
printer 515/tcp spooler # Druckspooler (remote)
route 520/udp router routed # Router-Informationsprotokoll
Zum Beispiel wird der Dienst echo sowohl für TCP als auch für UDP über Port 7 angeboten. Port 512 wird für zwei verschiedene Dienste verwendet: für die Programmausführung auf entfernten Systemen mittels rexec (TCP) und für den COMSAT-Dämon (UDP), der Benutzer über neu eingegangene Post informiert.
Analog zur services-Datei benötigt die Netzwerk-Bibliothek noch eine Möglichkeit, Protokollnamen (beispielsweise die in der Services-Datei verwendeten) in Protokollnummern zu übersetzen, die der IP-Layer auf dem anderen Host versteht. Dies wird mit Hilfe der Datei /etc/protocols erreicht. Sie besteht aus einem Eintrag pro Zeile, der den Protokollnamen und die zugewiesene Nummer enthält. Daß Sie sich mit dieser Datei auseinandersetzen müssen, ist sogar noch unwahrscheinlicher als bei /etc/services. Ein Beispiel ist in Beispiel 9--3 zu sehen.
Beispiel 9-3. Ausschnitt aus /etc/protocols (Beispiel)
#
# Internet-Protokolle (IP)
#
ip 0 IP # Internet-Protokoll, Pseudo-Protokollnummer
icmp 1 ICMP # Internet Control Message Protocol
igmp 2 IGMP # Internet Group Multicast Protocol
tcp 6 TCP # Transmission Control Protocol
udp 17 UDP # User Datagram Protocol
raw 255 RAW # RAW IP-Interface
Ein sehr allgemeiner Mechanismus für Client/Server-Anwendungen wird von RPC, dem Remote Procedure Call-Paket, angeboten. RPC ist von Sun Microsystems entwickelt worden und ist eine Sammlung von Tools und Bibliotheksfunktionen. Wichtige Anwendungen, die auf RPC basieren, sind NFS, das »Network File System« und NIS, das »Network Information System«.
Ein RPC-Server kennt eine Reihe von Prozeduren, die ein Client aufrufen kann, indem er eine RPC-Anforderung zusammen mit den benötigten Parametern an den Server schickt. Der Server führt die Prozedur im Auftrag des Client aus und liefert das Ergebnis zurück, wenn es eines gibt. Um maschinenunabhängig zu sein, werden alle zwischen dem Client und dem Server ausgetauschten Daten vom Sender in das sogenannte XDR-Format (External Data Representation) um- und vom Empfänger wieder in die lokale Repräsentation zurückgewandelt. Sun hat RPC großzügigerweise in die Public Domain freigegeben. Es wird in einer Reihe von RFCs beschrieben.
Manchmal führen Verbesserungen an einer RPC-Anwendung zu Inkompatibilitäten im Interface der Prozeduraufrufe. Natürlich würde ein einfaches Wechseln des Servers alle Anwendungen zum Absturz bringen, die noch das ursprüngliche Verhalten erwarten. Darum verfügt jedes RPC-Programm über eine Versionsnummer, die normalerweise bei 1 beginnt und bei jeder neuen RPC-Version erhöht wird. Häufig bietet ein Server mehrere Versionen gleichzeitig an, und die Clients geben durch die Versionsnummer in ihren Anforderungen an, welche Implementierung des Dienstes verwendet werden soll.
Die Netzwerk-Kommunikation zwischen RPC-Servern und -Clients ist etwas ungewöhnlich. Ein RPC-Server bietet eine Sammlung von Prozeduren an, die als Programm bezeichnet wird und durch eine Programm-Nummer eindeutig definiert ist. Eine Liste, die Servicenamen auf Programm-Nummern abbildet, wird normalerweise in der Datei /etc/rpc gespeichert. Einen Ausschnitt dieser Datei sehen Sie in Beispiel 9--4.
Beispiel 9-4. Ausschnitt aus /etc/rpc
#
# /etc/rpc -- verschiedene RPC-basierte Dienste
#
portmapper 100000 portmap sunrpc
rstatd 100001 rstat rstat_svc rup perfmeter
rusersd 100002 rusers
nfs 100003 nfsprog
ypserv 100004 ypprog
mountd 100005 mount showmount
ypbind 100007
walld 100008 rwall shutdown
yppasswdd 100009 yppasswd
bootparam 100026
ypupdated 100028 ypupdate
Bei TCP/IP-Netzwerken wurden die Autoren von RPC mit dem Problem konfrontiert, Programm-Nummern auf Netzwerkdienste abzubilden. Sie entschieden, daß jeder Server sowohl einen TCP- als auch einen UDP-Port für jedes Programm und jede Version bereitstellen soll. Normalerweise verwenden RPC-Anwendungen UDP, um Daten zu übertragen, und greifen nur dann auf TCP zurück, wenn die zu transportierenden Daten nicht in ein einziges UDP-Datagramm passen. Es gibt allerdings einige wenige Dienste, die nur eines der beiden Transportprotokolle anbieten.
Natürlich müssen Client-Programme eine Möglichkeit haben herauszufinden, auf welche Programm-Nummer ein Port abgebildet ist. Die Verwendung einer Konfigurationsdatei zu diesem Zweck wäre zu unflexibel. Weil RPC-Anwendungen keine reservierten Ports verwenden, gibt es keine Garantie, daß ein ursprünglich von unserer Datenbank-Anwendung zu verwendender Port nicht von einem anderen Prozeß besetzt wurde. Darum nimmt eine RPC-Anwendung den ersten Port, den sie kriegen kann, und teilt ihn dem sogenannten Portmapper-Dämon mit. Der Portmapper fungiert als Service-Vermittler für alle RPC-Servern, die auf dieser Maschine laufen. Ein Client, der einen Dienst mit einer gegebenen Programm-Nummer nutzen möchte, wird zuerst den Portmapper auf dem Host des Servers abfragen, der dann die TCP- und UDP-Portnummern zurückliefert, über die der Dienst erreicht werden kann.
Diese Methode hat den Nachteil, daß sie -- genau wie inetd für die normalen Berkeley-Dienste -- einen »single point of failure« darstellt. Nun ist dieser Fall noch ein wenig schlimmer, weil alle RPC-Port-Informationen verlorengehen, wenn der Portmapper stirbt. Das bedeutet üblicherweise, daß Sie alle RPC-Server manuell neu starten, oder sogar die gesamte Maschine neu hochfahren müssen.
Bei Linux wird der Portmapper rpc.portmap genannt und ist in /usr/sbin zu finden. Sie müssen nur sicherstellen, daß er von rc.inet2 aus gestartet wird; weitere Konfigurationsarbeiten sind nicht notwendig.
Es gibt eine Reihe von Befehlen zur Ausführung von Befehlen auf entfernten (remote) Hosts. Diese sind rlogin, rsh und rcp. Alle führen eine Shell auf dem entfernten Host aus und erlauben dem Benutzer die Ausführung von Befehlen. Natürlich benötigt der Client einen Account auf dem Host, auf dem die Befehle ausgeführt werden sollen. Aus diesem Grund führen all diese Befehle eine Autorisierungsprozedur durch. Üblicherweise teilt der Client dem Server den Loginnamen des Benutzers mit, der wiederum ein Paßwort anfordert, das auf die übliche Weise kontrolliert wird.
Manchmal ist es wünschenswert, für bestimmte Benutzer die Autorisierungs-Prüfungen zu vereinfachen. Wenn Sie beispielsweise sehr häufig auf eine andere Maschine in Ihrem LAN zugreifen müssen, wäre es für Sie sehr angenehm, wenn Sie nicht jedesmal Ihr Paßwort eingeben müßten.
Das Deaktivieren der Autorisierung ist nur bei einer kleinen Anzahl von Hosts ratsam, deren Paßwort-Datenbanken abgeglichen sind, oder bei einer kleinen Anzahl privilegierter Benutzer, die aus administrativen Gründen auf viele Maschinen zugreifen müssen. Wenn Sie Leuten das Login auf Ihr System ohne die Angabe eines Login-ID oder eines Paßworts gewähren wollen, müssen Sie darauf achten, nicht versehentlich jemand anderem den Zugriff zu ermöglichen.
Es gibt zwei Wege, die Autorisierungs-Prüfungen für die r-Befehle zu deaktivieren. Zum einen kann der Superuser einigen oder allen Benutzern auf einigen oder allen Hosts (letzteres wäre eine sehr schlechte Idee) erlauben, sich einzuloggen, ohne daß nach einem Paßwort gefragt wird. Dieser Zugriff wird in einer Datei namens /etc/hosts.equiv kontrolliert. Sie enthält eine Liste mit Host- und Benutzernamen, die mit den Benutzern auf dem lokalen Host gleichgesetzt werden. Eine alternative Möglichkeit wäre, daß ein Benutzer anderen Anwendern auf verschiedenen Hosts den Zugriff auf seinen Account erlaubt. Dies kann in der Datei .rhosts im Home-Verzeichnis des Benutzers eingetragen werden. Aus Sicherheitsgründen muß diese Datei dem Benutzer oder dem Superuser gehören und darf nicht einfach ein symbolischer Link sein. Anderenfalls wird sie ignoriert.(3)
Wenn ein Client einen der r-Dienste anfordert, wird der entsprechende Host- und Benutzername in der Datei /etc/hosts.equiv gesucht. Diese Prozedur wird danach in der .rhosts des Benutzers, bei dem der Login erfolgen soll, wiederholt. Nehmen wir beispielsweise an, daß
janet an gauss arbeitet und versucht, sich in
joes Account auf
euler einzuloggen. Während des nachfolgenden Beispiels sprechen wir von Janet als Client-Benutzer und Joe als lokalem Benutzer. Janet gibt auf
gauss den folgenden Befehl ein:
$ rlogin -l joe euler
Der Server durchsucht zuerst hosts.equiv,(4) um zu sehen, ob Janet freier Zugang gewährt werden soll. Schlägt dies fehl, wird versucht, sie in .rhosts im Home-Verzeichnis von joe zu finden.
Die Datei hosts.equiv auf
euler sieht wie folgt aus:
gauss
euler
-public
quark.physics.groucho.edu andres
Ein Eintrag besteht aus dem Hostnamen, dem optional ein Benutzername folgt. Besteht der Eintrag nur aus dem Hostnamen, ist allen Benutzern dieses Host der Zugang zu diesem Host ohne weitere Prüfungen erlaubt. In unserem obigen Beispiel könnte sich Janet unter ihrem Account
janet einloggen, wenn sie von
gauss käme. Dasselbe würde für alle anderen Benutzer, mit Ausnahme von
root, gelten. Wenn Janet sich allerdings als
joe einloggen würde, müßte sie, wie gewöhnlich, das Paßwort eingeben.
Wenn, wie in der letzten Zeile des obigen Beispiels, dem Hostnamen ein Benutzername folgt, wird dem Benutzer paßwortfreier Zugang zu allen Accounts gewährt (mit Ausnahme des root-Accounts).
Vor dem Hostnamen kann auch ein Minuszeichen stehen, wie im Eintrag
-public. In diesem Fall wird die Autorisierung für alle Accounts auf
public benötigt, gleichgültig, welche Rechte von einzelnen Benutzern in deren jeweiligen .rhosts vergeben wurden.
Das Format von .rhosts ist mit dem von hosts.equiv identisch, die Bedeutung ist aber etwas unterschiedlich. Sehen wir uns mal Joes .rhosts auf euler an:
gauss janet
Der erste Eintrag erlaubt
joe freien Zugriff, wenn er sich von
chomp.cs.
groucho.edu aus einloggt, hat aber keinen Einfluß auf die Rechte anderer Accounts auf
euler oder chomp. Der zweite Eintrag ist eine leicht abgewandelte Variante des ersten Eintrags und erlaubt janet den freien Zugriff auf Joes Account, wenn sie sich von
gauss aus einloggt.
Beachten Sie, daß der Hostname des Client ermittelt wird, indem die Adresse des Anrufers auf einen Namen abgebildet wird (»Reverse Mapping«). Diese Operation schlägt aber fehl, wenn Hosts dem Resolver nicht bekannt sind. Es wird erwartet, daß der Hostname des Client dem Namen in den Hostdateien in einer der folgenden Formen entspricht:
- Der kanonische Hostname (kein Alias) entspricht dem Hostnamen in der Datei.
- Wenn der Hostname des Client ein voll qualifizierter Domainname ist (wie er z. B. vom Resolver zurückgeliefert wird, wenn DNS läuft), und nicht genau dem Namen aus der Host-Datei entspricht, wird letzterer um den lokalen Domainnamen ergänzt und erneut verglichen.
Fußnoten
- (1)
- Entwickelt von Wietse Venema, wietse@wzv.win.tue.nl.
- (2)
- Üblicherweise enthalten nur lokale Hostnamen, die über einen Lookup in /etc/hosts ermittelt wurden, keinen Punkt.
- (3)
- In einer NFS-Umgebung müssen Sie ihr möglicherweise den Modus 444 zuweisen, weil der Superuser häufig nur sehr eingeschränkt auf Dateien zugreifen kann, die über NFS gemountet sind.
- (4)
- Beachten Sie, daß hosts.equiv nicht durchsucht wird, wenn sich jemand als root einloggt.
Inhaltsverzeichnis 
Kapitel 8 
Kapitel 10