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

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

Spacer
Linux von Johannes Plötner, Steffen Wendzel
Das umfassende Handbuch
Buch: Linux

Linux
Rheinwerk Computing
1282 S., 5., aktualisierte Auflage 2012, geb., mit 2 DVDs
49,90 Euro, ISBN 978-3-8362-1822-1
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.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

Rheinwerk Computing - Zum Seitenanfang

21.3 SSH nutzenZur nächsten Überschrift

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


Rheinwerk Computing - Zum Seitenanfang

21.3.1 Remote-LoginZur 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:

Listing 21.8 Kommandozeilen-ssh unter Unix

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

[zB]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.


Rheinwerk Computing - Zum Seitenanfang

21.3.2 Secure CopyZur nächsten ÜberschriftZur vorigen Überschrift

Oft muss man zwischen Servern auch Dateien austauschen, was ohne entsprechende Dienste recht aufwendig und schnell auch unsicher werden kann. Aus diesem Grund kann man für diese Aufgabe sinnvollerweise auch den SSH-Zugang nutzen, so dass 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. Dies 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:

Listing 21.9 Dateien holen

$ scp user@host:quelle ziel

Listing 21.10 Dateien senden

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

Genau wie cp kann auch scp rekursiv Verzeichnisse kopieren oder Wildcards wie »*« oder »?« nutzen, die dann auf dem entfernten Rechner aufgelöst werden.

Listing 21.11 Dateien kopieren mit Wildcards

$ 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
$

Rheinwerk Computing - Zum Seitenanfang

21.3.3 Authentifizierung über Public-Key-VerfahrenZur 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.

Listing 21.12 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 wäre das Äquivalent zu einem ganz normalen Benutzerkennwort, da der private Schlüssel mit ihr verschlüsselt wäre, 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

Es wurden also zwei wichtige Dateien erstellt:

  • ~/.ssh/id_rsa
    In dieser Datei liegt der private Schlüssel. Normalerweise ist er – sofern nichts anderes angegeben wurde – bei RSA und DSA 1024 Bit lang, kann aber durch die Option -b 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.
  • Listing 21.13 Der private Schlüssel bei RSA: id_rsa

    cvs@ploetner:~$ ls -l .ssh/id_rsa
    -rw------- 1 cvs cvs 887 Jul 3 11:28 .ssh/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 hängen wir mit ssh und scp den Inhalt von id_rsa.pub an die Datei authorized_keys im .ssh-Verzeichnis des Benutzeraccounts auf dem Server an, 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:

Listing 21.14 Den öffentlichen Schlüssel aktivieren

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

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

Da durchaus mehrere öffentliche Schlüssel autorisierte Schlüssel sein können, wollen wir die ~/.ssh/authorized_keys nicht einfach überschreiben, sondern wir 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:

Listing 21.15 Passwortloses Login über Public-Key-Authentifizierung

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

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. [Fn. 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.


Rheinwerk Computing - Zum Seitenanfang

21.3.4 Secure File TransferZur 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 Programm sftp, das Bestandteil der Open-SSH-Distribution ist. Einmal verbunden, kann man alle bereits vom normalen Konsolen-ftp her bekannten Befehle nutzen:

Listing 21.16 SFTP-Sitzung mit Public-Key-Authentication

$ 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

Rheinwerk Computing - Zum Seitenanfang

21.3.5 X11-ForwardingZur nächsten ÜberschriftZur vorigen Überschrift

Entfernte Fenster

Damit Sie Ihre Administration von Unix-Servern perfektionieren können, 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, [Fn. 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 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.


Rheinwerk Computing - Zum Seitenanfang

21.3.6 SSH-Port-ForwardingZur 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 eines Webbrowsers oder eines beliebigen anderen Programms 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.

Einen Tunnel richtet man unter Linux wie folgt ein:

Listing 21.16 Einen Tunnel aufbauen

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

Dieser Aufruf bewirkt Folgendes:

  • -f
    Nach dem erfolgreichen Verbindungsaufbau forkt [Fn. Mehr zum Thema forking erfahren Sie in Abschnitt fork]. sich SSH in den Hintergrund, so dass 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 Parameter -L angegebenen 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.

>> Zum Feedback-Formular
<< zurück
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Linux Handbuch






 Linux Handbuch


Zum Katalog: Linux Server






 Linux Server


Zum Katalog: Raspberry Pi






 Raspberry Pi


Zum Katalog: Ubuntu 14.04 LTS






 Ubuntu 14.04 LTS


Zum Katalog: Roboter bauen mit Arduino






 Roboter bauen
 mit Arduino


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2012
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.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de