Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Konfiguration von Remote-Logins und Ausführen von Befehlen

Häufig ist es sehr nützlich, einen Befehl direkt auf einem Remote-Host ausführen zu können und diesem Befehl sogar noch Ein- und Ausgaben übers Netz zu ermöglichen.

Die traditionellen Befehle für die Ausführung von Befehlen auf entfernten Hosts sind rlogin, rsh und rcp. Ein Beispiel für den rlogin-Befehl haben wir bereits in Kapitel 1 Einführung in das Arbeiten mit Netzwerken, im Abschnitt Einführung in TCP/IP-Netzwerke. gesehen. In Systemsicherheit sprachen wir kurz über die damit einhergehenden Sicherheitsfragen und empfahlen ssh als Ersatz. Das ssh-Paket bietet die Ersatzbefehle slogin, ssh und scp.

Jeder dieser Befehle führt eine Shell auf dem entfernten Host aus und erlaubt dem Benutzer die Ausführung von Befehlen. Natürlich benötigt der Client ein Benutzerkonto auf dem Host, auf dem der Befehl ausgeführt werden soll. Folglich führen all diese Befehle einen Authentifizierungsprozeß durch. Die r-Befehle tauschen dazu einfach die Benutzernamen und Paßwörter aus. Das geschieht ohne Verschlüsselung, so daß jeder leicht die Paßwörter abhören kann. Die ssh-Befehle dagegen bieten mehr Sicherheit. Sie benutzen dafür eine Technik, die als Public Key Cryptography bezeichnet wird. Sie bietet Authentifizierung und Verschlüsselung zwischen Hosts und stellt sicher, daß weder Paßwörter noch andere Daten von anderen Hosts leicht abgehört werden können.

Es ist möglich, die Authentifizierungsprüfungen für bestimmte Benutzer noch weiter zu lockern. Wenn Sie sich beispielsweise sehr häufig auf einer anderen Maschine in Ihrem LAN einloggen müssen, wollen Sie vielleicht auch direkten Zugriff erhalten, ohne jedesmal Ihr Paßwort eingeben zu müssen. Mit den r-Befehlen war das schon immer möglich, aber die ssh-Suite macht Ihnen das noch etwas leichter. Das ist zwar immer noch keine gute Idee, denn wenn erst einmal ein Benutzerkonto geknackt wurde, kann man Zugriff auf alle anderen Benutzerkonten erlangen, die dieser Anwender für paßwortfreien Login konfiguriert hat. Trotz allem ist es eine bequeme Methode, und die Leute benutzen sie auch.

Lassen Sie uns nun darüber reden, wie wir die r-Befehle über Bord werfen und die ssh-Befehle zum Laufen bekommen.

Die r-Befehle deaktivieren

Als erstes entfernen wir alle r-Befehle, wenn sie installiert sind. Der einfachste Weg, die alten r-Befehle abzuschalten, ist, ihre Einträge in der Datei /etc/inetd.conf auszukommentieren (oder zu löschen). Die wichtigen Einträge dort sehen in etwa so aus:

# Shell, login, exec und talk sind BSD-Protokolle. shell    stream  tcp     nowait  root  /usr/sbin/tcpd /usr/sbin/in.rshd login    stream  tcp     nowait  root  /usr/sbin/tcpd /usr/sbin/in.rlogind exec     stream  tcp     nowait  root  /usr/sbin/tcpd /usr/sbin/in.rexecd

ssh installieren und konfigurieren

OpenSSH ist eine freie Version der ssh-Software. Die Linux-Portierung ist über http://violet.ibs.com.au/openssh/ und die meisten Linux-Distributionen erhältlich.¹ Auf die Kompilierung gehen wir hier nicht ein. Ausreichende Anweisungen dafür sind im Quellcode enthalten. Wenn Sie es aus einem vorkompilierten Paket installieren können, ist es vielleicht klug, dies auch zu tun.

Eine ssh-Session besteht aus zwei Komponenten. Zum einen gibt es einen ssh-Client, den Sie konfigurieren müssen und auf dem lokalen Host laufen lassen, zum anderen einen ssh-Dämon, der auf dem Remote-Host laufen muß.

Der ssh-Dämon

Der sshd-Dämon ist ein Programm, das auf Netzwerkverbindungen von ssh-Clients achtet, die Authentifizierung durchführt und den gewünschten Befehl ausführt. Es benutzt eine Haupt-Konfigurationsdatei namens /etc/ssh/sshd_config sowie eine spezielle Datei, die einen Schlüssel enthält, der von den Authentifizierungs- und Verschlüsselungsprozessen benutzt wird, um den Rechner selbst zu repräsentieren. Jeder Server und jeder Client hat seinen eigenen Schlüssel.

Den Distributionen liegt ein Hilfsmittel namens ssh-keygen bei, mit dem sich zufällige Schlüssel erzeugen lassen. Das wird normalerweise nur einmal während der Installation gemacht, um den Hostschlüssel zu bilden, den der Systemadministrator für gewöhnlich in der Datei /etc/ssh/ssh_host_key abspeichert. Die Schlüssel können beliebig lang sein, ab 512 Bits und mehr. Standardmäßig erzeugt ssh-keygen Schlüssel von 1024 Bits Länge, was auch von den meisten Anwendern übernommen wird. Um einen zufälligen Schlüssel zu erzeugen, rufen Sie ssh-keygen wie folgt auf:

# ssh-keygen -f /etc/ssh/ssh_host_key

Sie werden dann aufgefordert, eine Paßphrase einzugeben. Hostschlüssel benötigen jedoch keine Paßphrase, so daß Sie hier einfach die Return-Taste drücken können, ohne etwas einzugeben. Die Programmausgabe sieht dann etwa so aus:

Generating RSA keys:  ......oooooO...............................oooooO Key generation complete. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /etc/ssh/ssh_host_key Your public key has been saved in /etc/ssh/ssh_host_key.pub The key fingerprint is: 1024 3a:14:78:8e:5a:a3:6b:bc:b0:69:10:23:b7:d8:56:82 root@moria

Am Ende haben Sie zwei erzeugte Dateien vor sich. Der erste Schlüssel wird als privater Schlüssel bezeichnet, der geheimgehalten werden muß und in /etc/ssh/ssh_host_key aufbewahrt wird. Der zweite wird als öffentlicher Schlüssel bezeichnet und ist derjenige, den Sie mit anderen gemeinsam benutzen können; er wird in /etc/ssh/ssh_host_key.pub abgelegt.

Nachdem Sie mit den Schlüsseln für die ssh-Kommunikation ausgestattet sind, müssen Sie noch eine Konfigurationsdatei erzeugen. Die ssh-Software ist sehr mächtig, und die Konfigurationsdatei kann daher viele Optionen enthalten. Zur Einführung präsentieren wir Ihnen ein kleines Beispiel. Um die anderen Features zu aktivieren, sollten Sie in der ssh-Dokumentation nachlesen. Der folgende Code zeigt eine sichere und minimale sshd-Konfigurationsdatei. Die weiteren Konfigurationsoptionen werden ausführlich in der Manpage sshd(8) beschrieben.

# /etc/ssh/sshd_config #  # IP-Adressen, die für Verbindungen in Frage kommen. # 0.0.0.0 bedeutet alle lokalen Adressen. ListenAddress 0.0.0.0  # Der TCP-Port, der auf Verbindungen überwacht werden soll. # Vorgabewert ist 22. Port 22  # Der Name der Hostschlüsseldatei. HostKey /etc/ssh/ssh_host_key  # Die Schlüssellänge in Bits. ServerKeyBits 1024  # Erlauben wir root-Logins mittels ssh? PermitRootLogin no  # Soll der ssh-Dämon die Verzeichnis- und Dateirechte des # Benutzer-Home-Verzeichnisses auf Sicherheitsrisiken überprüfen, # bevor der Login gestattet wird? StrictModes yes  # Sind alte Authentifizierungsmethoden mit ~/.rhosts und /etc/hosts.equiv erlaubt? RhostsAuthentication no # Ist reine RSA-Authentifizierung zugelassen? RSAAuthentication yes # Ist Passwort-Authentifizierung zugelassen? PasswordAuthentication yes  # Ist /etc/hosts.equiv kombiniert mit RSA-Host-Authentifizierung erlaubt? RhostsRSAAuthentication no # Sollen ~/.rhosts-Dateien ignoriert werden? IgnoreRhosts yes # Sind Logins für Accounts mit leeren Passwörtern erlaubt? PermitEmptyPasswords no

Wichtig ist zu prüfen, ob die Zugriffsrechte der Konfigurationsdatei korrekt eingestellt sind, um sicherzustellen, daß die Systemsicherheit erhalten bleibt. Führen Sie dazu folgende Anweisungen aus:

# chown -R root:root /etc/ssh # chmod 755 /etc/ssh # chmod 600 /etc/ssh/ssh_host_key # chmod 644 /etc/ssh/ssh_host_key.pub # chmod 644 /etc/ssh/sshd_config

Der letzte Schritt in der Administration des sshd-Dämons besteht nur noch darin, ihn zum Laufen zu bringen. Normalerweise erzeugen Sie dafür eine neue rc-Datei oder tragen ihn in eine bereits existierende Datei ein, um ihn beim Systemstart automatisch auszuführen. Der Dämon läuft für sich und braucht keinen Eintrag in der Datei /etc/inetd.conf. Der Dämon muß als root laufen. Die Syntax ist sehr einfach:

/usr/sbin/sshd

Der ssh-Client

Es gibt eine Reihe von ssh-Client-Programmen: slogin, scp und ssh. Sie alle lesen dieselbe Konfigurationsdatei ein, für gewöhnlich /etc/ssh/ssh_config. Außerdem lesen sie Konfigurationsdateien aus dem Verzeichnis .ssh im Home-Verzeichnis des Benutzers, der sie ausführt. Die wichtigsten dieser Dateien sind .ssh/config, die Optionen enthalten kann, die die in der Datei /etc/ssh/ssh_config enthaltenen Optionen überschreiben, außerdem .ssh/identity, die den benutzereigenen privaten Schlüssel enthält, und die entsprechende Datei .ssh/identity.pub mit dem öffentlichen Schlüssel des Benutzers. Weitere wichtige Dateien sind .ssh/known_hosts und .ssh/authorized_keys. Über sie sprechen wir später in “ssh anwenden”. Zunächst erzeugen wir die globale Konfigurationsdatei und die Schlüsseldatei des Benutzers.

Die Datei /etc/ssh/ssh_config ist der Server-Konfigurationsdatei sehr ähnlich. Auch hier gibt es viele Features, die Sie konfigurieren können. Eine minimale Konfigurationsdatei hat die in Tabelle 12.5 gezeigte Form. Die restlichen Konfigurationsoptionen werden detailliert in der Manpage ssh(8) beschrieben. Sie können Abschnittehinzufügen, die zu bestimmten Hosts oder Gruppen von Hosts passen. Der Parameter für die Host-Anweisung kann entweder der vollständige Name eines Hosts oder ein Wildcard-Ausdruck sein, wie wir es in unserem Beispiel gemacht haben, um alle Hosts auszuwählen. Wir könnten zum Beispiel einen Eintrag wie Host *.vbrew.com erzeugen, der zu jedem Host in der Domain vbrew.com paßt.

Beispiel 12.5: Beispiel-Konfigurationsdatei für ssh-Client

# /etc/ssh/ssh_config  # Standardoptionen für die Verbindung mit einem Remote-Host Host *   # Session-Daten komprimieren?   Compression yes   # .. mit Komprimierungs-Level? (1 - schnell/schwach, 9 - langsam/gut)   CompressionLevel 6    # Zu rsh zurückkehren, falls die sichere Verbindung fehlschlägt?   FallBackToRsh no    # Keep-Alive-Nachrichten senden? Sinnvoll für IP-Masquerading   KeepAlive yes    # RSA-Authentifizierung versuchen?   RSAAuthentication yes   # RSA-Authentifizierung in Kombination mit .rhosts-Authentifizierung versuchen?   RhostsRSAAuthentication yes

Im Abschnitt über die Serverkonfiguration erwähnten wir, daß jeder Host und jeder Benutzer einen Schlüssel hat. Der Benutzerschlüssel wird in dessen ~/.ssh/identity-Datei gespeichert. Zur Erzeugung des Schlüssels benutzen Sie denselben ssh-keygen-Befehl, den wir auch zur Erzeugung des Hostschlüssels verwendet haben; nur müssen Sie diesmal nicht den Namen der Datei angeben, in der Sie den Schlüssel aufbewahren wollen. ssh-keygen gibt dafür die richtige Voreinstellung an, fragt aber trotzdem nach, ob Sie einen anderen Dateinamen wünschen. Manchmal ist es sinnvoll, mehrere identity-Dateien zu haben, weshalb ssh dies auch gestattet. Wie vorher fordert ssh-keygen Sie auf, eine Paßphrase einzugeben. Paßphrasen tragen zur Erhöhung der Sicherheit bei und sind somit eine gute Sache. Ihre Paßphrase wird bei der Eingabe nicht auf dem Bildschirm angezeigt.

Sie sollten jeden Ihrer Anwender auffordern, den Befehl ssh-keygen nur einmal auszuführen, um sicherzustellen, daß ihre Schlüsseldatei korrekt erzeugt wird. Der Befehl erzeugt für sie ein ~/.ssh/-Verzeichnis mit den entsprechenden Zugriffsrechten und ihre privaten bzw. öffentlichen Schlüssel in .ssh/identity bzw. .ssh/identity.pub. Eine Beispielsitzung sollte so aussehen:

$ ssh-keygen Generating RSA keys:  .......oooooO.............................. Key generation complete. Enter file in which to save the key (/home/maggie/.ssh/identity): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/maggie/.ssh/identity. Your public key has been saved in /home/maggie/.ssh/identity.pub. The key fingerprint is: 1024 85:49:53:f4:8a:d6:d9:05:d0:1f:23:c4:d7:2a:11:67 maggie@moria $

Nun kann man mit ssh loslegen.

ssh anwenden

Nun sollten wir ssh und seine zugehörigen Programme installiert und betriebsfertig haben. Lassen Sie uns einen kurzenBlick darauf werfen, wie man sie anwendet.

Als erstes versuchen wir uns in einen entfernten Host einzuloggen. Dazu können wir das Programm slogin benutzen, wie wir es bereits ähnlich in einem früheren Beispiel in diesem Buch mit rlogin gemacht haben. Beim ersten Versuch, eine Verbindung mit einem Host herzustellen, empfängt der ssh-Client den öffentlichen Schlüssel vom Host und fordert Sie auf, seine Identität zu bestätigen, indem er Ihnen eine Kurzform dieses Schlüssels ausgibt, die als “Fingerabdruck” bzw. Fingerprint bezeichnet wird.

Der Administrator des Remote-Hosts sollte Ihnen bereits vorsorglich den Fingerprint des öffentlichen Schlüssels mitgeteilt haben. Diesen sollten Sie Ihrer Datei .ssh/known_hosts hinzufügen. Haben Sie dagegen noch keinen Fingerprint bekommen, können Sie sich trotzdem mit dem Remote-Host verbinden, jedoch warnt ssh Sie mit dem Hinweis, daß dieser einen Schlüssel hat, und fragt Sie, ob Sie den Schlüssel vom Remote-Host akzeptieren wollen. Wenn Sie sicher sind, daß niemand gerade ein DNS-Spoofing bei Ihnen durchführt und Sie tatsächlich mit dem richtigen Host kommunizieren, beantworten Sie die Frage mit “yes”. Der relevante Schlüssel wird dann automatisch in Ihrer .ssh/ known_hosts-Datei vermerkt, und Sie werden in Zukunft nicht mehr danach gefragt. Wenn Sie irgendwann wieder eine Verbindung aufbauen und der vom Host empfangene öffentliche Schlüssel nicht mit dem gespeicherten übereinstimmt, werden Sie gewarnt, da hier eine potentielle Sicherheitsverletzung vorliegt.

Der erstmalige Login in einen Remote-Host geht etwa so vor sich:

$ slogin vchianti.vbrew.com The authenticity of host 'vchianti.vbrew.com' can't be established. Key fingerprint is 1024 7b:d4:a8:28:c5:19:52:53:3a:fe:8d:95:dd:14:93:f5. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'vchianti.vbrew.com,172.16.2.3' to the list of/     known hosts. maggie@vchianti.vbrew.com's password: Last login: Tue Feb  1 23:28:58 2000 from vstout.vbrew.com $

Sie werden nach einem Paßwort gefragt. Hier sollten Sie das Paßwort für das Remote-Benutzerkonto eingeben, nicht für das lokale Benutzerkonto. Das Paßwort wird bei der Eingabe nicht angezeigt.

Sind keine speziellen Argumente angegeben, versucht slogin einen Login mit derselben Benutzer-ID wie auf der lokalen Maschine. Mit der Option -l können Sie das überschreiben und einen alternativen Login-Namen für den Remote-Host angeben. Genau das machten wir bereits in unserem früheren Beispiel in diesem Buch.

Dateien zum bzw. vom Remote-Host können wir mit dem Programm scp kopieren. Die Syntax gleicht der vom konventionellen cp-Befehl mit der Ausnahme, daß Sie vor einem Dateinamen auch einen Hostnamen angeben können, was bedeutet, daß die Datei sich auf dem angegebenen Host befindet. Das folgende Beispiel veranschaulicht die Syntax von scp. Dabei wird eine lokale Datei namens /tmp/fred in das Verzeichnis /home/ ­maggie/ des Remote-Hosts vchianti.vbrew.com kopiert:

$ scp /tmp/fred vchianti.vbrew.com:/home/maggie/ maggie@vchianti.vbrew.com's password: fred                 100% |*****************************| 50165   00:01 ETA

Auch hier werden Sie nach einem Paßwort gefragt. Der Befehl scp zeigt standardmäßig nützliche Informationen über den aktuellen Stand des Dateitransfers an. Genauso einfach kopieren Sie eine Datei von einem Remote-Host. Dazu geben Sie einfach nur den Hostnamen und ein Verzeichnis als Quelle und das lokale Verzeichnis als Ziel an. Es ist sogar möglich, direkt von einem Remote-Host auf einen anderen zu kopieren. Allerdings ist das nicht sehr effizient, da die übertragenen Daten dann den Umweg über Ihren Host machen müssen.

Mit ssh können Sie Befehle auf dem Remote-Host ausführen. Auch hier ist die Syntax sehr einfach. Nehmen wir an, unsere Benutzerin maggie will sich das Wurzelverzeichnis auf dem Remote-Host vchianti.vbrew.com ansehen. Das kann sie wie folgt tun:

$ ssh vchianti.vbrew.com ls -CF / maggie@vchianti.vbrew.com's password: bin/    console@  dos/     home/    lost+found/  pub@   tmp/  vmlinuz@ boot/   dev/      etc/     initrd/  mnt/         root/  usr/  vmlinuz.old@ cdrom/  disk/     floppy/  lib/     proc/        sbin/  var/

Sie können ssh auch in eine Befehls-Pipeline setzen und damit Ein-/Ausgabeumleitungen durchführen wie mit allen anderen Befehlen auch, mit der Ausnahme, daß die Ein- bzw. Ausgabe vom bzw. zum Remote-Host über die ssh-Verbindung erfolgt. Das folgende Beispiel zeigt, wie Sie diese Möglichkeit mit dem Befehl tar kombinieren können, um ein komplettes Verzeichnis inklusive Unterverzeichnissen von einem Remote-Host zum lokalen Host zu kopieren:

$ ssh vchianti.vbrew.com "tar cf - /etc/" | tar xvf - maggie@vchianti.vbrew.com's password: etc/GNUstep etc/Muttrc etc/Net etc/X11 etc/adduser.conf .. ..

In diesem Beispiel haben wir die auszuführende Anweisung in Anführungszeichen gesetzt, um festzulegen, was als Argument an ssh übergeben wird und was von der lokalen Shell verarbeitet werden soll. Die Anweisung startet das Programm tar auf dem Remote-Host, archiviert das Verzeichnis /etc/ und und gibt das Archiv auf der Standardausgabe aus. Diese Ausgabe leiten wir auf die Standardeingabe eines lokalen tar-Befehls um, der das Archiv auf der lokalen Maschine wieder entpackt.

Wiederum werden wir nach dem Paßwort gefragt. Nun sehen Sie, warum wir die Empfehlung ausgesprochen haben, ssh so zu konfigurieren, daß es nicht jedesmal nach dem Paßwort fragt. Das holen wir jetzt für den Host vchianti.vbrew.com nach. Wir erwähnten früher bereits die Datei .ssh/authorized_keys — jetzt wissen Sie, wozu man sie braucht. Diese Datei enthält die öffentlichen Schlüssel für alle fernen Benutzerkonten, in die wir uns automatisch einloggen wollen. Die automatischen Logins können Sie aktivieren, indem Sie die Inhalte der Datei .ssh/identity.pub vom fernen Benutzerkonto in Ihre lokale Datei .ssh/authorized_keys kopieren. Achten Sie unbedingt darauf, daß die Zugriffsrechte von .ssh/authorized_keys so gesetzt sind, daß nur Sie darin lesen und schreiben können, damit nicht andere die Schlüssel stehlen und sich damit auf dem Remote-Host einloggen können.Um sicherzugehen, daß die Zugriffsrechte korrekt eingestellt sind, setzen Sie sie für .ssh/authorized_keys wie folgt:

$ chmod 600 ~/.ssh/authorized_keys

Die öffentlichen Schlüssel bestehen aus einer einzelnen, langen Klartext-Zeile. Wenn Sie einen solchen Schlüssel mittels Copy und Paste in Ihre lokale Datei übertragen, stellen Sie sicher, daß Sie dabei nicht versehentlich irgendwelche anderen Zeichen (z.B. Zeilenwechsel) mit übernehmen. Die Datei .ssh/authorized_keys kann viele Schlüssel enthalten, jeden davon in einer eigenen Zeile.

Die ssh-Software ist ein sehr mächtiges Werkzeug und bietet noch viele andere nützliche Eigenschaften und Optionen, die Sie vielleicht kennenlernen möchten. Mehr Informationen erhalten Sie in den Manpages und den anderen Dokumentationen zur ssh-Software.

Weitere Informationen zum Linux - Wegweiser für Netzwerker

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center