Server und Serverdienste
In diesem Abschnitt stellen wir einige der wichtigsten Serverdienste vor.
Die Themen:
•
•
•
•
•
•
Domain Name Server
NFS und NIS
Samba
Apache
DHCP
SSH
Domain Name Server - DNS
Jeder mit dem Internet verbundene Rechner oder jedes Netzwerk, welches IP als
Netzwerk-Protokoll benutzt, hat eine (oder mehrere) IP-Adressen, mit der das Routing
von und zu diesem System sichergestellt wird. Da die Benutzer sich diese
Zahlenkolonnen nur schwer merken können, kann jedem Rechner, eigentlich jeder IPNummer, ein Name, der sogenannte "Hostname", zugewiesen werden.
Dieser Name wird an verschiedenen Stellen gespeichert. Sie können mit dem Kommando
hostname den Namen des Rechners herausfinden, es wird der Wert aus der Datei
/etc/hostname ausgegeben. Wenn Sie dies an einem (dauerhaft) ans Internet
angeschlossenen Rechner probieren, besteht dieser Name aus verschiedenen Teilen, die
durch Punkte getrennt sind, zum Beispiel debian.ethz.ch. Nur der erste Teil ist der Name
des Rechners (hostname), der Rest wird als Domain Name bezeichnet, hier ethz.ch.
Innerhalb einer Domain, das ist eine Gruppe von Computern in einem Netzwerk, ist meist
eine Person für die Vergabe von Computernamen zuständig und pflegt die Daten mit den
notwendigen Informationen. Dieses System ist als DNS, Domain Name Service, bekannt
und mit einem Telefonverzeichnis vergleichbar. Sie können nach einem Computernamen
suchen und erhalten dessen IP-Adresse. Lokale Computernamen können darüberhinaus
optional mit ihrem Namen in der Datei /etc/hosts gespeichert werden.
Wenn ein Debian GNU/Linux-System die IP-Adresse eines anderen Rechners benötigt,
zum Verschicken von Mail oder um eine Webseite aufzurufen, wird ein Teil der C Library
benutzt, um die Informationen zu bekommen - der resolver. Zuerst wird ein Blick in die
Datei /etc/nsswitch.conf geworfen. In dieser ist aufgeführt, an welchen Stellen
versucht werden soll, die IP-Nummer zu finden. Hier sind drei verschiedene Einträge
möglich, wenn mehrere vorhanden sind, werden diese der Reihenfolge nach durchsucht.
•
•
•
files - versucht den Hostnamen in der Datei /etc/hosts zu finden
dns - probiert es über eine Nameserverabfrage
nis - fragt eine NIS-Datenbank
Ein üblicher Eintrag in der Datei /etc/nsswitch wäre:
hosts:
files dns
Dieser Eintrag bringt den Resolver dazu, zuerst die Datei /etc/hosts und dann den in
/etc/resolv.conf definierten Nameserver (DNS) nach dem Rechnernamen zu
durchsuchen. Die Datei /etc/resolv.conf enthält, neben dem Eintrag für einen oder
mehrere Nameserver, zunächst den Namen der lokalen Domain.
debian.ethz.ch
nameserver 194.25.2.129
nameserver 192.168.22.33
Die erste Zeile bewirkt, dass wenn nur ein Rechnername ohne Angabe der Domain
angegeben wird, die lokale Domain an den Rechnernamen (Hostname) angehängt wird.
Die folgenden Zeilen beschreiben die (IP-technisch gesehen möglichst gut erreichbaren)
Nameserver. Sie sollten hier in jedem Fall IP-Nummer und nicht die Namen der Rechner
verwenden.
Alle Programme, die Sie benutzen (zum Beispiel Webbrowser), erfragen automatisch die
IP-Nummer, wenn Sie einen Rechnernamen eingeben. Natürlich können Sie aber auch
selber solche Abfragen starten. Das zu Debian GNU/Linux gehörende Paket dnsutils
enthält das Programm nslookup. Sie können nslookup interaktiv benutzen, um
mehrere Abfragen nacheinander zu starten. Die häufigste Anwendung ist aber,
nslookup für eine einzelne Abfrage zu benutzen. Hierzu geben Sie nach dem
Kommando einfach den Namen des gesuchten Rechners an:
# nslookup www.debian.org
Server:194.25.2.129
Address:194.25.2.129#53
Non-authoritative answer:
Name:www.debian.org
Address: 198.186.203.20
Nach dem befragten Server wird weiter unten die IP-Adresse für den gewünschten Server
angegeben.
NFS und NIS
Um zu der angestrebten Lösung zu kommen, vernetzte Computer als einen virtuellen Grossrechner zu
nutzen, fehlen uns noch zwei wesentliche Voraussetzungen. Zum einen brauchen wir die Möglichkeit,
Dateisysteme auf anderen Rechnern im Netz zu nutzen, zum anderen benötigen wir eine zentrale
Verwaltung der wichtigsten Systemdaten.
Die Werkzeuge zur Lösung dieser Probleme stammen von der Firma SUN, die sie zunächst für ihre
eigenen Netze entwickelte. Bald nach Einführung gab SUN dann aber die Rechte für diese Protokolle frei,
so dass heute fast alle grösseren Systeme darauf aufbauen.
Das Network File System (NFS)
Technisch gesehen baut das Network-File-System auf einer Entwicklung auf, die Remote
Procedure Call (RPC) genannt wird. Dieser "entfernte Prozeduraufruf" nutzt die
Portnummern oberhalb 10000 um es zu ermöglichen, Client-Server Software zu steuern.
Der Server stellt bestimmte Prozeduren zur Verfügung, die jeweils einer bestimmten
Portnummer zugeordnet sind. Ein Client im Netz kann nun diese Prozeduren aufrufen, es
entsteht eine Art gemischtes Programm, ein Teil läuft auf dem Client ab, ein anderer Teil
auf dem Server.
Die Zuweisung der Ports für das RPC-System übernimmt der Portmapper, ein Programm,
das immer laufen muss, wenn ein Rechner RPC-Services anbieten will.
Die oben genannte Aufteilung macht sich NFS zu Nutzen, indem dieses System
Prozeduren zur Verfügung stellt, die sich auf den Zugriff auf Dateisysteme beziehen.
Diese Prozeduren werden jetzt vom NFS-Client aufgerufen, um Zugriff auf ein
Dateisystem zu bekommen.
Der prinzipielle Aufbau von NFS
Unter NFS benötigen wir einen Rechner, der als Fileserver dient und Verzeichnisse
freigibt, und verschiedene andere Rechner, die die freigegebenen Verzeichnisse nutzen
können.
Auf der Serverseite müssen folgende Voraussetzungen erfüllt sein:
•
•
•
Der Portmapper muss laufen.
Die Daemonen rpc.nfsd und rpc.mountd müssen laufen.
Beide erhalten ihre Konfigurationsinformationen über die Datei /etc/exports Diese Datei enthält die Informationen, wer was mounten darf.
Die Clientseite muss jetzt nur noch über einen Kernel verfügen, der den Dateisystemtyp
NFS kennt, dann können sie die exportierten (freigegebenen) Verzeichnisse mit dem
mount Befehl mounten, als ob es lokale Laufwerke wären.
Der Aufbau der Datei /etc/exports
Die Datei /etc/exports steuert die Zugriffsrechte anderer Rechner auf die
Verzeichnisse des Servers. Hier werden Verzeichnisse freigegeben und die
entsprechenden Optionen, etwa ReadOnly, gesetzt. Die Datei hat eine einfache Form,
zeilenweise werden die einzelnen Verzeichnisse angegeben und mit
Zugriffsbestimmungen versehen. Dabei sind Wildcards möglich um möglichst flexibel in
der Unterscheidung zu sein, wer was mounten darf. In Klammern können noch Optionen
gesetzt werden, die die Zugriffsrechte betreffen (Read only ...) oder die das Squashing
(siehe oben) steuern.
Jedesmal, wenn Einträge verändert werden, muss den beiden Daemonen rpc.mountd
und rpc.nfsd ein HUP-Signal geschickt werden, um sie zu zwingen, die Datei
/etc/exports neu einzulesen.
Die Client-Seite
Auf der Seite des Clients, also des Rechners, der auf ein Dateisystem eines anderen
Rechners zugreifen will, gibt es nicht viel zu tun. Ein einfacher mount-Befehl reicht aus,
um ein freigegebenes Verzeichnis in den Dateibaum zu hängen.
Um z.B. das Verzeichnis /usr/public auf dem Rechner debian in das lokale
Verzeichnis /usr/local/public zu mounten, genügt es, den folgenden Mountbefehl
anzugeben:
mount -t nfs hal:/usr/public /usr/local/public
Dieser Prozess kann natürlich auch automatisiert werden, damit das Verzeichnis bei
jedem Start des Rechners wieder gemountet wird. Dazu muss wie bei lokalen Partitionen
ein Eintrag in die Datei /etc/fstab gemacht werden, in etwa so:
debian:/usr/public /usr/local/public nfs defaults 0 0
Dabei ist allerdings darauf zu achten, dass der Fileserver, hier debian, schon läuft, bevor
der Computer gestartet wird, dessen fstab diese Zeile enthält. Sonst versucht der
Rechner das Verzeichnis von debian zu mounten und es kann eine ganze Weile dauern,
bis der Timeout dafür sorgt, dass der Bootvorgang weitergeht.
Das Network Information System (NIS)
Manchmal, gerade, wenn es erwünscht ist, dass alle Rechner gleich behandelt werden
sollen, ist es von Vorteil, wenn es eine Methode gibt, die wichtigsten Systemdateien (z.B.
/etc/hosts /etc passwd /etc/group ...) zentral auf einem Server zu verwalten. Alle Zugriffe
auf diese Dateien sollten auf diesen Server umgeleitet werden.
Genau diesen Mechanismus stellt NIS zur Verfügung. In einem lokalen Netz werden zwei
Server zur Verfügung gestellt, die diese Dateien als zentrale Datenbank verwalten. Alle
Nachfragen (etwa ein GetHostByName Systemaufruf auf die Datei /etc/hosts oder ein
Einloggvorgang mit Passwortvergleich) werden auf den primären Server umgeleitet, falls
dieser nicht erreichbar ist, wird der sekundäre Server (Slave) herangezogen.
Der primäre Server sorgt selbstständig dafür, dass alle Veränderungen auch an den
Slave weitergegeben werden. So ist dieses System verhältnismässig ausfallsicher.
Immerhin ginge im gesamten Netz nichts mehr, wenn kein NIS-Zugriff auf die PasswortDatenbank mehr möglich wäre.
Der Vorteil dieser Methode liegt auf der Hand, jeder User kann sich überall im Netz
einloggen, sein Passwort verändern und mit dem neuen Passwort sich gleich darauf auf
einem anderen Rechner anmelden. Jeder neu ins Netz aufgenommene Host muss nur in
eine /etc/hosts aufgenommen werden, in die zentrale Datenbank. Probleme mit der
Zugriffsverwaltung bei NFS (siehe oben) sind ausgeschlossen, weil sicher gewährleistet
ist, daß alle User überall die gleiche UID und GID besitzen.
Samba
Samba verbindet zwei Welten miteinander. Es dient als Datei- und Druckerserver für über das Netzwerk
angeschlossene Windows-Rechner. Samba benutzt hierzu das von Microsoft benutze SMB (Server
Message Block)-Protokoll, es sind so an den Windows-Rechnern keinerlei Veränderungen vorzunehmen
oder gar zusätzliche Software zu installieren.
Funktionen von Samba
Samba besteht aus zwei existenziellen Programmen, smbd und nmbd, welche die grundlegenden
Funktionen implementieren. Diese sind:
•
Datei- und Druckdienste
•
•
•
Authentifikation und Authorisation
Namensauflösung
Browsing
Datei- und Druckdienste, sowie Authentifikation und Authorisation werden von smbd, dem SMBDaemon, zur Verfügung gestellt.
Laufwerke und Druckdienste können auch mit Passwörtern geschützt werden. Im
einfachsten Fall kann ein Passwort einem Laufwerk oder Drucker zugeordnet werden.
Empfehlenswerter ist es, jedem Benutzer einen eigenen Benutzernamen und ein
Passwort zu geben, der Systemadministrator entscheidet dann, welche Zugriffe für
welchen Benutzer gestattet sind.
Windows NT erlaubt darüberhinaus eine weitere Stufe der Authentifizierung durch die
Koordination der Netzwerkdienste über einen Server, dem sogenannten "Domain
Controller". Eine Windows NT Domain ist eine Gruppe von Rechnern, die auf einen
gemeinsamen Domain Controller zugreifen.
Namensauflösung sowie Browsing werden von nmbd zur Verfügung gestellt.
Die Auflösung von Namen kann via „broadcast“ oder „point-to-point“, erfolgen. Mit der
Broadcast-Methode "ruft" ein Rechner, der einen Service sucht, ins Netz und wartet auf
eine Antwort. Die zweite Methode benutzt das sogenannte WINS, den Windows Internet
Name Service. Hierbei sendet jeder Client sendet seinen NetBIOS-Namen und die IPAdresse an den Server, der die Informationen in einer Datenbank speichert. Bei der
Kommunikation wird der Namen des gewünschten Rechners übermittelt und die dazu
passende IP-Adresse zurückgeschickt.
Das Browsing stellt eine Liste der verfügbaren Laufwerke und Drucker dar. In einem LAN
gibt es zwischen den teilnehmenden Rechnern eine „Abstimmung“ und der "dominierende
Rechner" wird zum LMB, zum Local Master Browser, erklärt der die verfügbaren Dienste
pflegt. Die Liste stellt die „Netzwerk Umgebung“ dar. Als Ergänzung gibt es noch die
DMBs, die Domain Master Browsers, welche die Listen zwischen NT-Domänen und
gerouteten Netzwerken. koordinieren.
Samba-Werkzeuge
Im Samba-Paket sind eine Reihe von Werkzeugen enthalten, andere sind unter Debian GNU/Linux als
separate Pakete verfügbar.
•
•
•
smbclient - ein einfaches Programm, ähnlich wie ftp, mit dem Sie eine Verbindung von einem
GNU/Linux-System zu einem SMB-Laufwerk oder einem Drucker herstellen können und Dateien
übertragen können.
nmblookup - ein NetBIOS Name Service Client. Hiermit können Sie IP-Adressen und Namen von
anderen Rechnern im Netz ermitteln.
swat - Ein webbasiertes Administrationstool.
SMB-Dateisysteme
Mit Samba können Sie von einem Windows-Rechner aus Dateisysteme Ihres Linux-Rechners völlig
transparent nutzen, als wenn diese auf einer lokalen Festplatte liegen würden. Aber auch der umgekehrte
Weg funktioniert, über das smbfs-Dateisystem können Sie auf Laufwerke zugreifen, die von einem
Windows-Rechner freigegeben wurden. So können Sie zum Beispiel ein Verzeichnis /mnt/win/ anlegen
und das entsprechende Laufwerk Ihres Windows-Rechners dort mounten. Sie können in diesem
Verzeichnis alle Aktionen (lesen, schreiben, löschen usw. von Dateien) ausführen, wie auf den lokalen
Platten bzw. Partitionen.
Konfiguration und Verwaltung
Samba wird über die Datei /etc/smb.conf konfiguriert. Dies ist, wie unter Debian GNU/Linux üblich,
eine normale ASCII-Datei, die Syntax ähnelt den von Windows bekannten*.ini-Dateien.
Referenzen:
http://samba.org/ - Samba Homepage.
http://www.oreilly.com/catalog/samba/ - englischsprachige Online-Version des O'Reilly
Buches „Using Samba“.
http://kt.linuxcare.com/KC/samba/ - neuester Stand zur Samba-Entwicklung
Administrationswerkzeuge
SWAT - Das Samba Web Administration Tool (SWAT) stellt eine webbasierte
Konfigurationsoberfläche für Samba zur Verfügung. SWAT ist Bestandteil der Samba
Distribution, wurde aber für Debian GNU/Linux als eigenes Paket gepackt. Da SWAT
webbasiert ist, benötigen Sie ebenfalls einen Webserver (apache) auf Ihrem System.
Starten Sie dann Ihren Webbrowser mit der URL http://localhost:901/.
gnosamba - ist ein grafisches Werkzeug zur Konfiguration von Samba. Sie können mit
gnosamba eine bestehende Samba-Konfigurationsdatei einlesen und verändern.
gnomba - ist eine grafische Oberfläche für das zum Samba-Paket gehörende Programm
smbclient. Sie können mit gnomba die freigegebenen Laufwerke und Drucker suchen
lassen und gleich an Ihrem System anmelden. Dies entspricht in etwa der von Windows
bekannten „Netzwerkumgebung“.
Apache Webserver
Anfang 1995 war die beliebteste Server-Software für das Web der freie NCSA-Server, der am "National
Center for Supercomputing Applications" an der Universität von Illinois entwickelt wurde. Die OpenSource
Gemeinde übernahm weitere Entwicklungen in Form von sogenannten „Patches“. Die Vielzahl dieser
Patches führte dann zum Namen: „A PAtCHy server“ - Apache.
Auch wenn man einen Rechner nicht an's Internet angeschlossen hat, macht ein eigener Webserver
häufig Sinn. Bei der Entwicklung eigener Webseiten und Scripts kann das System vorab getestet werden,
ohne die Seiten auf einem an das Internet angeschlossenen Server zu installieren.
Apache installieren & einrichten
Die Installation von Apache kann wie gewohnt mit apt-get install apache
durchgeführt werden. Das Paket beinhaltet ein Konfigurationscript, welches während der
Installation gestartet wird. Wenn man Apache später neu konfigurieren möchten, kann
das mit dem Programm apacheconfig erfolgen.
Folgende Angaben werden vom Konfigurationsprogramm erfragt:
•
E-mail Adresse des Webmasters
•
Das Zuladen von optionalen Modulen
Das Konfigurationsprogramm wird die nötigen Dateien, Module genannt, unter
/etc/apache/ speichern. Spätere Aenderungen erfordern den Neustart des
Webservers.
Der Webserver ist nun installiert. Er kann mit einem beliebigen Webbrowser unter der
Adresse: http://localhost/ erreicht werden. Es wurde bei der Installation eine Testseite
eingerichtet, diese sollte angezeigt werden. Die Dateien zu dieser Seite findet man unter
/var/www/. Dort können nun eigene Seiten ableget werden.
Die Dokumentation zur Installation befindet sich im Paket apache-doc.
Konfigurationsdateien
Unter Debian GNU/Linux befinden sich die Konfigurationsdateien des Apache unter
/etc/apache/. Apache benutzt drei Konfigurationdateien:
•
•
•
httpd.conf - Informationen zum Verhalten des Servers.
srm.conf - Informationen zu den Dokumenttypen
access.conf - Informationen zu den Zugriffen auf die Dokumente
Debian GNU/Linux benutzt während der Installation des Paketes das Programm
apacheconfig, um diese Dateien zu konfigurieren. Sie können apacheconfig zu jeder
Zeit wieder aufrufen (als Superuser).
Logdateien
Apache protokolliert alle Aktionen in zwei Logdateien, welche unter /var/log/apache/
zu finden sind:
•
•
error_log - Fehlermeldungen.
access_log - Hier werden alle übertragenen Dateien protokolliert.
Starten & Stoppen
Sie können den Apache als Superuser über das Script /etc/init.d/apache starten,
neu starten und stoppen. Wenn Sie Veränderungen an den Konfigurationsdateien
vorgenommen haben, müssen Sie den Apache neu starten. Wenn dieser Neustart
misslingt, liegt ein Fehler in den Konfigurationsdateien vor.
Apache konfigurieren & optimieren
Der Apache Webserver verfügt über eine Vielzahl von Funktionen zur individuellen Konfiguration. Drei
davon, das Erstellen von geschützten Verzeichnissen , das Umleiten von Webseiten, und die Behandlung
von Fehlermeldungen wollen wir hier vorstellen.
Geschützte Verzeichnisse
Wenn Sie Verzeichnisse auf Ihrem Webserver mit einem Passwort schützen wollen, so
erzeugen Sie in dem gewünschten Verzeichnis die Datei .htaccess. Diese sollte
folgenden Inhalt haben:
AuthUserFile /home/user007/www/.passwd
AuthName "user007"
AuthType Basic
<Limit GET POST>
require valid-user
</Limit>
Nun benötigen Sie noch die Datei mit dem Passwort in verschlüsselter Form. Achten Sie
darauf, daß diese Datei auf keinen Fall innerhalb der aus dem Netz zugänglichen
Webseiten liegt! Erzeugen Sie die Datei /home/user007/www/.passwd, mit folgendem
Eintrag:
user007:gfrzGZ98bsd8
Sie können ein verschlüsseltes Passwort mit dem Programm mkpasswd aus einem
Klartext erzeugen.
Umleitungen
Manchmal ist es gewünscht, einzelne Webseiten oder gar komplette Server umzuleiten.
Dies kann bei einem Providerwechsel nötig sein oder wenn Sie die Struktur Ihres Servers
verändert haben. Wenn Sie einen kompletten Server umleiten wollen, weil sich
beispielsweise der Name geändert hat, so aktivieren Sie das Modul mod_alias und
ergänzen Sie die Datei /etc/apache/httpd.conf um die Zeile:
Redirect / http://www.debian.org/
Dies führt aber nicht in allen Fällen zu dem gewünschten Ergebnis, zum Beispiel wenn
nicht auf die Hauptseite, sondern auf eine alte URL unterhalb der Hauptseite zugegriffen
wird. Besser ist es, wenn Sie alle Zugriffe auf den Server abfangen und dem Client
(Browser) eine neue URL „unterschieben“. Hierzu benötigen Sie das Modul
mod_rewrite und folgende Zeilen in der Konfiguration:
RewriteEngine On
RewriteRule /.* http://www.debian.org/ [R]
Dies bewirkt, dass alle Anfragen auf den Server umgeleitet werden.
Fehlermeldungen
Fehlermeldungen werden mit einer Webpage mit der Information „Error 404: Page Not
Found“ quittiert. Sie können mit dem Apache Webserver diese Fehlermeldungen
individuell gestalten oder auch dafür sorgen, dass in dem Fall, dass eine Seite nicht
gefunden wird, der Client auf eine andere Seite geleitet wird. Standardmässig bekommen
Sie eine Fehlermeldung, wenn eine Seite nicht gefunden wurde, dazu müssen Sie nichts
konfigurieren. Je nach Fehlernummer können Sie ein anderes Verhalten erzwingen.
Neben der Fehlernummer müssen Sie noch eine URL angeben, die dem Client
übermittelt werden soll. Diese URLs können mit einem / beginnen, wenn es sich um
lokale URLs handelt, oder auf entfernte Server verweisen.
ErrorDocument
ErrorDocument
ErrorDocument
ErrorDocument
500
404
401
403
http://foo.example.com/cgi-bin/tester
/cgi-bin/bad_urls.pl
/subscription_info.html
"Sorry can't allow you access today"
DHCP
DHCP ist ein sehr verbreitetes Protokoll, um automatisch Rechner für den Zugang zum Netz zu
konfigurieren. Hierzu ist es notwendig, einen DHCP-Server aufzusetzen, von dem die Clients
(zum Beispiel die Arbeitsplatzrechner) die nötigen Daten (IP-Nummer, Netzmaske oder auch
Nameserver-Adresse) beziehen.
Wir nstallieren zunächst das Paket dhcp. Die Konfiguration für den DHCP-Server finden wir in
der Datei /etc/dhcpd.conf.
Hier ein Beispiel für die Datei /etc/dhcpd.conf bei der jedem Rechner (Client) eine feste IPNummer zugewiesen wird. Diese wird anhand der Hardware Adresse ( MAC-Adresse) der
Netzwerkkarte zugeordnet.
# dhcpd.conf
#
option domain-name "openoffice.de";
option domain-name-servers gateway.openoffice.de;
option subnet-mask 255.255.255.240;
default-lease-time 600;
max-lease-time 7200;
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.10 192.168.1.255;
option broadcast-address 192.109.42.16;
option routers gateway.openoffice.de;
}
host imac {
hardware ethernet 08:00:07:26:c0:a5;
fixed-address sushi.openoffice.de;
}
Diese Konfiguration benutzt ein nicht geroutetes Netz, welches Sie problemlos zu Hause für Ihr
internes Netz verwenden können. Weiterhin werden die ersten 9 Adressen nicht benutzt, Rechner,
die Ihre Netzwerkangaben per DHCP beziehen, benutzen IP-Nummer ab der 192.168.0.10
aufwärts.
Sie müssen für jeden Rechner, den Sie über den DHCP-Server versorgen wollen, einen Eintrag,
wie hier im Beispiel für den Rechner „imac“ gezeigt, vornehmen. Wenn Sie die Hardware-
Adresse Ihrer Netzwerkkarte nicht kennen, konfigurieren Sie den DHCP-Server erst einmal ohne
diesen Eintrag und lesen weiter. Sie können die Hardware-Adresse auch später aus dem Logfile
Ihres Servers entnehmen.
Weiterhin müssen Sie in der Datei /etc/init.d/dhcp die Variable run_dhcp auf 1 ändern.
Danach können Sie mit /etc/init.d/dhcp start den DHCP-Server aktivieren.
Starten Sie nun einen der Rechner, die per DHCP versorgt werden sollen (Client). Wenn Sie noch
keinen Eintrag für die Hardware-Adresse vorgenommen haben, können Sie diese aus dem Logfile
entnehmen. Benutzen Sie dazu als Superuser das Kommando: tail -f /var/log/messages.
Fügen Sie die angezeigte Adresse in die Konfigurationsdatei ein und starten Sie den DHCPServer neu (mit: /etc/init.d/dhcp stop und /etc/init.d/dhcp start). Sollte Ihr Client
mittlerweile aufgegeben haben, so starten Sie diesen Rechner ebenfalls neu.
Alternativ kann auch das Kommando pump benutzt werden um erneut eine DCHP Abfrage zu
starten.
Eine etwas umfangreichere Konfiguration, die auch eine dynamische Adressvergabe zuläßt und
für einen Rechner eine feste IP-Adresse zuweist finden Sie hier:
# option definitions common to all supported networks...
option domain-name "openoffice.de";
option domain-name-servers ns.openoffice.de;
#option subnet-mask 255.255.255.224;
default-lease-time 600;
max-lease-time 7200;
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.20 192.168.1.255;
option domain-name-servers 192.168.1.6;
option domain-name "openoffice.de";
option routers 192.168.1.6;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
default-lease-time 600;
max-lease-time 7200;
}
host surimi {
hardware ethernet 00:60:08:78:c3:67;
fixed-address surimi;
}
SSH - Gesicherte Kommunikation über unsichere Netz
Die Secure Shell erlaubt das Login auf einer entfernten Maschine, die interaktive oder nichtinteraktive
Ausführung von Kommandos auf der entfernten, und das Kopieren von Dateien zwischen verschiedenen
Rechnern eines Netzes. Sie erlaubt eine starke Authentifizierung und eine kryptographisch gesicherte
Kommunikation. Die Secure Shell deckt weitgehend den Funktionsumfang von Telnet und teilweise sogar
von FTP ab und kann als deren sichere Alternative angesehen werden.
Implementierung
Die SSH unterstützt neben Linux und Windows (cygwin) eine breite Palette von Plattformen. Darunter
finden sich freie Implementierungen, aber auch kommerzielle Programme für eine strenges
Sicherheitskonzept. Die nachfolgenden Darstellungen beziehen sich auf die nichtkommerziellen
Versionen 1.2.x, die konstenfrei beschafft und genutzt werden können, sowie die von diesen
Implementierungen realisierte Version 1.x des SSH-Protokolls.
Eigenschaften
•
•
•
•
•
•
•
•
Durch die Verwendung einer auf dem asymmetrischen Kryptosystem RSA basierenden
Authentifizierung des Servers werden mehrere Sicherheitslücken (z.B. IP-, Routing- und DNSSpoofing) geschlossen.
Der Klient ist sowohl durch systemweite als auch nutzerbezogene Konfigurationsdateien
steuerbar. Damit kann der Administrator sinnvolle Voreinstellungen vornehmen, die dem
gewöhnlichen Anwender die Arbeit stark erleichtern.
Die Uebertragung beliebiger Binärdaten zwischen den Maschinen ist möglich. Eine Kompression
der Daten wird optional unterstützt.
Es stehen verschiedene Verfahren zur Authentifizierung des Klienten gegenüber dem Server zur
Verfügung.
Im Standardfall erfolgt eine automatische und transparente Verschlüsselung der gesamten
Kommunikation mittels eines der bei der Generierung der Software ausgewählten symmetrischen
Verfahren (IDEA, Triple DES, DES, ...).
SSH unterstützt den Schutz von X11-Verbindungen und beliebigen TCP-Verbindungen durch
deren Weiterleitung über einen kryptographisch gesicherten Kanal. Diese Funktionalität ist eine
Spezifik der Secure Shell, die von verschiedenen anderen weit verbreiteten und frei verfügbaren
Sicherheitswerkzeugen nicht angeboten wird.
Jeder SSH-Server-Prozeß (Dämon) arbeitet mit zwei RSA-Schlüsselpaaren:
1. Ein langlebiges Paar (eH , dH) aus öffentlichem und privatem Host-Key dient der
Identifikation der Maschine und ist für alle auf dieser Maschine laufenden Dämonen
identisch.
2. Beim Start kreiert jeder Server-Prozess ein Server-Key-Paar (eS , dS) das er in
bestimmten Intervallen (in der Regel nach jeweils einer Stunde) verändert, sofern es
benutzt wurde. Dieses Paar wird niemals in einem File abgelegt. Die dynamischen
Schlüssel sollen verhindern, dass ein Angreifer aufgezeichnete Sitzungen entschlüsseln
kann, falls es ihm später gelingen sollte, in den Server einzudringen und dessen
langlebige Schlüssel zu stehlen.
Jeder Nutzer kann eine beliebige Anzahl von RSA-Schlüsseln zu seiner eigenen Identifikation
verwalten und verwenden. Zu deren bequemer Handhabung steht der SSH-Agent zur Verfügung.
Kommando-Übersicht
Zur SSH-Distribution gehören folgende Kommandos:
•
•
•
Klienten: ssh oder das Synonym slogin sind ein funktionaler Ersatz für telnet. In seinem
eigenen Interesse sollte jeder Anwender an Stelle von telnet konsequent die SSH einsetzen.
scp kopiert Files, gesichert zwischen zwei Maschinen unter Nutzung von ssh; ersetzt ftp.
Server: sshd, ist der Secure Shell Dämon.
Administrationswerkzeuge: ssh-keygen erzeugt die RSA-Schlüssel, ssh-agent
verwaltet private RSA-Keys, ssh-add registriert neue Schlüssel beim SSH-Agenten, make-
ssh-known-hosts erstellt eine Liste mit bekannten öffentlichen Host-Keys einer Domäne.
Prinzipieller Ablauf beim Login
Das Login auf einem Server läuft gemäss SSH-Protokoll 1.x folgendermassen ab:
•
•
•
•
•
•
•
•
•
•
Der Klient baut eine TCP-Verbindung zum Server auf (Default-Port: 22).
Beide Partner tauschen die jeweils verwendete Protokoll-Version aus. Falls die Versionen
inkompatibel sind, wird die Kommunikation abgebrochen.
Klient und Server schalten auf ein paketbasiertes Binär-Protokoll um.
Der Server sendet seine beiden öffentlichen RSA-Schlüssel eH und eS (Host- und Server-Key)
sowie eine Auflistung der von ihm unterstützten symmetrischen Chiffren zum Klienten.
Der Klient verifiziert eH über eine lokale Datenbasis (bzw. "lernt" diesen Key, falls es der Nutzer
zulässt).
Wurde eH akzeptiert, so generiert der Klient einen zufälligen Sitzungsschlüssel, chiffriert diesen
mittels der beiden RSA-Keys eH und eS und sendet das Resultat zusammen mit der Angabe,
welches der angebotenen symmetrischen Verfahren er gewählt hat, an den Server.
Ab jetzt läuft die gesamte Kommunikation verschlüsselt ab.
Der Klient authentifiziert sich mit einem der jeweils unterstützen Verfahren.
Nach erfolgreicher Authentifizierung wird für den Nutzer eine Arbeitsumgebung auf dem ServerRechner hergestellt. Dazu gehört z.B. das Setzen von Umgebungsvariablen (u.a. TERM und
DISPLAY) sowie die Umleitung von X11- und ggf. auch beliebigen TCP-Verbindungen.
Der Austausch der Nutzerdaten beginnt.
Verfahren zur Authentifizierung des Klienten
SSH unterstützt verschiedene Verfahren zur Authentifizierung des Klienten, wobei die Nutzung der
einzelnen Verfahren durch Kommandozeilen-Optionen bzw. Einträge in den Konfigurationsdateien gezielt
zugelassen bzw. unterdrückt werden kann. Die in einer konkreten Konstellation verfügbaren Verfahren
werden nacheinander bis zum ersten Erfolg oder bis zum definitiven Misserfolg versucht:
•
•
Reine RSA-Authentifizierung: Sie stellt die flexibelste und potentiell sicherste Methode dar.
Hierbei weist der Nutzer die Kenntnis seines privaten Schlüssels und damit seiner Identität nach,
ein Verfahren das sich unter Verwendung des SSH-Agenten automatisch abwickeln lässt. Die zur
Authentifizierung nutzbaren öffentlichen Schlüssel stehen auf dem Server im File
$HOME/.ssh/authorized_keys. Das Schlüsselpaar des Nutzers wird beim Klienten in einer
Datei, standardmäßig in $HOME/.ssh/identity, gespeichert.
Passwort-Authentifizierung: Die Authentifizierung erfolgt durch Angabe eines Nutzerpassworts,
wobei dieses immer verschlüsselt übertragen wird. Im Standardfall handelt es sich dabei um das
normale UNIX-Passwort.
Weitere Informationsquellen
•
•
lSSH-FAQs:
o http://www.tigerlair.com/ssh/faq/
o http://www.employees.org/~satch/ssh/faq/
o http://www.ayahuasca.net/ssh/ssh-faq.html
SSH Protocols and Secure Shell - Informationen der Firma SSH Communications Security Ltd.
zur SSH
© Copyright 2024 ExpyDoc
