SSH steht für “Secure Shell” und ist für den Remote Zugriff auf Computersysteme gedacht. Ursprünglich war die SSH eine Entwicklung für die Unix Systeme, die aber mit OpenSSH auch unter Mac, Windows, Linux und Android anzutreffen ist (es gibt aber auch eine Variante speziell für Unternehmen).
Der ursprünglichen Idee von SSH ging aber eine nicht so erfreuliche Sache voraus. Ein schlauer Mensch, der Entwickler/ Erfinder von SSH, wurde Opfer eines Hackerangriffes. Genauer gesagt wurden wohl Uni Server gehackt und damit auch die Daten des Entwicklers. Da hat sich dieser schlaue Mensch gedacht: “Naja, man könnte doch ein Programm entwickeln, das den Zugriff auf Systeme ermöglicht, aber alle übertragenen Daten verschlüsselt…”. So ungefähr war das wohl gewesen.
Damit ist bereits klar: SSH ermöglicht Datenverbindungen zwischen Systemen und verschlüsselt während der Übertragung die Daten. Man benötigt also ein Programm auf dem System, das den Zugriff erhalten möchte (SSH Client) und ein Programm, das den Zugriff ermöglicht (SSH Server).
Für den Verbindungsaufbau stellt der SSH Client eine Anfrage an den SSH Server (“Hallo! Bist du da?”; “Ja, ich bin hier! Das ist meine Authentifizierung..”). Bereits während dieses Verbindungsaufbaus wird bereits eine erste Sicherheitsüberprüfung durchgeführt. Zusätzlich zu dieser Überprüfung wird dann die zu verwendende Verschlüsselung festgelegt (mit der höchsten Stufe kann selbst eine Regierung nicht viel mitlesen; die Standardkonfiguration ist bereits okay). Die kommerzielle SSH Version unterstützt an dieser Stelle auch Zertifikate. Das macht OpenSSH auch, aber nicht ganz so gut. Aber natürlich müssen Client und Server die Verschlüsselung unterstützen! Wählt ihr eine sehr starke Verschlüsselung, dann kann es zu einer hohen Latenz führen oder/ und der Rechenaufwand wird sehr hoch. Letzteres kann bei einem Smartphone oder Notebook den Akku stark belasten. Außerdem gibt es da so eine Sache beim ersten Verbindungsaufbau! Der Client kennt den Server zu diesem Zeitpunkt noch nicht. Deswegen wird beim ersten Verbindungsaufbau zur Sicherheit ein “Fingerprint” erstellt. Anhand dieses “Fingerprint” kann die Originalität des Gegenüber gewährleistet werden. Den “Fingerprint” findet ihr dann in der Datei “known_hosts” und der wird dann bei späteren Verbindungen zur Prüfung abgefragt. Zusätzlich erfolgt später wärend des Datenaustausches auch eine Prüfung der Datenintegrität, d.h. Änderungen an den Datenpaketen können bemerkt werden.
Nach diesem Verbindungsaufbau erfolgt dann die eigentliche Authentifizierung am System, auf das wir Zugriff haben möchten. Diese Authentifizierung erfolgt mit Benutzername und Passwort (so wie es auch in dem System verwendet wird) oder die Authentifizierung erfolgt mit Schlüsseln. Ein Schlüsselpaar besteht aus einem privaten Key und einem öffentlichen Key. Der private Key verbleibt auf dem Server und der öffentliche wird dann auf die Geräte verteilt, die Zugriff haben möchten. Durch diese Schlüssel entfällt die Eingabe von Benutzername/ Passwort. Die Verwendung der Schlüssel macht die Verschlüsselung nicht besser! Das ist ein Mythos. Es ist lediglich eine andere Art der Anmeldung. Smartcards werden von der kommerziellen Variante unterstützt.
Aber es gibt durchaus auch Probleme mit dem Schlüsselverfahren. Ein echtes Problem entsteht zum Beispiel dann, wenn sehr viele Schlüssel verwendet werden. Es gibt zwar Programme, “Keymanager”, aber man kann trotzdem schnell den Überblick verlieren. Außerdem könnten die Schlüssel von nicht erwünschten Programmen oder durch eine Sicherheitslücke ausgelesen werden. Bei einer Passwortanmeldung ist das nur schwerer möglich (Stichwort Keylogger).
Welche Daten können jetzt verschlüsselt werden? Theoretisch alle (ja, ich ignoriere an dieser Stelle das OSI Modell, um die Sache nicht zu komplizieren). Der Haken ist: Wenn auf der Gegenseite kein SSH Server aktiv ist, dann funktioniert es nicht. Das schränkt den Anwendungsbereich etwas ein. Sinn macht es zum Beispiel, wenn ihr in den Urlaub fahrt und von unterwegs den Zugriff auf euer Heimnetzwerk möchtet bzw. vom Homeoffice aus auf das Unternehmensnetzwerk zugreifen müsst. Oder wenn ihr einfach nur in eurem Netzwerk auf einen anderen PC Zugriff haben wollt. Die Fritz!Boxen unterstützen das übrigens nicht mehr! Okay, so wirklich wurde das noch nie unterstützt... Bei den Fritz!Boxen habt ihr nur die Option mit den Fritz!Apps oder über den Webbrowser Zugriff auf die Box zu erlangen. Oder mit VPN bzw. Wireguard kann der Zugriff auf das Netzwerk erfolgen, in dem dann ein PC mit SSH Server aktiv ist.
Weitere Infos zu SSH findet ihr auf der Webseite: https://www.ssh.com/academy/ssh. Dort findet ihr im Menü die SSH Akademie mit Themen zur Konfiguration usw.. In den Handbüchern der von euch verwendeten Linux Distribution sollte auch etwas zu finden sein, alternativ in der Manpage (hat nichts mit Geschlechtern zu tun, sondern kommt vom Englisch Manual). Speziell für den Raspberry PI, aber auch übertragbar auf andere Linuxe, gibt es hier eine Kurzanleitung: https://www.raspberrypi.com/documentation/computers/remote-access.html#remote-access.
Bei Windows müsst ihr euch durch die Windows Hilfeseiten wühlen (am besten die Google Suche verwenden oder die Microsoft KI im Bing mal fragen; vielleicht wird es kein Rezept zum Brotbacken..). Aber es ist ähnlich Linux. Ihr müsst das OpenSSH aber erst als “optionales Feature” installieren. Die Konfigurationsdateien für den Client findet ihr im Userordner unter “.ssh”. Die Standardkonfiguration für den Server liegt etwas versteckter unter Programdata. Anleitung unter: https://learn.microsoft.com/de-de/windows-server/administration/openssh/openssh_install_firstuse?tabs=gui.
Und für MacOS steht etwas hier: https://support.apple.com/de-de/guide/mac-help/mchlp1066/mac. Typisch MacOS ist bei denen die Sache mit ein paar Mausklicks erledigt. Für speziellere Konfigurationen muss man dann trotzdem die Konfigurationsdateien bearbeiten. Im Zusammenhang mit der Powershell findet man bei Microsoft auch ein paar zusätzliche Infos zur Konfiguration unter MacOS.
