 |
Netzwerk-Installationsanleitung für Kernel 2.4 und 2.6 |  |
 |
|
 |
 |
 |
|
|||||||
|
|||||||
|
| Zurück | Inhalt | Vorwärts |
| Dieses Kapitel wurde freundlicherweise zur Verfügung gestellt von: Michael Schlenstedt |
Unter Linux können eine Vielzahl von unterschiedlichen Diensten laufen, die es ermöglichen, den Rechner über das Netzwerk zu erreichen. Beispiele für solche Dienste sind zum Beispiel telnet, ftp, oder ssh (Secure Shell).
Der Administrator des Netzes (ja, so darfst Du Dich jetzt nennen ;-)) muss sich jedoch im klaren sein, dass mit jedem angebotenen Dienst auch die Sicherheit des gesamten Systems abnimmt. Gerade beim Anschluss eines Netzes an das Internet sollte man dieses immer im Hinterkopf behalten.
Aus diesem Grund ist es wichtig, wirklich nur die Dienste auf dem Server zu aktivieren, die unbedingt notwendig sind. Zudem sollte man den Zugriff dann auf das interne Netz beschränken, wenn die Dienste nicht auch von außerhalb genutzt werden sollen. Dienste, die man nicht kennt, braucht man offensichtlich auch nicht. Wie sagt es Peter Lustig immer so schön: ABSCHALTEN!
Um den Server auch Fernadministrieren zu können, sind jedoch einige Dienste notwendig. Da sich ein Linuxrechner komplett über das Netzwerk steuern lässt und der Administrator jegliche Software (sowohl X- als auch Konsolensoftware) auf dem Server auch Remote bedienen kann, ist eine Grafikkarte, Tastatur und ein Bildschirm am Server überflüssig.
Viele der zentralen Dienste auf einem Server werden über die Datei /etc/inetd.conf gesteuert (so auch bei SuSE). Durch das Aktivieren eines Dienstes in dieser Konfigurationsdatei ist er über das Netzwerk ansprechbar. Ein Beispiel für einen Dienst, der über den inetd gesteuert wird, ist z. B. ftp oder telnet. Zunächst sollten alle Dienste in dieser Datei deaktiviert werden. Für die Administration des Servers kann lediglich der Dienst telnet sinnvoll sein, da hierbei jedoch alle Daten unverschlüsselt übertragen werden, sollte dieses Protokoll nicht mehr verwendet werden und auf ssh (Secure Shell) umgestiegen werden. Wer dennoch telnet verwenden will, muss die Raute ("#") vor der entsprechenden Zeile entfernen. Alle restlichen Dienste bleiben, wie gesagt, zunächst deaktiviert. Die entsprechende Zeile für telnet muss wie in Listung 4.1 gezeigt, ausschauen.
| Listing 4.1: Die Datei /etc/inetd.conf |
| # See "man 8 inetd"
for more information. # # If you make changes to this file, either reboot your machine or send the # inetd a HUP signal with "/etc/init.d/inetd reload" or by hand: # Do a "ps x" as root and look up the pid of inetd. Then do a # "kill -HUP # The inetd will re-read this file whenever it gets that signal. # # # telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd |
Falls noch nicht geschehen, muss natürlich der Telnet-Daemon installiert werden. Unter SuSE findet man ihn in der Serie "n Netzwerk-Support" (Paket: telnet-server). Zusätzlich muss ebenfalls der TCP-Wrapper aus der gleichen Serie (Paket: tcpd) installiert sein. Nach einem Neustart des Internet-Daemons (inetd) wird der Dienst aktiv. Dieses lässt sich durch folgenden Befehl erledigen:
skill -HUB $(pidof inetd)
Anschließend ist der Server durch telnet wgserver1 von jedem Rechner im LAN erreichbar.
Ein wesentlich sicherer Dienst als telnet ist ssh (Secure Shell), da hier eine verschlüsselte Übtertragung der Daten stattfindet. Zudem lassen sich hierüber sehr bequem X11-Programme ohne das lästige Setzen der Display-Variablen, wie bei telnet nötig, starten. Wenn immer möglich, sollte man ssh und nicht telnet einsetzen!
Der ssh-Serverdienst muss lediglich auf dem Server aktiviert werden. Das Paket befindet sich bei SuSE in der Serie "sec Sicherheitsrelevante Software" und heißt sinnigerweise "ssh". Das Paket enthält zwar beides, Client- und Serversoftware, aktiviert wird die Serversoftware aber nur, wie schon erwähnt, auf dem Server. Dieser Dienst wird nicht über den inetd gestartet, sondern über ein eigenes Init-Skript. Um ssh zu aktivieren, setzt man in der zentralen Konfigurationsdatei /etc/rc.config (nur SuSE!) die entsprechende Variable auf "Yes":
#
# Start the ssh daemon ? (yes/no)
#
START_SSHD="yes"
Konfiguriert wird der sshd über die Datei /etc/ssh/sshd_config. SuSE hat hier bereits sinnvolle Voreinstellungen aktiviert. Lediglich geringfügige Änderungen müssen vorgenommen werden. Wer X11-Programme auf dem Server ausführen möchte (z. B. YaST2), sollte das X11-Forwarding aktivieren. Zudem sollte man sshd darauf beschränken, lediglich Verbindungen vom internen LAN anzunehmen (es sei denn, man möchte vom Internet aus auf den eigenen Server zugreifen):
ListenAddress 127.0.0.1
ListenAddress 192.168.99.1
X11Forwarding yes
Auf den Clients muss der sshd-Server nicht aktiviert sein (obwohl es in einigen Fällen praktisch sein kann, auch von einem Client auf den anderen zugreifen zu können. Dann kann man natürlich auch den sshd auf den Clients aktivieren).
Mittels ssh gibt es 2 Möglichkeiten, sich gegenüber dem Server zu identifizieren. Zum einen die herkömmliche Art analog zu telnet: Über Benutzernamen und Passwort. Hierbei wird das Passowrt über einen sicheren Tunnel zum sshd übermittelt. Diese Authentifizierung ist zwar ebenfalls verschlüsselt, bietet aber durch den Tunnel einen weiteren Angriffspunkt (der jedoch im internen LAN zu vernachlässigen ist). Über diese Variante lässt sich eine Verbindung zum Server folgendermaßen aufbauen:
ssh wgserver1 -l BENUTZERNAME
Nach Eingabe des Passwortes steht einem eine Shell zur Verfügung. Eine weitere Möglichkeit, sich gegenüber dem Server zu authentifizieren, ist über sogenannte Schlüssel. Hierbei weisen sich die Partner der Verbindung gegenseitig mit den Schlüsseln aus. Dieses geschieht mit 2 Schlüsseln: Einem öffentlichen und einem privaten Schlüssel. Der Partner bekommt bei jeder Verbindung den öffentlichen Schlüssel mitgeteilt, akzeptiert aber nur die Verbindung, wenn der zugehörige private Schlüssel auf dem Rechner vorhanden ist. Es handelt sich dabei um das gleiche Prinzip wie bei PGP.
Ein weiterer Vorteil beim Verwenden der Schlüssel ist, dass hier das lästige eingeben des Passwortes entfällt, zudem handelt es sich hierbei um die sicherere Methode. Um diese Variante zu nutzen, muss man zunächst einen eigenen Schlüssel auf dem Server generieren. Hierzu loggt man sich auf dem Server ein und gibt im eigenen Homeverzeichnis folgenden Befehl ein:
ssh-keygen
Die Abfrage des Passwortes bestätigt man einfach zweimal mit Enter. Im Homeverzeichnis wurde nun ein neues Verzeichnis .ssh erstellt, in dem sich die Dateien mit dem öffentlichen und privaten Schlüssel befinden.
Nun loggt man sich auf dem Client ein und wechselt hier ebenfalls in sein Homeverzeichnis. Auch hier generiert man ein Schlüsselpaar mit "ssh-keygen". Der jetzt erzeugte öffentliche Schlüssel muss auf den Server kopiert werden. Dazu loggt man sich wiederum auf dem Server ein und erstellt eine neue Datei .ssh/authorized_keys, in die man den Inhalt der Datei .ssh/identity.pub vom Client kopiert (z. B. mit Copy&Paste).
Jetzt reicht es aus, sich auf dem Server mittels
ssh wgserver1
einzuloggen. Die Eingabe des Usernamens und Passwortes entfällt, da man sich gegenüber dem Server durch den öffentlichen (und privaten) Schlüssel identifiziert hat.
Nach dem Einloggen ist es möglich, jegliche X11- und Konsolenprogramme zu starten und so den Server komplett Fernzuadministrieren.
Auch für Windows gibt es sehr leistungsfähige und kostenlose ssh- und telnet-Clients. Ein sehr leistungsfähiges und trotzdem einfaches Programm (es ist keine Installation notwendig!) ist Putty. Der ursprünglich nur telnet beherrschende Client TerraTerm kann mittlerweile ebenfalls als ssh-Client "aufgerüstet" werden.
|
|
|
Abbildung 4.1: ssh/telnet-Client Putty |
Beide Clients bieten das direkte Anmelden über Kennung und Passwort sowie auch die Anmeldung über das Schlüsselpaar. Die Konfiguration ist der entsprechenden Hilfe und/oder Webseite zu entnehmen.
| Zurück | Inhalt | Vorwärts |
|
||||
|
