Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einleitung
2 Die Installation
3 Erste Schritte
4 Linux als Workstation für Einsteiger
5 Der Kernel
6 Die Grundlagen aus Anwendersicht
7 Die Shell
8 Reguläre Ausdrücke
9 Konsolentools
10 Die Editoren
11 Shellskriptprogrammierung mit der bash
12 Die C-Shell
13 Benutzerverwaltung
14 Grundlegende Verwaltungsaufgaben
15 Netzwerkgrundlagen
16 Anwendersoftware für das Netzwerk
17 Netzwerkdienste
18 Mailserver unter Linux
19 LAMP
20 DNS-Server
21 Secure Shell
22 Die grafische Oberfläche
23 Window-Manager und Desktops
24 X11-Programme
25 Multimedia und Spiele
26 Prozesse und IPC
27 Bootstrap und Shutdown
28 Dateisysteme
29 Virtualisierung und Emulatoren
30 Softwareentwicklung
31 Crashkurs in C und Perl
32 Einführung in die Sicherheit
33 Netzwerksicherheit überwachen
A Lösungen zu den einzelnen Aufgaben
B Kommandoreferenz
C X11-InputDevices
D MBR
E Die Buch-DVDs
F Glossar
G Literatur
Stichwort

Download:
- ZIP, ca. 15,7 MB
Buch bestellen
Ihre Meinung?

Spacer
 <<   zurück
Linux von Johannes Pl&ouml;tner, Steffen Wendzel
Das umfassende Handbuch
Buch: Linux

Linux
geb., mit 2 DVDs
1302 S., 39,90 Euro
Galileo Computing
ISBN 978-3-8362-1704-0
Pfeil 21 Secure Shell
  Pfeil 21.1 Das Protokoll
    Pfeil 21.1.1 SSH-Protokoll 1
    Pfeil 21.1.2 SSH-Protokoll 2
  Pfeil 21.2 Konfiguration eines OpenSSH-Servers
    Pfeil 21.2.1 Die /etc/ssh/sshd_config
  Pfeil 21.3 SSH nutzen
    Pfeil 21.3.1 Remote-Login
    Pfeil 21.3.2 Secure Copy
    Pfeil 21.3.3 Authentifizierung über Public-Key-Verfahren
    Pfeil 21.3.4 Secure File Transfer
    Pfeil 21.3.5 X11 Forwarding
    Pfeil 21.3.6 SSH Port Forwarding
  Pfeil 21.4 Zusammenfassung
  Pfeil 21.5 Aufgaben


Galileo Computing - Zum Seitenanfang

21.3 SSH nutzen  Zur nächsten ÜberschriftZur vorigen Überschrift

Nachdem wir unseren Server konfiguriert haben, wollen wir einen Blick auf die vielfältigen Möglichkeiten werfen, die uns SSH bietet.


Galileo Computing - Zum Seitenanfang

21.3.1 Remote-Login  Zur nächsten ÜberschriftZur vorigen Überschrift

Eines der wichtigsten Features ist das Remote-Login. Dazu gibt es zwei Möglichkeiten: Zum einen kann man unter Unix-Systemen den Kommandozeilen-Client ssh nutzen, zum anderen bietet sich unter Windows-Systemen ein Tool wie PuTTY an.

In Aktion: ssh

Das ssh-Tool gehört zum Inventar eines jeden Unix-Administrators – Sie müssen es einfach kennen. Der Aufruf des Programms selbst ist sehr einfach:

ploetner@elbs:~$ ssh root@192.168.128.171
Password:
Last login: Mon Apr 26 16:57:14 2004
ldap-server:~#

Listing 21.8  Kommandozeilen-ssh unter Unix


In diesem Beispiel haben wir uns also von unserem aktuellen System elbs aus, auf dem wir mit der Benutzerkennung ploetner eingeloggt sind, mit dem Rechner mit der IP-Adresse 192.168.128.171 verbunden und uns dort als der Superuser root eingeloggt.

Auch wurde die uns von der Konfiguration her bekannte PasswordAuthentication genutzt, die jedem Unix-Benutzer vom normalen Login-Vorgang her geläufig sein sollte. Zudem musste beim Server für diese Aktion die Option PermitRootLogin auf yes gesetzt sein, damit wir uns erfolgreich als Superuser einloggen konnten.



Galileo Computing - Zum Seitenanfang

21.3.2 Secure Copy  Zur nächsten ÜberschriftZur vorigen Überschrift

Oft muss man zwischen Servern auch Dateien austauschen, was ohne entsprechende Dienste schon recht aufwendig und schnell auch unsicher werden kann. Aus diesem Grund kann man für diese Aufgabe sinnvollerweise auch den SSH-Zugang nutzen, sodass man nicht zu viele selten benötige Dienste pflegen muss und die Daten auch sicher kopieren kann.

Dateien über SSH kopieren

Von welchem Unix-System aus Sie auch arbeiten, die benötigten Client-Programme werden in 99 % aller Fälle bereits installiert sein. Das gilt auch für scp, das ähnlich wie das bekannte cp-Kommando Dateien kopieren kann. Zusätzlich können Dateien per SSH von Servern geholt beziehungsweise auf Server kopiert werden, was sinnvoll ist. Dazu muss nur die Syntax von cp bezüglich Quelle und Ziel entsprechend angepasst werden:

$ scp user@host:quelle ziel
[Dateien senden]
$ scp quelle [quelle2 ...] user@host:ziel

Listing 21.9  Dateien holen

Genauso wie cp kann auch scp rekursiv Verzeichnisse kopieren oder Wildcards wie »*« oder »?« nutzen, die dann remote aufgelöst werden.

$ scp jploetner@172.20.2.1:~/Projekte/*.PNG .
Password:
pscp.PNG                100%   53KB  53.2KB/s   00:00
PuTTYgen.PNG            100%   61KB  61.4KB/s   00:00
PuTTY_term.PNG          100%   53KB  52.7KB/s   00:00
PuTTY_X11.PNG           100%   63KB  62.8KB/s   00:00
$

Listing 21.10  Dateien kopieren mit Wildcards


Galileo Computing - Zum Seitenanfang

21.3.3 Authentifizierung über Public-Key-Verfahren  Zur nächsten ÜberschriftZur vorigen Überschrift

RSA in der Praxis

Im Folgenden wollen wir uns mit den bereits angesprochenen Public-Key-Verfahren zur Authentifizierung beim SSH-Server beschäftigen. Bevor man irgendwelche öffentlichen und privaten Schlüssel nutzen kann, muss man diese erst einmal erstellen.

Dazu dient das Kommando ssh-keygen, dem man über den Parameter -t den Algorithmus angeben muss, mit dem wir das Schlüsselpaar später nutzen wollen.

_qk3_Erstellung eines Schlüsselpaares mittels ssh-keygen]
cvs@ploetner:~$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (~/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ~/.ssh/id_rsa.
Your public key has been saved in ~/.ssh/id_rsa.pub.
The key fingerprint is:
df:4e:09:cc:33:02:0a:7f:30:9b:10:79:24:3d:e3:86 cvs@ploetner
cvs@ploetner:~$

Im Allgemeinen wird man sich wohl zwischen RSA und DSA entscheiden. Im Beispiel haben wir uns für das Ihnen bereits bekannte RSA-Verfahren entschieden. Nach der Erzeugung des Schlüsselpaares fragt das Programm, in welcher Datei der erzeugte Schlüssel gespeichert werden soll. Meistens ist die Vorgabe ~{/.ssh/id_rsa} beziehungsweise ~/.ssh/id_dsa sinnvoll, es sei denn, man möchte den Schlüssel nicht für den aktuellen User auf diesem System generieren.

Als Nächstes wird nach einer Passphrase gefragt. Diese Passphrase wäre das Äquivalent zu einem ganz normalen Benutzerkennwort, da der private Schlüssel mit ihr verschlüsselt wäre. Die Passphrase müsste also bei jeder Benutzung des Schlüssels angegeben werden. Da wir uns aber gänzlich ohne Passwort einloggen möchten – und demzufolge ganz auf die Sicherheit und Integrität des privaten Schlüssels vertrauen –, geben wir keine Passphrase an.

Die Schlüsseldateien

Im Folgenden wurden also zwei wichtige Dateien erstellt:

  • ~/.ssh/id_rsa
    In dieser Datei liegt der private Schlüssel. Normalerweise ist dieser – sofern nichts anderes angegeben wurde – bei RSA und DSA 1024 Bit lang, kann aber durch die -b Option auch verlängert werden. Wurde der Schlüssel nicht über eine Passphrase mit 3DES verschlüsselt, sollte man strengstens darauf achten, dass diese Datei von niemandem gelesen werden kann.
cvs@ploetner:~$ ls -l .ssh/id_rsa
-rw-------  1 cvs  cvs  887 Jul 3 11:28 .ssh/id_rsa

Listing 21.11  Der private Schlüssel bei RSA: id_rsa

    • Im Falle einer Kompromittierung wären nämlich alle Systeme, auf die man von diesem User-Account aus über den Schlüssel Zugriff hätte, ebenfalls offen.
  • ~/.ssh/id_rsa.pub
    Diese Datei enthält den öffentlichen Schlüssel unseres Schlüsselpaares, den wir im Folgenden auf den Servern verteilen müssen, auf denen wir uns später ohne Passwort einloggen wollen.

Dazu kopieren wir beispielsweise mit scp die id_rsa.pub in die Datei authorized_keys im .ssh-Verzeichnis des Benutzeraccounts auf dem Server, auf dem wir uns nachher so problemlos einloggen möchten. In vielen Fällen müssen wir vorher aber erst noch besagtes Verzeichnis auf dem Rechner anlegen, bevor wir die Datei schließlich kopieren können:

cvs@ploetner:~$ ssh root@192.168.128.171
The authenticity of host 'ldap-server

(192.168.128.171)' can't be established.
RSA key fingerprint is

9e:00:79:9f:de:53:c2:27:2a:9b:4d:b6:eb:1e:b3:cc.
Are you sure you want to continue connecting
(yes/no)? yes
Warning: Permanently added '192.168.128.171' (RSA)

to the list of known hosts.
Password:
Last login: Wed Jun 30 10:48:50 2004 from elbs
ldap-server:~# mkdir .ssh
ldap-server:~# scp cvs@ploetner:~/.ssh/id_rsa.pub .
Password:
id_rsa.pub              100%  222     0.2KB/s  00:00
ldap-server:~# cat id_rsa.pub >> .ssh/authorized_keys
ldap-server:~# exit
logout

Listing 21.12  Den öffentlichen Schlüssel aktivieren

Dazu loggen wir uns zuerst per SSH auf dem Server ein und erstellen per mkdir das entsprechende Verzeichnis. Schließlich kopieren wir per scp den Schlüssel zuerst in das aktuelle Verzeichnis.

Da ja durchaus mehrere öffentliche Schlüssel autorisierte Schlüssel sein können, wollen wir die ~/.ssh/authorized_keys nicht einfach überschreiben, sondern hängen den Inhalt der Schlüsseldatei mittels cat und Ausgabeumleitung an die Datei an.

Sicheres Login ohne Passwort

Im Folgenden testen wir, ob die Authentifizierung ohne Passwort funktioniert:

cvs@ploetner:~$ ssh root@192.168.128.171
Last login: Wed Jun 30 11:58:03 2004 from ploetner
ldap-server:~#

Listing 21.13  Passwortloses Login über Public-Key-Authentifizierung

Eine solche Authentifizierung über Public-Key-Verfahren ist besonders beim Einsatz von Diensten und Skripten sinnvoll, die sich ohne Benutzermitwirkung automatisch auf fremden Systemen einloggen sollen.

Achtung auf fremden Systemen

Damit das Ganze wie in dem eben vorgestellten Beispiel funktioniert, muss auf dem Server die bereits erläuterte PubkeyAuthentication-Option gesetzt sein. [Wir haben also bisher immer implizit das SSH-Protokoll Version 2 genutzt, wie Sie vielleicht bereits an dem verwendeten Verfahren (DSA) gemerkt haben.] Außerdem ist zu beachten, dass die Sicherheit bei einem Schlüssel ohne Passphrase allein darauf beruht, dass niemand außer dem betreffenden Benutzer Zugriff auf diesen Schlüssel hat.

Sicherheitsprobleme

Daraus ergeben sich natürlich Implikationen für Systeme, auf denen Sie kein Vertrauen in den Systemadministrator haben können – und dazu gehören unter Umständen auch Benutzer mit eingeschränkten sudo-Rechten. Schließlich kann root uneingeschränkt auf alle Dateien zugreifen, selbst wenn er formal in der Unix-Rechtemaske keine Rechte hat.


Achten Sie also darauf, von unsicheren Systemen aus niemals mit privaten Schlüsseln ohne Passphrase zu arbeiten.


Diese Anmerkungen betreffen natürlich nicht die Datei authorized_keys und den öffentlichen Schlüssel. Wenn Sie das Prinzip der asymmetrischen Kryptografie verstanden haben, dann ist Ihnen dieser Fakt auch ganz klar: Die Authentifizierung gelingt nämlich immer nur in einer Richtung, sie ist nicht bidirektional. Mit anderen Worten: Sie müssen zwei Schlüsselpaare erstellen, wenn Sie mit Public-Key-Authentifizierung von System A auf System B und von System B auf System A zugreifen wollen.


Die authorized_keys-Datei sollte allerdings immer nur für den Besitzer der Datei schreibbar sein, da sich sonst jeder User, der Schreibrechte auf diese Datei besitzt, Zugriff auf den Account verschaffen kann.



Galileo Computing - Zum Seitenanfang

21.3.4 Secure File Transfer  Zur nächsten ÜberschriftZur vorigen Überschrift

Ersatz für FTP

Ist das sftp-Subsystem (SSH File Transfer Protocol auf dem SSH-Server aktiviert, so kann man FTP-ähnliche Dateitransaktionen über eine SSH-Verbindung laufen lassen. Man braucht dazu nichts weiter als das sftp-Programm, das Bestandteil der Open-SSH-Distribution ist. Einmal verbunden, kann man alle bereits vom normalen Konsolen-ftp her bekannten Befehle nutzen:

$ sftp ploetner@comrades.are-crazy.org
Connecting to comrades.are-crazy.org...
sftp> ls
.       ..       .alias   .bash_history  .bash_profile
.bashrc .cshrc   .ssh
sftp> get .bash_profile
Fetching /home/ploetner/.bash_profile to .bash_profile
~/.bash_profile             100%  704  0.7KB/s  00:01
sftp> exit

Listing 21.14  SFTP-Sitzung mit Public-Key-Authentication


Galileo Computing - Zum Seitenanfang

21.3.5 X11 Forwarding  Zur nächsten ÜberschriftZur vorigen Überschrift

Entfernte Fenster

Damit Sie Ihre Administration von Unix-Servern perfektionieren, wollen wir noch die Benutzung des X11 Forwarding erläutern. Mit diesem Feature können bekanntlich auf dem Server ausgeführte X-Anwendungen auf dem Client in einem Fenster dargestellt werden. Damit dies serverseitig überhaupt funktionieren kann, muss die Option X11Forwarding in der Datei /etc/ssh/sshd_config aktiviert (»yes«) sein.

Auf der Client-Seite benötigt man nur einen laufenden X-Server, also reicht zum Beispiel eine ganz normale KDE- oder GNOME-Sitzung des Benutzers, der auch den ssh-Befehl ausführt, [Normalerweise kann nur der Benutzer auf den X-Server zugreifen, der ihn auch gestartet hat. Wollen Sie zum Beispiel als root ein Fenster auf einem Display öffnen, das jploetner geöffnet hat, so wird das ohne Weiteres nicht funktionieren. Demzufolge würde auch in diesem Fall ein von root versuchtes ssh mit X11 Forwarding fehlschlagen, da er keinen Zugriff auf den Desktop bekommt.] vollkommen aus. Clientseitig/.ssh/config} kann man das Forwarding entweder über die ~/.ssh/config ähnlich wie in der sshd_config anschalten oder es explizit über die Kommandozeilenoption -X aktivieren.

Anschließend kann man auf dem Server einfach über ein xterm & versuchen, ein grafisches Terminal zu starten. Ist die Applikation auf dem Server installiert, sollte sich nun auf dem Desktop ein Fenster mit der Applikation öffnen. Dieses kann nun ohne Einschränkungen bedient werden. Vor allem für grafische Administrationstools wie YaST2 auf SUSE-Linux-Servern ist dieses Feature äußerst sinnvoll, da es nun wirklich keinen Grund mehr gibt, einen Server permanent mit Bildschirm und Tastatur auszustatten.


Galileo Computing - Zum Seitenanfang

21.3.6 SSH Port Forwarding  topZur vorigen Überschrift

Wie Sie bisher gesehen haben, stellt SSH bereits eine ganze Reihe nützlicher Dienste für die Remote-Administration von Unix-Servern bereit. Es gibt auch den Fall, dass man eine unverschlüsselte Kommunikation über eine unsichere Leitung übertragen muss oder aufgrund von Firewall-Regeln an bestimmte Ports nicht direkt herankommt.

Dienste tunneln

Um so ein Problem zu lösen, gibt es die sogenannten SSH-Tunnel. Zur Errichtung eines SSH-Tunnels verbindet man sich ganz normal mit einem SSH-Server, der dann zu Ihrem gewünschten Kommunikationspartner eine Verbindung aufbaut. Diese Verbindung wird anschließend über die von Ihnen gestartete SSH-Sitzung zu einem Port auf Ihrem lokalen Rechner weitergeleitet. Verbinden Sie sich nun zum Beispiel mittels Webbrowser oder einem beliebigen anderen Programm mit eben diesem lokalen Port auf Ihrem Rechner, so kommunizieren Sie indirekt über die verschlüsselte SSH-Verbindung – also über den Umweg über den SSH-Server – mit Ihrem Kommunikationspartner.

Abbildung Tux

Einen Tunnel richtet man unter Linux wie folgt ein:

$ ssh -f -N -C -L 8888:rechner:6667 -l user ssh-server

Listing 21.15  Einen Tunnel aufbauen

Dieser Aufruf bewirkt Folgendes:

  • -f
    Nach dem erfolgreichen Verbindungsaufbau forkt [Mehr zum Thema forking erfahren Sie in Abschnitt 5.3.2.] sich SSH in den Hintergrund, sodass die Shell nicht weiter blockiert wird.
  • -N
    SSH führt nach einer erfolgreichen Verbindung auf der Gegenseite kein Kommando aus – wir wollen ja nur die Port-Weiterleitung.
  • -C
    Die Verbindung wird komprimiert, damit der Datentransfer beschleunigt wird.
  • -L 8888:rechner:6667
    Öffnet uns den lokalen Port 8888, der dann über den Tunnel mit dem Port 6667 auf rechner verbunden ist. Die Strecke zwischen den beiden Systemen wird mit SSH bis zu unserem SSH-Server getunnelt und läuft ab dort unverschlüsselt weiter.
  • -l user
    Wir loggen uns auf dem SSH-Server mit dieser Benutzerkennung ein.
  • ssh-server
    Wir verbinden uns, um den Tunnel aufzubauen, mit dem SSH-Port dieses Systems. Von dort wird dann die Verbindung zu dem im -L-Parameter spezifizierten System aufgebaut.

Jetzt müssen wir, um die verschlüsselte Verbindung zu nutzen, unserem Client-Programm nur noch sagen, dass wir statt mit rechner:6667 mit localhost:8888 sprechen wollen. Ein netstat –tcp sollte uns dann eine Verbindung zum localhost-Port 8888 und eine Verbindung zum ssh-server auf den SSH-Port anzeigen.


Als normaler Benutzer können Sie unter Unix keinen der sogenannten privilegierten Ports unterhalb von 1024 belegen, da diese root vorbehalten sind. Wählen Sie lieber einen noch nicht belegten höheren Port.




Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






 <<   zurück
  Zum Katalog
Zum Katalog: Linux, Ausgabe 2011






Linux, Ausgabe 2011
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Linux-Server






 Linux-Server


Zum Katalog: Linux Hochverfügbarkeit






 Linux Hoch-
 verfügbarkeit


Zum Katalog: LPIC-1






 LPIC-1


Zum Katalog: Debian GNU/Linux






 Debian GNU/Linux


Zum Katalog: openSUSE 11.2






 openSUSE 11.2


Zum Katalog: Shell-Programmierung






 Shell-Programmierung


Zum Katalog: Ubuntu GNU/Linux






 Ubuntu GNU/Linux


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2011
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: 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.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de