SSH mit mehreren Schlüsseln nutzen

Normalerweise erzeugt man einen privaten und einen öffentlichen Teil seines SSH-Schlüssels, hinterlegt den öffentlichen Teil auf den entsprechenden Servern und loggt sich mit diesen dort ein. Nun kann es aber durchaus vorkommen, dass man mit unterschiedlichen Schlüsselpaaren arbeiten muss um sich auf verschiedenen Servern einzuloggen. Zur Lösung dieses Problems existieren zwei Herangehensweisen, welche beide mit der SSH-Konfigurationsdatei arbeiten. Die Konfigurationsdatei ist im Home-Verzeichnis der Nutzers unter .ssh/config zu finden ist. Bei der ersten Möglichkeit werden die entsprechenden Schlüssel in der Konfigurationsdatei hinterlegt:

IdentityFile ~/.ssh/id_rsa
IdentityFile ~/.ssh/id_rsa_production
IdentityFile ~/.ssh/id_rsa_test
IdentityFile ~/.ssh/id_rsa_integration

Damit werden bei einem Login auf einem Server die Schlüssel der Reihe nach durchprobiert. Bei der zweiten Möglichkeit wird ein Host pro Server konfiguriert:

Host production production.example.com
    HostName production.example.com
    User root
    IdentityFile ~/.ssh/id_rsa_production
    

Host test test.example.com
    HostName test.example.com
    User root
    IdentityFile ~/.ssh/id_rsa_test

Host integration integration.example.com
    HostName integration.example.com
    User root
    IdentityFile ~/.ssh/id_rsa_integration

In der Konfiguration des Hosts befinden sich neben dem Host auch die zu nutzende Schlüsseldatei. Als weiteren Vorteil kann man die SSH-Verbindung nun über den definierten Kurznamen aufrufen:

ssh production

Dabei wird die Verbindung mit der definierten Schlüsseldatei aufgebaut, so dass ein durchprobieren der unterschiedlichen Schlüssel vermieden wird.

Z-Wave im Home Assistant aktivieren

Die freie Heimautomationslösung Home Assistant verfügt unter anderem über eine Unterstützung des Z-Wave-Protokolls. Möchte man die Unterstützung für Z-Wave hinzufügen, so muss theoretisch nur die passende Konfiguration hinterlegt werden. In der Praxis gibt es allerdings ein paar Kleinigkeiten mehr zu beachten. Hier wird davon ausgegangen, dass Hass.io als Betriebssystem für Home Assistant genutzt wird. Bevor man mit der Konfiguration beginnt, benötigt man Gerät um sich mit dem Z-Wave-Netzwerk zu verbinden. Empfehlenswert ist hier z.B. der Aeotec Z-Stick Series 5. Daneben existieren eine Reihe weiterere Controller, welche vom Home Assistant unterstützt werden.

Die Anzeige der installierten Add-Ons für Hass.io

Im ersten Schritt sollten im Hass.io-Menü die Add-Ons für SSH und Samba aktiviert werden. Dazu wird die Weboberfläche über die URL:

http://hassio.local:8123

aufgerufen. Nach der Installation der Add-Ons ist es wichtig, diese über den Button Start direkt zu aktivieren. Nachdem das Samba-Add-On aktiviert wurde, kann über die Freigabe der Hass.io-Instanz im Ordner config die Konfiguration eingesehen werden. Wichtig ist hierbei die Datei configuration.yaml. An das Ende dieser Datei fügt man folgende Konfiguration ein:

# Z-Wave
zwave:
  usb_path: /dev/ttyACM0

Damit ist die Konfiguration für Z-Wave abgeschlossen. Um das korrekte Gerät für den Z-Wave-Stick zu ermitteln, loggen wir uns per SSH auf der Hass.io-Instanz ein:

ssh

und geben dort den Befehl:

hassio host hardware

Dieser Befehl zeigt uns, welche Hardware an dem Raspberry Pi angeschlossen ist. Eine Ausgabe könnte dann z.B. so aussehen:

{
  "serial": [
    "/dev/ttyAMA0"
  ],
  "input": [],
  "disk": [],
  "gpio": [
    "gpiochip0",
    "gpiochip100"
  ],
  "audio": {
    "0": {
      "name": "bcm2835 - bcm2835 ALSA",
      "type": "ALSA",
      "devices": {
        "0": "digital audio playback",
        "1": "digital audio playback"
      }
    }
  }
}

Nachdem der Befehl eingegeben wurde, wird der Z-Wave-Stick an den Raspberry Pi angeschlossen:

{
  "serial": [
    "/dev/ttyACM0",
    "/dev/ttyAMA0"
  ],
  "input": [],
  "disk": [],
  "gpio": [
    "gpiochip0",
    "gpiochip100"
  ],
  "audio": {
    "0": {
      "name": "bcm2835 - bcm2835 ALSA",
      "type": "ALSA",
      "devices": {
        "0": "digital audio playback",
        "1": "digital audio playback"
      }
    }
  }
}

Bei dem neuen Gerät im Abschnitt serial handelt es sich um den Z-Wave-Stick. Seine Gerätebezeichnung übernehmen wir in die Konfiguration. Wird der Stick ab- und später wieder angesteckt, so kann sich die Gerätebezeichnung ändern, so dass dieser Prozess anschließend wiederholt werden muss. Im Falle einer falsch konfigurierten Gerätebezeichnung erhält man auf dem Dashboard eine Fehlermeldung das Z-Wave nicht angesprochen werden konnte. Nachdem der Stick angesteckt ist und die Konfiguration entsprechend erweitert wurde, muss Home Assistant neugestartet werden. Dazu wählt man im Menü Einstellungen den Punkt General und wählt dort im Bereich Server Managment den Button Restart. Nach knapp einer Minute sollte die Weboberfläche wieder verfügbar und Z-Wave aktiv sein.

SSH-Deamon auf dem Raspberry Pi aktivieren

Seit November 2016 wird die Standarddistribution für den Raspberry Pi namens Raspbian, eine auf Debian basierende Distribution, mit deaktiviertem SSH-Server ausgeliefert. Was aus Sicherheitsgründen lobenswert ist hat natürlich für die schnelle Inbetriebnahme eines Raspberry Pi einige Nachteile.

Ein Raspberry Pi 3

Allerdings existieren zwei relativ einfache Wege den SSH-Dienst wieder zu aktivieren. Die erste Möglichkeit ist, nachdem das Image auf die für den Raspberry Pi verwendete SD- bzw. microSD-Karte gebracht wurde, auf der boot-Partion der Karte eine Datei mit dem Namen ssh anzulegen. Ist diese Datei vorhanden, so wird der SSH-Serverdienst beim Start des Raspberry Pi aktiviert.

Die entsprechende Option in raspi-config

Läuft der Raspberry Pi bereits und man hat Zugriff auf diesen kann der SSH-Dienst mittels des Konfigurationstools raspi-config aktiviert werden. Nachdem dieses gestartet wurde, wird dort der Punkt Interfacing Options ausgewählt. Dort findet sich der Unterpunkt P2 SSH. Wählt man diesen Unterpunkt an, wird nach der Bestätigung der Sicherheitsabfrage der SSH-Dienst aktiviert.

Nach der Sicherheitsabfrage wird der SSH-Dienst aktiviert

Nun kann sich (wenn das Raspbian noch in der Standardkonfiguration läuft) mittels:

ssh

und dem Passwort raspberry eingeloggt werden. Da man dieses Passwort nach der Ersteinrichtung ändern sollte, erhält man beim Login über ssh folgenden Hinweis:

SSH is enabled and the default password for the 'pi' user has not been changed.
This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password.

Dieses Hinweis sollte befolgt werden und das Passwort mit dem Kommando:

passwd

geändert werden. Anschließend kann der Raspberry Pi ohne Probleme mit dem SSH-Dienst genutzt werden. In der offiziellen Raspberry Pi Dokumentation wird weiterführend auf das Thema eingegangen. Dort wird neben der eigentlichen Einrichtung des SSH-Dienstes auch die Nutzung verschiedener Clients in den unterschiedlichen Betriebssystemen besprochen.

Einführung in die uncomplicated firewall

Wenn man unter Linux eingehende und abgehende Pakete kontrollieren, umleiten oder blockieren möchte, so kann man für diese Aufgabe iptables nutzen. Das Problem an iptables ist das es relativ kompliziert in der Anwendung ist.

Damit man hier nicht im Regen steht, gibt es (neben vieler anderer Firewall-Lösungen für Linux) die uncomplicated firewall kurz ufw. Technisch gesehen handelt es sich bei ufw um ein Frontend für iptables. Seit der Version 8.04 (Hardy Hedon) ist ufw ein Bestandteil der Ubuntu-Distribution. Neben Ubuntu ist ufw unter anderem auch für Debian verfügbar. Installiert werden kann ufw mittels des Befehls:

apt-get install ufw

Standardmäßig ist ufw deaktiviert, so das die Installation im ersten Schritt keinerlei Auswirkungen hat. Den aktuellen Status sowie die definierten Regeln können dabei mittels:

ufw status

eingesehen werden. Das könnte dann z.B. so aussehen:

Status: Aktiv

Zu                   Aktion      Von
--                   ------      ---
8080/tcp             DENY        Anywhere                                
22/tcp               ALLOW       Anywhere                            
22/tcp (v6)          ALLOW       Anywhere (v6)

Ist der Status auf inaktiv gesetzt, so muss ufw erst mit dem Befehl:

ufw enable

aktiviert werden. Hierbei muss man beachten das eine unbedachte Aktivierung von ufw dazu führen kann das man sich aus dem Rechner aussperrt. Dies liegt daran das am Anfang keinerlei Regeln definiert sind – so werden Pakete an Port 22 ignoriert; dies führt dazu das keine Verbindung per SSH möglich ist. Um dem vorzubeugen sollte eine Regel für SSH definiert werden, bevor ufw aktiviert wird:

ufw allow 22/tcp

Bei dieser Schreibweise handelt es sich um die vereinfachte Form zum Anlegen einer Regel. Neben allow, sind dabei auch die Werte deny und reject möglich. Während bei allow die Pakete passieren können, werden sie bei deny blockiert – im Gegensatz dazu wird bei reject der Absender darüber informiert das die Pakete abgelehnt wurden. Möchte man komplexere Regeln definieren nutzt man ufw nach folgendem Schema:

ufw allow proto tcp from any to 127.0.0.1 port 1234

Damit werden alle Verbindungen per TCP von beliebigen IP-Adressen an die spezifizierte IP-Adresse weitergeleitet. Als Port wird als Eingangs- und Zielport Port 1234 genutzt. Die Regeln welche ufw verwaltet werden in drei Dateien gespeichert:

/etc/ufw/before.rules
/var/lib/ufw/user.rules
/etc/ufw/after.rules

Abgearbeitet werden die Regeln in der Reihenfolge wie oben angegeben – somit könnte eine Regel in der user.rules-Datei definiert sein, welche anschließend von einer anderen Regel in der after.rules-Datei überschrieben wird. Die selbst definierten Regeln sind dabei in der user.rules zu finden. Neben dem Anlegen ist es natürlich auch möglich Regeln wieder zu löschen. Für obige SSH-Regel würde das dabei so aussehen:

ufw delete allow 22/tcp

Daneben ist es möglich ufw auf die Standardeinstellungen zu setzen. Dazu dient der Befehl:

ufw reset

Alle Regeln werden dabei auf die Standardeinstellungen zurückgesetzt. Für die bestehenden Regeln wird ein Backup im Verzeichnis /etc/ufw/ angelegt. Möchte man ufw wieder deaktivieren, so nutzt man den Befehl:

ufw disable

Beim beschriebenen reset-Befehl wird ufw ebenfalls deaktiviert. Damit sind die grundlegenden Konfigurationsschritte erklärt – für die weitergehende Konfiguration empfiehlt sich der entsprechende Artikel bei ubuntuusers.

Zertifikate für ejabberd erzeugen

Von Zeit zu Zeit laufen Zertifikate ab. So auch in meinem Fall, als sich mein XMPP Client beschwerte, das dass Server-Zertifikat nicht mehr gültig ist. Um für ejabberd neue Zertifikate zu erzeugen, sollte man sich auf seinem Server einloggen und dort folgenden Zeilen eingeben:

openssl req -newkey rsa:2048 -keyout ejabberd.pem -nodes -x509 -days 365 -out ejabberd.cer
cat ejabberd.cer >> ejabberd.pem
cp ejabberd.pem /etc/ejabberd/ejabberd.pem

Anschließend kann der Dienst mittels:

service ejabberd restart

neugestartet werden. Das neue Zertifikat ist damit aktiv und der Dienst kann wieder genutzt werden.