Diese Unterbrechungen sind im Umfeld der Shell recht üblich und werden dort über die Tastenkombination STRG+z durchgeführt. Damit wird der aktuelle Prozess im Job-Management angehalten und die Shell zur Eingabe von Befehlen freigegeben. Nach der Arbeit mit dem Befehl erfolgt eine Wiederaufnahme des Befehls über fg.

Bereits in dem letzten Artikel dieser Reihe haben wir die Datei authorized_keys kennengelernt und erfahren, wie man mit ihr einen Login ohne Kennworteingabe durchführt.

SSH-Agent

Solange wir, wie es empfohlen ist, auf den ‘privaten Schlüssel’ ein Kennwort legen, muss weiterhin bei jedem Login ein Kennwort eingegeben werden. Dies ist allerdings nicht das Kennwort des Benutzers auf der angesprochenen Maschine, sondern das Kennwort des lokal abgelegten ‘privaten Schlüssels’.

Die Entwickler des SSH-Protokolls haben für diesen Zweck einen Mechanismus eingebaut, über den ein Agent die Verwaltung der Schlüssel übernimmt und bei Zugriff auf einen Server dem ssh-Kommando nutzbare Schlüssel anbietet.

Nachdem sich der erste Teil der Reihe mit den grundlegenden Funktionen der ‘Secure SHell’ befasst hat, gehen wir nun einen Schritt weiter. Thema dieses Artikels ist die Anmeldung ohne Passwort per ‘Public Key Authentifizierung’.

Öffentlicher und privater Schlüssel

Die Idee eines Schlüssels ist hinreichend bekannt: Er gewährt Zugang zu einem System. Ein symmetrischer Schlüssel – also ein Schlüssel lediglich zum Verschlüsseln und Entschlüsseln – genügt unseren Ansprüchen an dieser Stelle allerdings nicht.

Nachdem wir in dem letzten Artikel dieser Reihe schon die einfache Nutzung der Datei authorized_keys kennengelernt haben, geht es in dieser Folge um weitere Einsatzmöglichkeiten.

Darüber hinaus sollen natürlich auch einige wichtige Parameter für die Konfiguration eines OpenSSH-Servers oder -Clients nicht fehlen.

Automatische Ausführung von Befehlen

Die einfachste Art, Befehle mit OpenSSH auf einer entfernten Maschine ausführen zu lassen, ist, den Befehl direkt auf der Kommandozeile anzugeben.

Um die Beispiele zu vereinfachen, gehen wir in der Folge davon aus, dass lokal ein ssh-agent mit einem ‘privaten Schlüssel’ läuft und der Benutzer auf dem Server in der Datei authorized_key den entsprechenden ‘öffentlichen Schlüssel’ hinterlegt hat.

Im Zusammenhang mit dem Heartbleed Bug in OpenSSL müssen die Privaten Schlüssel und Zertifikate der Server ausgetauscht werden, da es durch eine geschickte Nutzung des Bugs möglich ist den Privaten Schlüssel auszulesen und zur Entschlüsselung der per https übertragenen Daten genutzt werden.

Erster Schritt ist das Erzeugen eines neuen Privaten Schlüssels.

user@linux ~ $ openssl genrsa -out server.key 2048
Generating RSA private key, 2048 bit long modulus
......................................................+++
.................................................................+++
e is 65537 (0x10001)

Der so erstellte Private Schlüssel ist neu und damit unabhängig von dem bisher genutzten Privaten Schlüssel. Damit der Schlüssel genutzt werden kann wird nun das Zertifikat benötigt. Wir gehen davon aus, dass das Zertifikat von einem Trustcenter stammt und müssen daher eine Zertifikatanfrage (CSR) erstellen.

Egal ob bei dem ersten Aufsetzen oder bei einem späteren Erweitern eines Software Raids unter Linux, es muss immer auf zusammengehörenden Festplatten die gleichen Daten in die Partitionstabelle eingetragen sein. Die meisten Administratoren lösen das Problem mittels eines manuellen Aufrufs und lassen sich zunächst die alte Partitionstabelle ausgeben und tragen die Daten dann auf der neuen Festplatte ein.

tux@linux ~ $ sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 9E91EA64-7F47-4DE7-82E6-B162A0F22F83
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1          264192         2361343   1024.0 MiB  FD00  Linux RAID
   2         2361344      5860533134   2.7 TiB     FD00  Linux RAID
 128            2048          264191   128.0 MiB   EF02  BIOS boot partition

Diese Vorgehensweise lässt sich auf eine einzelne Festplatte ohne Probleme anwenden, birgt aber auch hier schon die Möglichkeit, dass sich der Administrator vertippt und falsche Daten eingibt.

Reguläre Ausdrücke

Um den Einsatz von z. B. sed effizienter zu gestalten, bedarf es der Kenntnisse über ‘Reguläre Ausdrücke’.

Hintergründe

Viele Linux-Kommandos kennen bei Filterfunktionen nicht nur einzelne Sonderzeichen, sondern auch sogenannte ‘Reguläre Ausdrücke’ (‘Regular Expressions’), auch als ‘RegEx’ oder ‘RegExp’ abgekürzt. Ein regulärer Ausdruck ist sozusagen ein Platzhalter, der (durchaus komplexe) Gruppen von Zeichenketten repräsentiert.

Zwar gibt es verschiedene Implementierungen der RegEx, doch sind die meisten kompatibel mit den ‘Perl Compatible Regular Expressions’ (PCRE). Auch das ‘Portable Operating System Interface’ (POSIX) definiert reguläre Ausdrücke; es ist den PCRE sehr ähnlich, unterscheidet aber etwa einfache und erweiterte RegEx. Welche Art der regulären Ausdrücke und in welchem Umfang sie ein Programm unterstützt, beschreibt dessen Dokumentation.

Spezialfall Regulärer Ausdruck?

Bisher haben wir in sed lediglich einfache Zeichenketten genutzt. Genau genommen ist eine Zeichenkette auch nichts anderes als ein Regulärer Ausdruck: Die Zeichenkette ist eine ‘Verkettung’ der einzelnen Buchstaben, Ziffern und Zeichen, aus denen sie besteht. Damit sind Reguläre Ausdrücke kein Sonderfall und ohne zusätzliche Optionen in sed nutzbar.

Folgender Dateiinhalt dient uns nun in der Datei zitronen.txt als Ausgangspunkt für unsere Experimente:

Auto-Fahrer fahren Zitronen!
Bier-Brauer brauen Autos.
Zitronen-Falter falten Biere?

Mit einer einfachen Ersetzung lässt sich hier zumindest ein Teil richtigstellen.

In diesem letzten Teil der Serie lernen wir weitere Funktionen von sed kennen.

Als Beispiel dient uns dieses Mal eine Konfigurationsdatei des DHCP-Servers. Sie ist unter dem Namen dhcpd.conf gespeichert und enthält die eine oder andere Unstimmigkeit.

option domain-name-servers 172.16.1.1;

subnet 172.16.1.0 netmask 255.255.255.0 {
      range 172.1.1.10 172.1.1.254;
   option broadcast-address 172.1.1.255;
 option routers 172.16.1.1;
    option time-servers 172.16.1.1;
   option lease-time 86400;
}

Im Artikel lassen wir sed den geänderten Dateiinhalt ausgeben, gehen aber davon aus, dass die Änderungen ebenfalls in die Datei geschrieben werden und damit beim nächsten Aufruf vorhanden sind. Dieses Verhalten erreichen wir mit der Kommandozeilenoption -i, die wir bereits im ersten Teil der Serie kennengelernt haben.

Bereits vor Aufkommen des Internets war es für Administratoren wichtig, über das Netzwerk – also ohne Zugriff auf eine direkt angeschlossene Tastatur – Server und Rechner zu warten. Die ersten hierfür entwickelten Protokolle waren ‘Telnet’ und ‘rsh’ (Remote Shell), die die Daten (inklusive Login-Daten) unverschlüsselt und damit – nach heutigen Maßstäben – unsicher übertragen.

Der Wunsch nach Sicherheit brachte die Entwickler dazu, ein Protokoll zu entwickeln, das sämtliche Daten inklusive Anmeldung verschlüsselt überträgt.