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.

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.

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).

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.

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.

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.

Den folgenden Dialog hat jeder schon in seinem Browser gesehen: Sicherheitswarung des Mozilla Firefox beim Zugriff auf eine SSL verschlüsselte Seite Diese Warnung erscheint immer wenn der Administrator einer Website auf dem über SSL abgesicherten Server kein durch ein Trustcenter beglaubigtes Zertifikat hinterlegt hat oder dieses aus einem anderen Grund nicht gültig ist. Über das ‘Zertifikat’ (‘Certificate’ oder kurz ‘Cert’) prüft der Webbrowser, ob der Schlüssel des Servers unverändert und der Servername korrekt ist.