Die wohl am häufigsten genutzte Methode zur Administration eines Raspberry Pis ist Secure Shell (SSH). In den aktuellen Raspbian Versionen ist SSH bereits integriert und muss lediglich aktiviert werden.

Im aktuellen Raspbian Buster (basiert auf Debian 10 Stable) kommt OpenSSH in Version 7.9p1 zum Einsatz. Die Standard-Konfiguration ist in puncto Sicherheit zwar in Ordnung, aber mit einigen Handgriffen lässt sich die Administrationsschnittstelle deutlich besser absichern. Damit steigt die Hürde für potenzielle Angreifer deutlich. Dies ist vor allem wichtig, wenn euer Pi aus dem Internet erreichbar ist.

Grundlagen und hilfreiche Befehle

OpenSSH besteht aus zwei Teilen: Dem Server Daemon (sshd) und dem Client (ssh). In diesem Tutorial widme ich mich ausschließlich sshd. Die Konfigurationsdatei des Servers befindet sich hier:

/etc/ssh/sshd_config

Der Status des sshd-Daemons kann mit folgendem Befehl abgefragt werden:

systemctl status ssh.service
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2019-11-02 08:44:33 GMT; 2 weeks 3 days ago

Damit könnt ihr sicherstellen, dass sshd automatisch startet (enabled) und gerade läuft (active (running)). Des Weiteren seht ihr auch die 10 letzten Logeinträge.

Mit folgendem Befehl könnt ihr die aktiven SSH-Sessions einsehen:

ss -n -o state established '( dport = :22 or sport = :22 )'

Bei Änderungen an der Server-Konfiguration empfehle ich diese vor dem Neustart des Dienstes zu prüfen. Damit könnt ihr Syntaxfehler und Probleme mit ungültigen Einstellungen in “/etc/ssh/sshd_config” verhindern:

sudo sshd -t

Zum Anwenden der Änderungen empfehle ich sshd folgendermaßen neuzustarten. Mit dieser Variante besteht die größte Chance, dass offene Remote-Sessions nicht geschlossen werden.

sudo systemctl reload ssh.service

SSH-Server: Einstellungen

Wie oben bereits erwähnt lassen sich die Einstellungen in der Datei “/etc/ssh/sshd_config” anpassen und sind nach einem Neustart von sshd aktiv. Einige Einstellungen sind bereits standardmäßig deaktiviert. Diese sind in der Config-Datei auskommentiert. Es schadet jedoch nicht diese noch einmal zu überprüfen.
Über die Protokoll-Version müssen wir uns keine Sorgen machen, da ab OpenSSH 7.0 SSH Version  1 bereits beim Kompilieren deaktiviert wird.
Standardmäßig hört der Server auf Port 22. Dieser kann geändert werden, um beispielsweise die Anzahl der Angriffe zu verringern. Einen Sicherheitsgewinn gibt es meiner Meinung nach nicht.
Wenn der Server mehrere IP-Adressen besitzt, kann über “ListenAdress” eingeschränkt werden, auf welcher IP eine Verbindung akzeptiert werden soll.

Port22
ListenAddress 192.168.10.10
#ListenAddress ::

Da wir auf unserem Raspberry keine grafische Benutzeroberfläche haben, können wir das X11-Protokoll getrost deaktivieren. Davon abgesehen wird vom Server ein Rückkanal zum Client geöffnet, was sicherheitstechnisch nicht ganz unbedenklich ist.

X11Forwarding no

Mittels .rhosts-Datei kann der Zugriff von fremden Systemen lediglich anhand der IP-Adresse erlaubt werden. Dieser Zugriff ist heutzutage nicht mehr üblich und daher standardmäßig deaktiviert.

IgnoreRhosts yes

Useraccounts ohne Passwort dürfen sich nicht via SSH anmelden. Auch diese Option ist per Default deaktiviert.

PermitEmptyPasswords no

Eine direkte Anmeldung mit dem Account “root” sollte in der Regel nicht erlaubt werden (PermitRootLogin no). Falls dies aus bestimmten Gründen dennoch notwendig sein sollte, ist die Option “prohibit-password” in Ordnung. Diese ist standardmäßig gesetzt und erlaubt nur eine Public-Key-Authentifizierung mit dem root Account.

PermitRootLogin prohibit-password

Die maximale Zahl der Anmeldeversuche pro User sind standardmäßig auf 6 gesetzt. Ich würde empfehlen den Wert weiter zu verringern, beispielsweise auf 3.

MaxAuthTries 3

Inaktive Sessions können nach einer bestimmten Zeit automatisch beendet werden. Mit “ClientAliveInterval” wird festgelegt, nach wie vielen Sekunden Inaktivität der Server eine Nachricht an den Client sendet. “ClientAliveCountMax” ist die Anzahl, wie oft dies der Server wiederholt, bis der Client getrennt wird. In meinem Beispiel oben wird der Client nach 15 Minuten getrennt.

ClientAliveInterval 300
ClientAliveCountMax 3

Normalerweise erfolgt die Anmeldung am Server mit Username und Passwort. Eine bessere Alternative ist die Public-Key-Authentifizierung. Diese ist bereits standardmäßig erlaubt.

PubkeyAuthentication yes

Zur Einrichtung muss auf dem Client zunächst ein neues Schlüsselpaar generiert werden. Wählt hier “Ed25519”, sofern nichts gravierendes dagegenspricht. Unter Windows könnt ihr dies prima mit PuTTYGen erledigen. Ab Windows 10 1809 kann dies auch direkt via PowerShell oder der Eingabeaufforderung erledigt werden. Unter Linux nutzt ihr ssh-keygen. Der Einsatz einer Passphrase ist zwar optional, aber ich empfehle ein starkes Passwort zu verwenden, um den Key vor Missbrauch zu schützen.

ssh-keygen -o -a 100 -t ed25519 -f ~/.ssh/id_ed25519

Im nächsten Schritt muss der Public Key auf dem Server eingetragen werden. PuTTYGen stellt euch den String bereit, den ihr in die “authorized_keys” kopieren müsst.

ssh pi@192.168.10.10
mkdir ~/.ssh
chmod 700 ~/.ssh
vi ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Unter Linux geht dies mit “ssh-copy-id” etwas einfacher.

ssh-copy-id -i ~/.ssh/id_ed25519.pub pi@192.168.10.10

Abschließend solltet ihr prüfen, ob die Anmeldung via Public-Key-Authentifizierung funktioniert. Falls ja, könnt ihr nun die Passwort-Anmeldung an eurem SSH-Server deaktivieren.

PasswordAuthentication no
ChallengeResponseAuthentication no

SSH-Server: Cipher-Suites und Verschlüsselungsalgorithmen

Zur Prüfung, welche Cipher-Suites und Verschlüsselungsalgorithmen euer OpenSSH-Server anbietet, eignet sich das Python-Script “ssh-audit”:

cd ~
wget https://github.com/jtesta/ssh-audit/releases/download/v2.4.0/ssh-audit-2.4.0.tar.gz
tar -xvzf ssh-audit-2.4.0.tar.gz
~/ssh-audit-2.4.0/ssh-audit.py 192.168.10.10

Alternativ könnt ihr auch Nmap dazu verwenden:

nmap -p22 -n -sV --script ssh2-enum-algos 192.168.10.10

Schauen wir uns zunächst die Algorithmen für den Schlüsseltausch an. Falls Curve25519 nicht ausreichend ist, könnt ihr noch “diffie-hellman-group-exchange-sha256” hinzufügen.

# Allow only secure key exchange algorithms
KexAlgorithms curve25519-sha256@libssh.org

Danach folgen die Schlüssel bzw. Algorithmen für die Authentifizierung. Hier solltet ihr alle vorhandenen Host-Schlüssel löschen und neu generieren.

cd /etc/ssh
sudo rm ssh_host_*key*
sudo ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N "" < /dev/null
sudo ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key -N "" < /dev/null

Anschließend könnt ihr in eure “sshd_config” folgendes eintragen:

# Allow only secure server authentication algorithms
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKeyAlgorithms ssh-ed25519,ssh-rsa

Als nächstes nehmen wir uns den symmetrischen kryptographischen (Ciphers) sowie MAC (Message Authentication Code) Algorithmen an. Folgendes gilt aktuell als sicher:

# Allow only secure symmetric ciphers
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com

# Allow only secure message authentication codes
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

Prüft zur Sicherheit, dass ihr vor dem Neustart von sshd eine Verbindung habt, damit ihr euch im Notfall nicht den Zugang zu eurem Raspberry absägt.

Einen guten Artikel mit weiteren Details über die einzelnen Cipher-Suites und Verschlüsselungsalgorithmen findet ihr hier: https://stribika.github.io/2015/01/04/secure-secure-shell.html