Fachinformatik/ Sysadmin-Werkzeuge


Dieses Kapitel vermittelt eine Einführung in Werkzeuge der Systemadministration.

Secure Shell LoginBearbeiten

Um sich mittels Public-Key-Authentifizierungsverfahren bei einem entfernten Rechner anzumelden, geht man folgendermaßen vor:

ssh-keygenBearbeiten

  1. Mit ssh-keygen generiert man ein SSH-Schlüsselpaar, bestehend aus einem öffentlichen und einem privaten Schlüssel. Die Schlüssel werden standardmäßig in ~/.ssh/ abgelegt. Es empfiehlt sich, für den privaten Schlüssel ein Passwort zu vergeben, da der Besitz des privaten Schlüssels „Tor und Tür öffnet“. Das (meist) einmalig erzeugte Schlüsselpaar kann man zum Anmelden auf beliebig vielen entfernten Rechnern verwenden. Der private Schlüssel bleibt dabei stets auf dem lokalen Rechner.
  2. Anschließend kopiert man mit dem Befehl ssh-copy-id USER@REMOTE.HOST seinen öffentlichen Schlüssel (public key) auf den entfernten Rechner. Bei der ersten Verbindung zu einem Rechner wird zur Überprüfung des Host-Key-Fingerprints des entfernten Rechners aufgefordert. Außerhalb von Übungs- und Testszenarien sollte man diesen Fingerprint[1] über andere Kanäle in Erfahrung bringen (z.B. über den Hosting-Provider, …), um MITM-Angriffe weitgehend auszuschließen. Lokal wird der öffentliche Host-Key und damit die Identität des entfernten Rechners nach Bestätigung in ~/.ssh/known_hosts abgelegt.
  3. Nun kann man sich, gegebenenfalls nach dem Aufschließen des privaten Schlüssels, mit ssh USER@REMOTE.HOST ohne Passworteingabe bei allen entfernten Rechnern anmelden, denen mittels ssh-copy-id der eigene, öffentliche Schlüssel mitgeteilt wurde. Diesen findet man dann auf dem entfernten Rechner in der Datei ~/.ssh/authorized_keys.
  4. Im letzten Schritt (und nach erfolgreichem Test des Pubkey-Logins!) schaltet man die Anmeldung mittels Passwort beim entfernten Rechner ab indem man in der SSH-Konfiguration[2] PasswordAuthentication no setzt und den Dienst neu startet. Von nun an ist nur noch die Authentifizierung mit dem Pubkey-Verfahren möglich, was sich mittels ssh -o 'PubkeyAuthentication no' USER@REMOTE.HOST überprüfen lässt.

ssh-agentBearbeiten

Um sich per SSH Pubkey-Authentifizierung an einem entfernten Rechner anzumelden, benötigt man den privaten Schlüssel. Dieser ist meist durch ein Passwort geschützt, welches vor der Verwendung eingegeben werden muss.

Um sich die erneute Eingabe vor jeder Verwendung zu ersparen, gibt es den sogenannten SSH-Agent (man ssh-agent): Der SSH-Agent verwahrt ihm anvertraute Schlüssel bis zur Abmeldung (oder konfigurierbar für eine bestimmte Zeit). Viele Desktop-Umgebungen starten den SSH-Agent oder einen vergleichbaren Schlüsselverwaltungs-Dienst (Gnome Keyring, KWallet) bereits bei der Anmeldung. Manche Schlüsselverwaltungs-Dienste stellen z.T. auch den bzw. die Schlüssel bereits mit dem Login zur Verfügung.

Läuft der ssh-agent-Dienst im Hintergrund, so kann man mit dem Befehl ssh-add einen Schlüssel (nach Passworteingabe) zum Agent hinzufügen. Anschließend ist eine Passworteingabe zum Freischalten des Schlüssels für eine SSH-Pubkey Anmeldung nicht mehr erforderlich, da der ssh-agent den Schlüssel bereitstellt. Der Befehl ssh-add -l zeigt alle Schlüssel an, die der Agent verwaltet; ssh-add -D entfernt alle Schlüssel aus dem Agent (vergl. auch man ssh-add).

Software- und PaketmanagementBearbeiten

Kriterien zu Bewertung der Sicherheit bei der Installation von Software:


Paketverwaltung

Programmpaket

Projekt: Web-Anwendung NextcloudBearbeiten

KomponentenBearbeiten

 
Illustration eines LAMP-Stacks

Web-Technologien sind ein sehr dynamisches Feld der Informationstechnologie. Hier kann nur ein oberflächlicher und möglicherweise schon nicht mehr ganz aktueller Einblick gegeben werden.

Sehr oft bestehen Web-Anwendungen aus folgenden wesentlichen Komponenten:

  1. Webserver: Apache und nginx sind die bekanntesten Freien Open Source Webserver. Es gibt aber zahlreiche weitere.
  2. Serverseitiger Skript-Interpreter: Die Anwendung selbst ist meist in einer Skriptsprache wie PHP, Python, Perl, … geschrieben.
  3. Datenbank: Hier werden alle Daten der Anwendung gespeichert. Insbesondere MariaDB (früher MySQL) sind bei Webentwicklern sehr beliebte Datenbankmanagementsysteme.
  4. Die Webanwendung selbst.

Die ersten drei Komponenten installieren wir auf einem Server mit dem wir uns per SSH verbinden. Das resultierende System wird manchmal auch als LAMP-Stack bezeichnet, wobei die Anfangsbuchstaben z.T. je nach Variante unterschiedliche Bedeutung haben können.

Installation und Konfiguration der KomponentenBearbeiten

Webserver ApacheBearbeiten

apt install apache2

Infos unter: /usr/share/doc/apache2/

Test: Standard-Seite des Webservers abrufen, z.B. im Browser: http://localhost oder mit der IP-Adresse des Webservers http://127.0.0.1. Die Standard-Seite des Webservers liegt unter /var/www/html/ in der Datei index.html.

PHP-PaketeBearbeiten

apt install libapache2-mod-php php-gd php-mysql php-curl php-mbstring php-intl php-gmp php-bcmath php-imagick php-xml php-zip

Test: echo '<?php phpinfo(); ?>' | sudo tee /var/www/html/index.php, dann http://localhost/index.php aufrufen.

DBMS MariaDBBearbeiten

apt install mariadb-server

sudo mysql
[]
CREATE USER 'nextclouduser'@'localhost' IDENTIFIED BY '123';
CREATE DATABASE IF NOT EXISTS nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
GRANT ALL PRIVILEGES ON nextcloud.* TO 'nextclouduser'@'localhost';
FLUSH PRIVILEGES;
QUIT;
Test: mysql --user=nextclouduser --password=123 nextcloud
SHOW TABLES;
CREATE TABLE testtable(ID int);
SHOW TABLES;
DROP TABLE testtable;
QUIT;

NextcloudBearbeiten

wget https://download.nextcloud.com/server/releases/nextcloud-XX.tar.bz2        ## Nextcloud-Archiv
wget https://download.nextcloud.com/server/releases/nextcloud-XX.tar.bz2.sha512 ## zugehörige sha512 Check-Summe
wget https://download.nextcloud.com/server/releases/nextcloud-XX.tar.bz2.asc    ## zugehörige Signatur
wget https://nextcloud.com/nextcloud.asc                                        ## Public Key Nextcloud
Überprüfung Checksum und Signatur
 
Überprüfung der Signatur eines Dokuments oder auch Downloads:

Mit sha512sum --check nextcloud-XX.tar.bz2.sha512 kontrolliert man die Prüfsumme des Archives. Damit können Übertragungsfehler beim Download erkannt werden. Ein Angreifer aber, der auf dem Downloadserver das originale Archiv durch eine Version mit Hintertür ersetzen konnte, kann auch Dateien mit Prüfsummen ersetzen. Die Überprüfung der Check-Summe verhindert also nur technische Übertragungsfehler, nicht jedoch bösartige Eingriffe Dritter. Um diese zu verhindern, muss die Signatur geprüft werden. Hintergrundinformationen zur Signaturprüfung findet man u.a. auch unter https://www.gnupg.org/gph/de/manual/x275.html.

Zuerst muss der öffentliche Schlüssel von Nextcloud verfügbar gemacht werden. Dazu importiert man ihn in seinen „Schlüsselbund“:

gpg --import nextcloud.asc

Wichtig ist dabei, dass man den Schlüssel bzw. seinen Fingerprint mit anderen Quellen (Keyservern) abgleicht, sodass sichergestellt ist, dass man wirklich den richtigen Public Key besitzt. Anschließend kann man die Signatur verifizieren:

gpg --verify nextcloud-XX.tar.bz2.asc nextcloud-XX.tar.bz2

Nextcloud-Archiv auspacken
tar -xjvf nextcloud-XX.tar.bz2
sudo mv nextcloud /var/www/
sudo chown -R www-data:www-data /var/www/nextcloud/
sudo -e /etc/apache2/sites-available/nextcloud.conf  ## siehe Nextcloud Manual
sudo a2ensite nextcloud.conf
sudo systemctl reload apache2

Nextcloud anschließend einrichten durch Aufruf von http://localhost/nextcloud.


AnmerkungenBearbeiten

  1. Um den Fingerprint aus einem vorliegenden Host-Key zu generieren, verwendet man ssh-keygen -l -f /etc/ssh/HOSTKEY.pub.
  2. Üblicherweise in /etc/ssh/sshd_config oder besser, falls von sshd_config eingebunden, in /etc/ssh/sshd_config.d/local.conf.
  3. Vergl. irreführende, gefälschte „Homepage“ für KeePass




AufgabenBearbeiten

  1. Secure Shell: Host-Key Fingerprints und ~/.ssh/known_hosts
    1. Erzeuge mit for KEY in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -l -f "$KEY"; done Fingerprints aller Host-Keys. Melde dich mit ssh localhost lokal per ssh an und vergleiche den zu bestätigenden Fingerprint mit den zuvor generierten.
    2. Vergleiche deine ~/.ssh/known_hosts-Datei mit dem entsprechenden Host-Key in /etc/ssh/ des Rechners.
  2. Secure Shell: Public-Key Authentifizierung und ~/.ssh/authorized_keys
    1. Benenne auf einer Testmaschine, falls vorhanden, das Verzeichnis ~/.ssh/ um (mv ~/.ssh ~/.ssh_orig) und generiere ein SSH-Schlüsselpaar. Untersuche nun das neu generierte Verzeichnis ~/.ssh/. Dort sollte sich nun das erzeugte Schlüsselpaar befinden. Melde dich auf der selben Testmaschine als anderer Benutzer alice an. (Nutzer gegebenenfalls anlegen mit sudo adduser alice, anmelden mit su -l alice). Benenne das Verzeichnis ~/.ssh/ von alice ebenfalls um. Melde dich ab und führe ssh-copy-id alice@localhost aus. Überprüfe dein Verzeichnis ~/.ssh/ genauso wie das entsprechende Verzeichnis von alice.
    2. Vergleiche deinen Public-Key mit Einträgen in /home/alice/.ssh/authorized_keys.
    3. Lösche alle neu erzeugten .ssh/-Verzeichnisse und setze alles in den Originalzustand zurück (rm ~/.ssh && mv ~/.ssh_orig ~/.ssh).
  3. Nextcloud
    1. Ändere ein Bit des Nextcloud-Archives und berechne anschließend die Prüfsumme neu. Vergleiche mit der Prüfsumme des Originals.
    2. Lade eine Debian Installations-CD sowie die zugehörige Prüfsumme samt Signatur herunter. Führe eine vollständige Überprüfung des Downloads durch. Verwende dazu einen Public-Key aus /usr/share/keyrings/.
Lösung

Lösungsvorschlag
gpg --verify --keyring /usr/share/keyrings/debian-keyring.gpg SHA512SUMS.sign