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.

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.

Mit den letzten Artikeln dieser Reihe haben wir mit openssl Zertifikate erzeugt und überprüft. In diesem Artikel konfigurieren wir unsere Webserver, um mit den Zertifikaten unsere Webseiten abzusichern.

Die im Artikel angesprochenen Cipher zur Verschlüsselung der Webseiten sind keine sicheren Cipher, sie dienen nur dazu die Positionen zu zeigen an denen Cipher eingefügt werden sollten. Es macht keinen Sinn innerhalb einer Dokumentation sichere Cipher vorzugeben. Daher möchten wir hier auf das BetterCrypto.org

Mit dem letzen Artikel dieser Reihe haben wir das Thema OpenSSL begonnen und uns Möglichkeiten angesehen, bestehende Zertifikate von Webseiten auf der Konsole zu überprüfen.

Um Webseiten mit einer SSL-Verschlüsselung versehen zu können, muss hierfür neben dem Schlüssel des Servers (‘Key’) ein Zertifikat (‘Cert’) erzeugt werden, das die Validität des Schlüssels bestätigt.

Selbstsigniertes Zertifikat

Die einfachste Art, ein solches Zertifikat zu erzeugen, ist, openssl die ganze Arbeit in einem Schritt erledigen zu lassen. Der folgende Aufruf erzeugt den Schlüssel und das Zertifikat in einem Arbeitsschritt. Der Schlüssel ist 2048 Bit lang, und das Zertifikat hat eine Gültigkeit von 365 Tagen.

Das Zentrale Tool für die Suche nach Dateien auf einem Linux System ist der Befehl find. Viele Anwender haben im ersten Moment Probleme mit find, da er sich nicht wie z. B. der Befehl locate direkt mit dem dem gesuchten Dateinamen aufrufen lässt.

Aber fangen wir vorne an. Der einfachste Aufruf ist der Befehl ohne Parameter.

tux@linux ~ $ find
.
./Videos
./Dokumente
./.xinitrc
./.bash_logout
./Downloads
./.bash_profile
./.xsession
./Bilder
./Bilder/Camping
./Bilder/Camping/GISL9002.CR2
./Bilder/GISL9000.CR2
./Bilder/GISL9001.CR2
./Desktop
./.bashrc
./.zshrc

In diesem Fall listet find alle Dateien des lokalen Verzeichnisses (.) inklusive der versteckten Dateien. Da es für versteckte Dateien in Linux Dateisystemen keine Attribute gibt, wurde festgelegt, dass alle Dateien deren erstes Zeichen ein . ist von Befehlen wie ls nicht angezeigt und damit versteckt werden.