Dieser Heftschwerpunkt geht bei allen berücksichtigten Diensten davon aus, dass diese bereits installiert sind, aktiv genutzt werden und der Leser Einsatzzweck und Basisfunktionen des Serverdienstes kennt. Beim SSH-Server (Paket „openssh-server“), der dieses Special startet, steht der Nutzwert außer Frage. Die Tipps erklären einige Optionen, die nicht offensichtlich auf der Hand liegen und den Servereinsatz optimieren. 

SSH-Verbindungen einhängen 

SSH hat sein eigenes Dateiprotokoll SFTP, das alle erwachsenen Linux-Dateimanager (Nautilus, Dolphin, Nemo, Thunar und andere) beherrschen: Mit der Syntax 

sftp://sepp@192.168.178.10:22/srv/Data/

in der Adresszeile eines Dateimanagers (Strg-L) haben Sie – nach Kennworteingabe – umstandslos die Dateien des entfernten SSH-Servers vor sich. Die Adresseingabe scheint äußerst umständlich, allerdings können die Portangabe (22) und das Zielverzeichnis entfallen, falls Standardport 22 genutzt wird und das gesamte Dateisystem angezeigt werden soll: 

sftp://sepp@192.168.178.10

Solche Adresseingabe wird aber komplett entbehrlich, sobald Sie die Verbindung je nach Dateimanager per Drag & Drop oder über die Option „Lesezeichen“ in der Navigation ablegen. Dann genügt künftig ein Mausklick. Dieser komfortable Weg über den Dateimanager eignet sich multifunktional – zum Abspielen von Musik- oder Filmmedien ebenso wie für Datensicherungen oder zum Editieren von Konfigurationsdateien.

Es gibt aber Situationen, wo die Netzwerkkompetenz grafischer Dateimanager nicht hilft. Wenn der SSH-Client selbst ein terminaladministrierter SSH-Server ist, gibt es keinen grafischen Dateimanager. Ebenso kann es sein, dass auf einem grafischen Desktop ein Terminalplayer wie moc („Music on Console“) bevorzugt wird. Um Dateien auf einem SSH-Server so zu öffnen, als lägen sie auf der lokalen Festplatte, eignet sich das winzige Tool sshfs. Unter Ubuntu & Co. installieren Sie das Tool mit 

sudo apt install sshfs 

und können dann mit einem Terminalbefehl (Beispiel)

sshfs sepp@192.168.178.10:/srv/Archiv ~/Archiv/

beliebige Verzeichnisse des SSH-Servers im Home-Verzeichnis zugänglich machen. Der Zielordner („~/Archiv“) muss existieren. 

SSH-Anmeldung: Schlüssel statt Kennwort

Komfort und Sicherheit sind normalerweise indirekt proportional: Mehr Komfort bedeutet fast immer geringere Sicherheit. Die SSH-Anmeldung per Schlüssel ist eine Ausnahme. Der Zugang wird ohne Kennworteingabe deutlich bequemer und obendrein sicherer. Damit ist die Schlüsselmethode sowohl für öffentlich erreichbare Server (höhere Sicherheit) als auch für Homeserver mit geringem Sicherheitsanspruch uneingeschränkt zu empfehlen (einfacher Zutritt).

Mit folgendem Befehl erstellen Sie den Schlüssel auf allen Linux-PCs, die auf den SSH-Server zugreifen sollen:

ssh-keygen

Dieser Befehl wird gerne komplizierter vorgeschlagen – mit Angabe der Verschlüsselungsmethode („-t) und Schlüssellänge („-b“). Nötig ist das nicht, zumal der hier genutzte Standard (ED25519) als sicherer gilt als das oft empfohlene RSA. Bestätigen Sie alle Abfragen des Befehls einfach durch Eingabetaste. 

Damit entstehen im Home-Verzeichnis des aktuellen Benutzers unter „~/.ssh“ die zwei Dateien „id_ed25519“ und „id_ed25519.pub“ (der private und der öffentliche Schlüssel der asymmetrischen Verschlüsselung). 

Der öffentliche Schlüssel in der Datei mit der Erweiterung „.pub“ muss nun noch zum SSH-Server transportiert werden, und zwar unter dem Konto, mit dem man sich künftig anmelden will. Das ließe sich auch manuell erledigen, wird aber mit diesem speziellen Befehl vereinfacht (Beispiel): 

ssh-copy-id -i ~/.ssh/id_ed25519.pub sepp@192.168.178.10

Mit Parameter „-i“ müssen Sie die lokale, vorher erstellte, öffentliche Schlüsseldatei angeben. Der eigentliche Schlüssel landet dann auf dem Server im angegebenen Konto unter „~/.ssh/authorized_keys“ und ab sofort ist die Anmeldung mit (Beispiel) 

ssh sepp@192.168.178.10

ohne Passwort möglich. Das ist nicht nur bequemer, sondern bietet zusätzliche Vorteile: Sie können etwa automatische Rsync-Sicherungen per Cronjob einrichten oder Software auf dem Server mit 

ssh -X sepp@192.168.178.10 synaptic 

ohne Passworteingabe direkt auf dem Server starten und sich auf dem Rechner anzeigen lassen, vor dem Sie sitzen. 

Konten oder IP-Adressen ausschließen

Standardmäßig erlaubt SSH allen auf dem System vorhandenen Konten den Zugang. Das kann selbst auf einem unkritischen lokalen Heimserver zu großzügig sein, zumal jeder Samba-Berechtigte in der Regel mit demselben Kennwort auch das SSH-Terminal erreichen kann. Der SSH-Server bietet aber mehrere Optionen, um Konten oder auch Geräte vom Zugriff auszuschließen. Der Weg führt in die zentrale Konfigurationsdatei „/etc/ssh/sshd_config“. 

Eine erste Möglichkeit ist es, bestimmte Konten (des Servers) zu verbieten. Der Konfigurationseintrag dafür lautet „DenyUsers“ an beliebiger Stelle der Datei: 

DenyUsers anna berta claus

Meistens ist es aber einfacher, den umgekehrten Weg zu gehen und mit „Allow­Users“ von vornherein nur eines oder wenige SSH-berechtigte Konten zu definieren:

AllowUsers sepp

Dies schließt alle anderen aus und erlaubt nur noch genau diesem Systemkonto die SSH-Anmeldung. Das angegebene Konto muss auf dem Server unbedingt existieren, andernfalls wäre der SSH-Zugang versperrt und der Fehler nur noch am lokalen System zu korrigieren. Wenn nur ein Konto erlaubt ist, sollte dieses sudo-Recht besitzen, damit es die Serververwaltung übernehmen kann.

Für „AllowUsers“ gibt es zusätzlich einen interessanten IP-Filter: Folgende Anweisung erlaubt die SSH-Anmeldung eines einzigen Kontos nur noch von einer einzigen IP-Adresse (einem Gerät): 

AllowUsers sepp@192.168.178.5

Das Konto „sepp“ bezieht sich wie immer bei SSH auf ein Systemkonto auf dem SSH-Server. Die IP-Adresse ist hingegen diejenige eines zugreifenden Clients. Etwas offener wäre folgende Anweisung in der „/etc/ssh/sshd_config“ (eine Zeile!):

AllowUsers *@192.168.178.2 sepp@192.168.178.5 sepp@192.168.178.8

Von der IP „2“ des Adressraums (der Admin-Rechner?) darf sich jedes Konto anmelden, das Konto „sepp“ außerdem von den Geräten mit IP „5“ und „8“. 

Konfigurationsänderungen,Test und Neustart

Änderungen an der SSH-Konfiguration werden erst dann eingelesen und gültig, nachdem der Dienst mit 

sudo systemctl restart ssh 

neu gestartet wird. Dabei darf nichts schiefgehen. Fehler führen schlimmstenfalls dazu, dass der SSH-Dienst anschließend nicht mehr läuft und alle ausgesperrt sind. Vor dem Neustart des SSH-Dienstes empfiehlt sich daher mit 

sudo sshd -t

ein Test der Syntax der Datei „/etc/ssh/sshd_config“. Sollte die Datei Fehler enthalten, dann werden die Zeilennummer und die fehlerhafte Anweisung angezeigt. Dies schützt allerdings nur vor Tippfehlern und falsch geschriebenen Anweisungen. Wer sich durch fehlerhafte „AllowUsers“- oder „DenyUsers“-Zeilen oder durch erzwungene Schlüsselanmeldung (ohne erfolgten Schlüsselaustausch) ausschließt, kann das dann nicht mehr per SSH-Fernzugriff, sondern nur noch am lokalen SSH-Serversystem korrigieren.