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 NTDomä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 HardwareAdresse 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 DHCP-Server 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, makessh-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