Ich gehe hier mal davon aus, dass man so etwa weiß, was eine IP-Adresse, ein Port, ein Host und ein Client ist.
Ich beschreibe nur den Weg, wie man SSH mit einer Shell nutzt. Auf andere Clients wie z. Bsp. Putty gehe ich hier nicht ein. Ich denke, wenn man diese Seite hier gelesen hat, weiß man auch, wie man solche Clients einsetzen kann. Das Grundprinzip ist das Selbe.
Raspberry Pis sind nun nicht gerade der Renner was Netzwerktechnologie betrifft. Aber zum Erlernen solcher Sachen sind sie besser geeignet als teure Geräte, wo sich vielleicht noch sensible Daten darauf befinden.
Dieser Artikel ist auch für RaspiOS gültig, da es auf Debian basiert.
Bei der Grundkonfiguration des Systems haben wir ja schon SSH genutzt. Ich möchte hier auf weitere Einzelheiten in Bezug auf Sicherheit und Funktionsweise eingehen.
Ich gehe hier aber nicht bis in das letzte Detail. Diese Sachen sind für Privatanwender gedacht und nicht für Netzwerktechnik eines großen Konzerns.
Mein Freund Kay hat sich mal wieder ein Raspberry Pi zugelegt. Da werden Kabel angeschlossen, Tastatur, Maus und Bildschirm. Was für ein Kabelsalat in dem Zimmer.
"Hey Ulf, du machst doch auch immer wieder was am Raspi. Wieso hast du keine Tastatur oder Bildschirm?. Du musst doch sehen, was du machst." "Hey Kay, ich nutze SSH und bediene das Raspi von meinem Laptop."
SSH steht für Security Shell. Diese Technologie ermöglicht es, einen entfernten Rechner so zu bedienen als wenn man davor sitzt. Sehr oft werden Servergeräte über SSH verwaltet, da sie keine grafische Oberfläche, Bildschirm und Tastatur besitzen und sich irgendwo auf der Welt befinden.
Es wird eine kryptografisch verschlüsselte Verbindung zum entfernten Rechner (Host) aufgebaut, dort ein Programm ausgeführt, deren Rückgabe man erhält, und danach wird die Verbindung beendet.
Hä? Ein Programm und dann Verbindung Schluss? Ich hatte doch schon tagelange Verbindungen.
In den meisten Fällen wird auf dem Host eine Shell also ein Programm (z.Bsp. /usr/bin/dash) gestartet. Innerhalb dieser Shell führt man weitere Programme aus. Das "Elternprogramm" ist die Shell. Meldet man sich ab, wird die Shell und anschließend die Verbindung beendet.
Es ist auch möglich, grafische Programme über SSH auf einem Host auszuführen. Allerdings ist es nicht (so einfach) möglich, den gesamten Desktop auf den Client zu bekommen, wie das bei VNC-Verbindungen der Fall ist.
SSH macht hier nicht sein "Eigending" sondern ist an feste Regeln gebunden, die in den RFCs ab etwa 4500 definiert sind.
Eine SSH-Verbindung besteht aus 3 Schichten.
Die unterste Schicht enthält Informationen über die verbundenen Geräte, die natürlich verschlüsselt ausgetauscht werden. Jeder Server und jeder Client besitzt einen sogenannten Fingerabdruck. Einige kennen es vielleicht schon: Beim Aufbau einer aller ersten Verbindung zu einem Host kommt auf dem Client eine Frage, ob man diesem Host vertraut, was man mit "yes" beantwortet. Der Fingerabdruck wird lokal auf dem Client unter ~/.ssh/known_hosts gespeichert.
Die mittlere Schicht enthält Benutzerdaten also etwa Benutzername und Passwort oder Schlüsseldaten. Diese Daten werden von der unteren Schicht "getunnelt".
Mit der obersten Schicht erfolgt die eigentliche, von den anderen Schichten "getunnelte", Datenübertragung. Hier ist es sogar möglich, einen weiteren TCP-Socket hineinzupacken. Mehr dazu später.
Damit Kay eine SSH-Verbindung zu seinem Raspi bekommen kann, muss der SSH-Server auf dem Raspi gestartet sein. In Debian ist das der Fall. Bei RaspiOS kann es sein, dass er mittels sudo raspi-config gestartet werden muss.
Kay ist schon ganz aufgeregt. Das Raspi hat Netzwerk. Kann er es nun von seinem Laptop bedienen?
Dazu gibt er folgendes Komanndo in einer Shell auf seinem Laptop ein:
ssh kay@raspi001
kay ist sein Benutzername auf dem Raspi und raspi001 ist der Hostname des Raspis.
Und schon meckert sein Laptop, toll:
The authenticity of host .....:22 can't be established. ECDSA key fingerprint is SHA256:..... Are you sure you want to continue connecting?
Kay ist nun etwas verunsichert. Er weiß nicht, dass das bereits ein kleiner Erfolg ist. Es ist eine Verbindung auf Port 22 vorhanden, die sich in der unteren Schicht befindet.
Da es die erste SSH-Verbindung zwischen beiden Geräten ist, kennen sich diese noch nicht. Weil sie sich aber kennenlernen sollen, muss Kay diese Frage mit yes beantworten.
Und schon kommt die nächste Warnung von Kays Laptop:
Warning: Permanently added ..... to the list of known hosts.
Kay verliert langsam die Geduld. Was bedeutet denn das schon wieder? Diese Meldung besagt, dass der Fingerprint des Raspis auf seinem Laptop in der Datei ~/.ssh/known_hosts abgespeichert wurde.
Nun wird Kay nach dem seinem Passwort auf dem Raspi gefragt, welches er im Blindflug eingibt. Wir befinden uns also in der mittleren Schicht der Verbindung.
Hat Kay sein Passwort richtig eingegeben, startet der SSH-Server auf dem Raspi eine Shell, mit der Kay nun von seinem Laptop aus arbeiten kann. Die obere Schicht der Verbindung ist aktiv.
Ist Kay fertig, kann er sich mit STRG-d bzw. exit abmelden. Die Shell wird beendet und die Verbindung auch.
Erstellt Kay später eine neue Verbindung, sind die ganzen Warnungen weg. Die Geräte kennen sich bereits. Das zaubert dem Kay dann doch ein kleines Lächeln ins Gesicht.
Weitere Beispiele
Wenn Kay sein Benutzername auf seinem Laptop und auf dem Raspi gleich sind, kann er diesen weglassen:
ssh raspi001
Ändert Kay seine Serverkonfiguration so, um nicht den Standardport 22 sondern den Port 2222 zu nutzen, muss er das beim Verbinden mit angeben:
ssh -p 2222 kay@raspi001
Kennt Kay die IP-Adresse des Raspis, kann er die DNS-Anfrage am Router umgehen. Beispiel:
ssh kay@192.168.2.154
Das funktioniert auch mittels IPV6-Adressierung. Beispiel:
ssh kay@fd00::ba27:ebff:f1a4:c5a3
Möchte Kay nur die Uhrzeit vom Raspi wissen, nutzt er den Befehl:
ssh kay@raspi001 date
Kay kann auch mehrere Komanndos auf seinem Raspi ausführen lassen:
ssh kay@raspi001 "date; hostname; sleep 2; date"
Kay ist begeistert. Irgendwann hat er aber mehrere Raspis und will diese einfach mit SSH von seinem Laptop erreichen. Äh wie war der Hostname und welcher Port? Wie das Kay auf seinem Laptop regeln kann beschreibe ich später. Kay ist ungeduldig und will sein Raspi auch von draußen (Internet) erreichen.
Das Internet ist ein feindliches Netzwerk. Auch wenn es ursprünglich anders gedacht war, hat es sich so entwickelt. Der Grund dafür ist der Mensch.
Ich werde hier nicht beschreiben, wie man ein Port auf einem Router öffnet. Jeder ist für sein Heimnetz selbst verantwortlich.
Kay arbeitet beruflich als Servicetechniker und ist viel unterwegs. Sein Laptop nimmt er immer mit. Das wäre doch schön, wenn er weltweit auf sein Rasperry Pi zugreifen könnte.
"Ach, ich brauche doch nur den Port 22 auf dem Router zu meinem Raspi aufmachen. Dann geht es doch von draußen." Ja, es geht, aber.
Szenario 1: Die bösen Bots
Bots sind kleine Skripte bzw. Programme, die irgendwo laufen, um etwas automatisch zu erledigen.
Gerade in Indien und China aber auch anderswo laufen solche Bots, die IP-Adressen abscannen. Antwortet eine IP-Adresse, wird der Portscanner gestartet.
Irgendwann wird Kay sein Raspi auf Port 22 gefunden. "Aha, SSH. Starten wir den Passwortgenerator."
Szenario 2: Der gute Kollege
Kay ist auf Seviceeinsatz. Wie er es eher selten erlebt, ist dort ein freundliche Mensch, der stets hilsbereit ist und sich für die Arbeit interessiert.
Gemeinsam mit Kay versucht er, das geforderte Ziel zu erreichen. Besser kann es einem Servicetechniker nicht erwischen.
Kay verbindet sich 3 mal an einem Tag mit seinem Raspi. Vielleicht sogar ungewollt bekommt der freundliche Kollege mit, dass Kay da immer "2204Claudia!" eingibt.
Während Kay beim Abendessen sitzt, ist der freundliche Kollege von zu Hause aus auf Kays Raspi unterwegs.
Szenario 3: Der Mensch selbst
Ich übertreibe jetzt mal. Kay hat sich mit seinem Raspi verbunden und ist da sogar als root unterwegs.
Auf der Arbeit macht er eine kurze Pause und trinkt mal schnell einen Kaffee. Er vergisst sich abzumelden.
Eine andere Person gibt auf Kays Laptop rm -rf / ein und schon ist Kay sein Raspi komplett gelöscht.
Egal ob Kay eine tolle gesicherte Verbindung zu seinem Raspi hat, das System ist angreifbar.
Was könnte Kay tun, um die Sicherheit diesbezüglich zu verbessern?
Der gesunde Menschenverstand
Haben ist besser als Brauchen. Aber stimmt das hier auch? Braucht Kay unbedingt eine Fernverbindung zu seinem Raspi?
Kay sollte eine Verbindung nur so lange offen halten, wie er es benötigt. Hier geht es nicht um 5 Minuten. Aber eine Verbindung über 8 Stunden ist unverhältnismäßig, wenn Kay diese nur einmal für 5 Minuten benötigt.
Kay sollte sich für seine Pausen überlegen, was er da mit seinem Laptop macht. Sicherlich sind auf dem Laptop selbst Daten darauf, die niemanden etwas angehen.
Den Rat, ein gutes Passwort mit ... und ... zu wählen, gebe ich Kay hier nicht. Darüber wird viel Sinn und Unsinn in den Medien verbreitet. Der Titel des Absatz lautet "Der gesunde Menschenverstand" und nicht "Wie mache ich mir das Leben schwer". Letztendlich können Passwörter immer irgendwie erraten oder gestohlen werden.
Public-Key-Authentifizierung
Kay ist schon der Meinung, dass ein Anmelden per SSH nur mit einem Passwort etwas unsicher sein könnte. Deshalb interessiert er sich für die Public-Key-Authetifizierung. Aber was ist das und wie funktioniert sie?
Bei diesem Verfahren wird ein Schlüsselpaar erzeugt. Dieses besteht aus einem privaten Schlüssel (der Haustürschlüssel) und dem öffentlichen Schlüssel (das Schlüsselloch in der Haustür). Der private Schlüssel befindet sich auf Kay seinem Laptop. Der öffentliche Schlüssel muss demzufolge auf dem Raspi sein.
Verbindet sich Kay nun mit seinem Raspi, sendet er die Info in der mittleren Schicht mit, dass die Verbindung mittels seinem privaten Schlüssels erfolgt. Das Raspi prüft mit dem öffentlichen Schlüssel alle Daten, die von Kay kommen, auf Integrität, welche nun in der obersten Schicht der Verbindung liegen.
Hinweis zum Schlüsselloch: Aus einem öffentlichen Schlüssel lässt sich (bisher) kein privater Schlüssel ermitteln. Deshalb kann keine andere Person, die auf Kays Raspi unterwegs ist, Kays privaten Schlüssel ermitteln.
Es gibt verschiedene Typen von Schlüssel, die sich in der Art der Kryptografie unterscheiden. Empfohlen werden die Typen ECDSA und ED25519. Der Typ RSA gilt auch als sehr sicher, hat aber eine Größe von 4 bis 8 kB, was bei jeder Anmeldung übertragen und ausgewertet müsste.
Wie erstellt Kay ein Schlüsselpaar? Dazu nutzt er folgendes Komanndo auf seinem Laptop:
ssh-keygen -t ed25519
Es erfolgt eine Frage, unter welchen Dateinamen der Schlüssel abgespeichert werden soll. Dazu sollte bei Kay /home/kay/.ssh/id_ed25519 angeboten werden, was Kay mit Enter übernimmt.
Nun erfolgt die Frage nach einer gewünschten Passphrase. Eine Passphrase sorgt dafür, dass, wenn Kays privater Schlüssel gestohlen wird, niemand etwas damit anfangen kann (2-Komponenten-Authentifizierung). Deshalb empfehle ich nicht, die Passphrase leer zu lassen.
Nachdem er nun 2 mal seine 2204Claudia! eingegeben hat, kommt ein komisches Bildchen und das Schlüsselpaar ist erzeugt.
Ach der Kay, der will es immer genau wissen. Um den privaten Schlüssel anzuzeigen nutzt er:
cat ~/.ssh/id_ed25519
Und den Inhalt des öffentlichen Schlüssels liest er mit:
cat ~/.ssh/id_ed25519.pub
Nun muss der öffentliche Schlüssel auf Kays Raspberry Pi. Dazu nutzt er das Shell-Skript /usr/bin/ssh-copy-id, was sich jeder ansehen kann:
ssh-copy-id -i ~/.ssh/id_ed25519.pub kay@raspi001
Hierbei wird eine SSH-Verbindung erstellt, der Inhalt der Datei übertragen und auf Kays Rasperry Pi in der Datei ~/.ssh/authorized_keys hinzugefügt und die Verbindung beendet.
Sollte Kay das Script ssh-copy-id nicht besitzen, kann er den öffentlichen Schlüssel mit einem Shell-Komanndo übertragen:
Nun möchte Kay mal testen, ob eine Verbindung mit Public-Key-Authentifizierung klappt. Dazu nutzt er:
ssh -i ~/.ssh/id_ed25519 kay@raspi001
Es erfolgt die Abfrage nach der Passphrase und dann ist er auf dem Raspi unterwegs.
Dort bleibt er auch. Schließlich will er, dass sich in Zukunft niemand mehr mit Passwort einloggen kann. Dazu editiert er auf dem Raspi die Datei /etc/ssh/sshd_config mit Root-Rechten folgenden Eintrag:
#PasswordAuthentication yes
PasswordAuthentication no
Damit die Änderung sofort wirksam wird, startet Kay nun den SSH-Server neu:
sudo systemctl restart sshd.service
Was hat der Kay nun:
Niemand kann sich mit Passwort auf Kay seinem Raspi anmelden. Szenario 1 ist vom Tisch, die Bots können sich tot probieren.
Szenario 2 ist auch vom Tisch, denn der nette Kollege besitzt nicht die Datei ~/.ssh/id_ed25519 von Kays Laptop. Und selbst, wenn er sie hätte, bräuchte er zusätzlich noch die Passphrase. Sehr unwahrscheinlich.
Bei Szenario 3 kann man nur auf Kay seinem gesunden Menschenverstand hoffen.
Weitere Nutzer sollen sich verbinden können
Kay möchte es, dass sich seine Claudia auch mit dem Raspi über SSH verbinden darf.
"Alles klar." denkt sich Kay. "Ich kopiere meinen Schlüssel auf Claudias Laptop und gebe ihr die Passphrase." Nein Kay! Bitte nicht! Da kann er gleich die Haustür offen stehen lassen. Wenn Kay sein Portomonaise der Claudia gibt, weiß er nie, wieviel Geld noch drin sein wird, wenn er es wiederbekommt.
Claudia sollte selbst ein Schlüsselpaar erzeugen. Kay kann am Raspi mal kurz die Passwortauthentifikation zulassen, damit Claudia den öffentlichen Schlüssel auf dem Raspi anlegen kann.
Kays öffentlicher Schlüssel befindet sich ja unter /home/kay/.ssh/authorized_keys. Claudias öffentlicher Schlüssel wird unter /home/claudia/.ssh/authorized_keys angelegt. Somit bleiben die angelegten Benutzerrechte gewahrt.
Wenn Kay dann mal mehrere Raspis hat
Kay hat sich weitere Raspberry Pis zugelegt. Er entscheidet sich für das Public-Key-Verfahren, um Verbindungen zu den Geräten herstellen zu können.
Kann er seinen gleichen Schlüssel auf den anderen Geräten nutzen (Generalschlüssel)? Oder sollte er vielleicht für jedes Gerät ein extra Schlüsselpaar erzeugen (viele Zimmerschlüssel)?
Das muss Kay für sich selbst entscheiden. Das erste, was er bedenken sollte, ist: Was kann passieren, wenn ein Schlüssel gestohlen wird?
Für Kay ist es ganz klar, ein extra Schlüssel für jedes Gerät ist sicherer. In der Praxis gibt es Menschen, die ein paar Hundert Geräte über SSH verwalten. Da entsteht ein Schlüsselsalat, wo man selbst keinen Durchblick mehr hat. Vielleicht ist es da eine gute Alternative, einen Schlüssel für einen "Bereich an Geräten" zu verwenden.
Ich hoffe, ich konnte Kay seine Ungeduld etwas stillen und möchte zu den Grundlagen zurückkehren.
Kay hat inzwischen 28 Raspberry Pis am Laufen. In seinem Chaos lauscht jeder SSH-Server auf einem anderen Port. Und natürlich hat er für jedes Gerät einen extra Schlüssel angelegt.
Claudia und Kay verbringen 3 Wochen einen schönen verdienten Urlaub.
Nun ist Kay wieder zu Hause und möchte sich mit Raspi 17 verbinden.
Oder war es doch ein anderer Port oder ein anderer Schlüssel? Kay hat mal wieder sein Gedächtnis verloren, was ich von ihm kenne. Viel Spaß beim Suchen.
Kay kann sich auf seinem Laptop die Datei ~/.ssh/config anlegen, wo er diese Informationen einmal eintragen muss. Das sieht dann etwa so aus:
# Das erste Raspberry Pi
Host raspi001
HostName raspi001.kay.internet.de
User kay
Port 22
IdentityFile ~/.ssh/id_ed25519
Compression no
# Raspberry Pi 2 mit lila Gehäuse, nur Heimnetz
Host raspi002
HostName raspi002
User kay
Port 2223
IdentityFile ~/.ssh/kay02_ed25519
Compression no
.....
# Raspi 17 hinter dem Kühlschrank
Host raspi017
HostName raspi017.kay.internet.de
User kay
Port 2237
IdentityFile ~/.ssh/schluessel4_1_ed25519
Compression no
Ich denke mal, der Code ist selbsterklärend. Bei einem Raspberry Pi lohnt es sich nicht, die Datenkompression zu nutzen. Da hat es mehr zu tun, als die Daten einfach nur zu versenden. Die Kompression nutzt nur bei schlechter Netzwerkverbindung.
So Kay, jetzt schnappst du dir deine Claudia und machst noch mal 3 Wochen Urlaub. Danach nutzt du folgendes Komanndo:
Zwei Tools hat der Kay schon genutzt, ssh-keygen und ssh-copy-id. Nun möchte er wissen, ob es noch weitere gibt.
Alle folgenden Tools nutzen SSH als Grundbaustein. Somit sind erzeugte Schlüssel und Einträge in ~/.ssh/config gültig.
scp
Auf einem Vortrag bei der KielLux 2022 wurde gesagt, dass man scp nicht mehr verwenden sollte, weil es fehlerhaft sein könnte. Genauere Gründe wurden nicht genannt. Dafür konnte ich bisher keine weiteren Beweise finden und nutze scp weiter.
Vielleicht eine Notiz von mir: SSH wurde ursprünglich nicht dazu entwickelt, große Datenmengen zu übertragen. Es sollte die Möglichkeit geben, ein Programm auf einem entfernten Gerät auf sicherer Weise auszuführen. Überträgt man große Datenmengen per SSH, müssen diese verschlüsselt, übertragen und entschlüsselt werden. Oft wird da nicht die volle Netzwerkgeschwindigkeit genutzt, da das Ver- oder Entschlüsseln den Flaschenhals bildet.
Scp ist die OpenSSH-Variante zu cp (copy). Damit können einzelne oder mehrer Dateien von einem Gerät auf das andere Gerät mittels einer SSH-Verbindung kopiert werden.
Um eine Datei vom Raspi auf den Laptop zu kopieren nutzt Kay folgendes Komanndo:
Aber bei Kay muss es ja immer ein ganzes Verzeichnis mit allen Unterverzeichnissen sein:
ssh kay@raspi001 "tar -cf - ~/Dokumente/claudia/" | tar -xf -
Was bei den letzten 3 Beispielen besser sein soll als scp zu verwenden, kann ich Kay nicht sagen. Alle Beispiele nutzen SSH als Grundlage für die Übertragung.
sftp
Sftp ist die OpenSSH-Variante zu ftp. Damit können ebenfalls Dateien über eine SSH-Verbindung übertragen und verwaltet werden.
Sicherlich werden die meisten sftp nicht im Terminal nutzen, weswegen ich nur kurz darauf eingehe. Aber der Kay ist ja neugierig.
sftp kay@raspi001:/home/kay/
Nun kann sich Kay mit help die verfügbaren Komanndos anzeigen, ein paar davon ausführen und das Programm mit exit beenden.
Sftp wird aber dennoch häufig genutzt. So sind die meisten grafischen Dateimanagerprogramme in der Lage, sftp anzuwenden. Dazu öffnet Kay seinen Dateimanager und gibt folgendes in der Adresszeile ein:
sftp://kay@raspi001/home/kay/
Allerdings muss Kay hier folgendes wissen: Um mit den Dateien arbeiten (öffnen, verändern) zu können, muss er diese erst lokal auf seinen Laptop kopieren, wie das bei FTP auch der Fall ist.
sshfs
Auch hier wurde bei der KielLux 2022 ohne Angaben von Gründen empfohlen, sshfs nicht zu benutzen. Hier kann ich mir vielleicht vorstellen, woran das liegt.
Mit sshfs hat Kay die Möglichkeit, ein Verzeichnis auf seinem Raspberry Pi auf seinem Laptop einzuhängen. Nun kann er mit den Dateien arbeiten, als würden sie sich lokal auf dem Laptop befinden.
Für den Einhängevorgang sind keine Root-Rechte notwendig, da sshfs die Software fuse nutzt.
Kay erstellt sich ein Verzeichnis und hängt dort das Heimatverzeichnis des Raspberry Pis ein.
Nun kann er mit den Daten auf dem Raspi arbeiten. Ist Kay fertig, hängt er das Verzeichnis wieder aus.
fusermount -u ~/raspi/
Ich denke mal, hier liegt der Hase im Pfeffer. Viele werden das Aushängen aus Bequemlichkeit oder Vergesslichkeit nicht immer machen. Wenn man etwas braucht, tut man es sofort. Wird es dann nicht mehr benötigt, kann es erst mal liegen bleiben. Und Kay lässt sein Laptop rumliegen, geht einen Kaffee trinken und die anderen... Hier sind wir doch wieder beim gesunden Menschenverstand, oder?
Da SSH als sehr sicher und zuverlässig gilt, nutzen viele andere Programme, die nicht zur OpenSSH-Familie gehören, diese Möglichkeit für Verbindungen. Ich erwähnte schon die Dateimanager bei sftp.
Sehr oft wird zum Beispiel rsync -e ssh ..... genutzt, um Backups zu aktualisieren. Kay hat aber ein Raspberry Pi mit einer SD-Karte, was keine gute Backuplösung wäre. Er kann sich aber die Manpages zu solchen Programmen ansehen.
Kay hat inzwischen 2 Raspberry Pi. Auf raspi001 befinden sich Daten, die er gegebenenfalls bei einem Serviceeinsatz benötigt. Auf raspi002 befinden sich ausschließlich private Daten, die niemanden etwas angehen. Diese Daten sind nur für seine Claudia unf für ihn.
Vorbildlich, wie Kay nun mal ist, hat er die Firewall an seinem Router zu raspi002 zugemacht, damit das Gerät nicht von draußen erreichbar ist. Lediglich aus seinem Heimnetz ist raspi002 über SSH zu erreichen.
Kay ist wieder auf Serviceeinsatz. Da er sich nichts merken kann, braucht er wieder, eigentlich wie immer, weitere Informationen. "Kein Problem, das habe ich auf dem Raspi." denkt sich Kay und erstellt eine SSH-Verbindung.
kay@laptop:~$ ssh kay@raspi001
Er sucht dort die entsprechende Datei und macht folgende Feststellung: "Mist, das habe ich auf raspi002! Prima, Firewall ist zu, toll! Da habe ich mir die Haustür selbst zugeschmissen ohne den Schlüssel mitzunehmen." Hat Kay eine Chance, an die Daten zu kommen?
Hat er. Er erstellt eine SSH-Verbindung von raspi001 zu raspi002.
kay@raspi001:~$ ssh kay@raspi002
Diese 2. Verbindung befindet sich nur in seinem Heimnetz. Er findet seine gesuchte private Datei und erhält die entsprechenden Informationen.
Und an dieser Stelle überlege ich jetzt, ob ich hier aufhöre. Schließlich wurde dem Kay gezeigt, wie er seine eigene Firewall umgehen kann. Das soll hier aber keine Hacker-Seite werden.
Man kann hier erkennen, welche Gefahren lauern, wenn nur ein einzigstes Gerät aus dem Internet erreichbar ist.
Wenn es um Internet geht, sind Menschen vorsichtig und konfigurieren den Router entsprechend. Über den Datenverkehr im Heimnetz macht man sich eher weniger Gedanken.
An dieser Stelle kann ich Kay nur empfehlen, auch wenn die Verbindung von raspi001 zu raspi002 im Heimnetz stattfindet, die Public-Key-Authentifizierung zu nutzen, weil hier der Benutzer eine große Rolle spielt. Und von automatisches Verbinden nach dem Booten sollte er die Finger lassen, auch wenn es mittels ssh-agent relativ sicher ist. Das führt hier zu weit.
Grundsätzlich ist Kay zu empfehlen, längere SSH-Ketten über mehrere Geräte nicht zu nutzen, soweit es anderweitig möglich ist. Wenn Daten z. Bsp. über 6 Geräte übertragen werden, müssen 6 Geräte diese Daten verschlüsseln, senden, empfangen und entschlüsseln. Energie- und netzwerktechnisch ist das Unsinn.
Ich möchte einen SSH-Tunnel nicht mit einer VPN-Verbindung gleichsetzen, obwohl es den Anschein hat. Gerade wenn die Tunnel nicht richtig erstellt werden, könnten diese mit einer VPN-Verbindung in Sachen Datensicherheit nicht mithalten.
Man sollte auch wissen, dass Proxies die übertragenen Daten nicht lesen können. Aber sie können die Menge an Daten "mitzählen".
So Kay, jetzt fangen wir mal an, unser Gehirn einzuschalten. Die Kindergartenspiele bis hier sind ja nicht dein Anspruch.
Die Richtung ist entscheidend
Möchte man einen Netzwerktunnel nutzen, muss man wissen, dass die Richtung entscheidend ist.
Die Richtung geht immer vom Client zum Server. Es mag verwirren, da doch Daten in beide Richtungen übertragen werden können.
Kay verwirrt das nun auch. Kay trete einfach mal ein Schritt zurück.
Ein Client ist ein Schüler, der eine Frage hat. Der Server ist der Lehrer, der die Antwort gibt.
Die Frage des Schülers (Client) geht vorwärts zum Lehrer (Server). Die Antwort des Lehrers (Server) geht rückwärts zum Schüler (Client).
Aber wenn der Schüler (Client) den Lehrer (Server) nicht anspricht, kann der Lehrer (Server) keine Antwort dem Schüler (Client) geben. Darum geht es.
Mittels SSH können wir Tunnel vorwärts (-L) und rückwärts (-R) bauen. Vielleicht ein kleines Beispiel, wo der Kay wieder her halten muss.
Kay kann von seinem Laptop aus vorwärts einen Tunnel bauen, der bis zu seinem Router geht. Kay kann aber nicht auf seinem Router den Tunnel zu seinem Raspi verlängern, weil der Router sowas nicht kann. Aber Kay kann auf seinem Raspi einen Rückwärtstunnel zum Router erstellen, womit er nun einen gesamten Tunnel vom Laptop bis raspi001 hat.
Einen SSH-Tunnel für SSH
Ich gebe es zu, in der Praxis ist dieses Beispiel einfach Unsinn, da SSH bereits eine sichere Verbindung erstellt. Kay ist halt neugierig und möchte es probieren, dazu ist ein Raspberry Pi prima geeignet.
Kay macht sein Laptop an, öffnet eine Shell und gibt folgendes ein:
ssh -L 2222:raspi001:22 kay@raspi001
"Toll" denkt sich Kay. "Nun habe ich wieder eine Shell auf dem Raspberry Pi. Was soll der Unsinn?"
Kay, dann öffne doch mal eine 2. Shell und gib mal folgendes ein:
ssh -p 2222 kay@localhost
"Na noch besser, eine SSH-Verbindung zu mir selbst. Ich habe gar keinen Server auf dem Laptop laufen. Moment mal, ich bin auf meinem Raspberry Pi!"
In der ersten Shell hat sich Kay über SSH einen Tunnel gebaut. Der Eingang ist auf seinem Laptop Port 2222. Der Ausgang ist auf seinem Raspberry Pi Port 22, wo sein SSH-Server lauscht.
In der zweiten Shell erstellt Kay eine SSH-Verbindung zum Eingang des Tunnels. Der Tunnel leitet die Daten weiter zum Ausgang.
Kay hat so eine SSH-Verbindung innerhalb einer SSH-Verbindung erstellt.
Kurze Anmerkung zu genutzten Ports: Die Ports 0 bis 1023 sind für das System reserviert. Deshalb kann Kay als Eingang nur Ports ab 1024 bis 65533 nutzen.
Kay hat auch noch sein raspi002, wo kein Port am Router offen ist. Er könnte folgendes probieren:
ssh -L 2222:raspi002:22 kay@raspi001
Er sollte nun in der zweiten Shell raspi002 erreichen. Aber hier sei gesagt, dass sich der Tunnelausgang auf raspi001 befindet. Die Übertragung von raspi001 zu raspi002 ist dann nur eine normale SSH-Verbindung im Heimnetz.
Einen SSH-Tunnel zum privaten Intranet
Vielleicht macht dieses Beispiel mehr Sinn, obwohl es nur eine Wiederholung ist.
Kay kann eine SSH-Verbindung zu raspi001 herstellen. Er hat auch raspi002, wo nur private Daten sind. Aus dem Internet gibt es keinen Zugang darauf. Wirklich?
Auf raspi002 läuft ein Webserver für ein privates Intranet, der HTML-Dateien und kleine Webanwendungen für zu Hause bereit stellt. Dieser lauscht auf Port 8080 und kann nur HTTP, da er nur aus dem Heimnetz angesprochen wird.
Kay ist wieder unterwegs, startet sein Laptop und probiert folgendes:
ssh -L 8080:raspi002:8080 kay@raspi001
Nun öffnet er seinen Webbrowser und gibt folgende Adresse ein:
http://localhost:8080/index.html
Und schon wird ihm die Startseite seines privaten Intranets angezeigt.
Hierzu sollte Kay folgendes wissen: Der Webserver auf raspi002 denkt, die Anfrage kommt von raspi001, dessen IP-Adresse in das Protokoll geschrieben wird. Der Webbrowser auf dem Laptop denkt, dass Kay lokal auf seinem Rechner unterwegs ist und nutzt dafür vorgesehene Einstellungen. Einstellungen, die speziell für das Internet angelegt sind, werden ignoriert.
Nochmal die Wiederholung für Kay: Der Tunneleingang befindet sich auf dem Laptop Port 8080. Der Tunnelausgang ist auf raspi001 Port 8080. Daten werden von raspi001 ungesichert zu raspi002 weitergeleitet. Er hat also eine HTTP-Verbindung innerhalb einer SSH-Verbindung bis zu raspi001.
Diese Beispiele zu Tunnel sollen hier genügen. Man kann Tunnel miteinander verbinden. Dazu muss auf einem Gerät der Port des Ausgangs des ersten Tunnels gleichzeitig der Port des Eingangs des zweiten Tunnels sein.
Ich denke, hier ist es für Kay wichtiger zu erkennen, wie wichtig eine vernünftige Konfiguration des SSH-Servers ist, wenn er aus dem Internet erreichbar ist. Ist der Zugang zu seinem SSH-Server geknackt, könnten die bösen Hacker eine Unmenge an Schaden anrichten. Und alle Provider schimpfen:"Kay war's!"
Ich möchte dem Kay noch ein paar Tipps mit auf dem Wege geben, über die er nachdenken könnte, um die Sicherheit bezüglich SSH, wenn auch nur in einem sehr geringen Maße, zu verbessern. Einiges wurde dazu schon gesagt.
Jeder sollte selbst entscheiden, wie er SSH nutzt. Jeder ist selbst für die Sicherheit seines Systems verantwortlich.
Achte auf die Benutzer- und Gruppenverwaltung
Es ist nicht nur entscheidend, wer sich anmelden darf, sondern auch was der Angemeldete tun darf.
Claudia soll bestimmt nicht, auch wenn nur ungewollt, Kays Dateien verändern. Und ob Claudia Kays Dateien lesen und kopieren darf, muss Kay entscheiden.
SSH-Port ändern
Standardmäßig lauscht der SSH-Server auf Port 22. Nun denkt sich Kay:"Ich ändere den Port auf 2223. Und schon denken alle, dass kein SSH-Server läuft."
Das ist in einem geringen Maße richtig aber auch in einem hohen Maße falsch. Portscanner brauchen nicht lange, bis sie SSH auf Port 2223 gefunden haben.
Kay möchte es trotzdem machen. Dazu ändert er die Datei /etc/ssh/sshd_config wie folgt:
#Port 22
Port 2223
Sinn macht eine Portänderung, wenn man eine Menge an Geräten verwalten möchte. Man könnte jedem Bereich von Geräten einen extra Port zuweisen. Einige Geräte sollen aus dem Internet erreichbar sein und andere nicht. Macht ausversehen eine Person am Router den Port für ALLE Geräte auf, hat man so einen zusätzlichen Schutz.
Nicht zu viele gleichzeitige Verbindungen erlauben
Aber auch nicht zu wenig.
Kay hat ein Programm geschrieben und testet es auf dem Raspberry Pi. Über eine SSH-Verbindung startet er das Programm. Er möchte während der Programmausführung das System überwachen (Speichernutzung, CPU-Last, Temperatur etc.). Dazu benötigt er eine zweite SSH-Verbindung.
Kay entschließt sich, maximal 4 Verbindungen gleichzeitig zuzulassen, was ein gesundes Maß ist. Dazu ändert er /etc/ssh/sshd_config:
#MaxSessions 10
MaxSessions 4
Somit können nach dem Neustart des SSH-Servers maximal 4 Anmeldungen gleichzeitig stattfinden. Aber Weiterleitungen (Tunnel) werden hier nicht mitgezählt.
Nur Benutzer einer Gruppe Verbindungen zulassen
Bei Kay wurde ja nur die Claudia und sich selbst als Benutzer angelegt. Beide dürfen sich verbinden. Also spielt dieses Thema für Kay keine Rolle. Wirklich nicht?
Lieber Kay, führe mal auf deinem Raspberry Pi folgendes Komanndo aus:
cut -d ":" -f 1 /etc/passwd
Nun sieht Kay alle angelegten Benutzer. Es sind wohl doch ein paar mehr als zwei. Die meisten Benutzer sind "Pseudo-Benutzer", die vom System angelegt wurden, um gewisse Programme bzw. Dienste auszuführen, ohne komplette Root-Rechte zu erhalten.
Also wäre es vielleicht möglich, dass sich jemand als Benutzer www-data anmeldet? Nein Kay, es ist möglich.
Auf Kays Raspberry Pi ist bereits eine Benutzergruppe namens ssh für solche Zwecke angelegt. Schnell fügt er die Claudia und sich dieser Gruppe hinzu.
sudo adduser claudia ssh && sudo adduser kay ssh
Nun fügt er in /etc/ssh/sshd_config folgenden Eintrag hinzu:
AllowGroups ssh
Nach dem Neustart des Servers können sich nun nur noch Claudia und Kay per SSH anmelden, da sie Mitglieder der Gruppe ssh sind, auch wenn Kay die Passwortauthentifizierung zulässt.
Kay könnte auch mit "AllowUsers kay claudia" explizit nur die 2 Benutzer zulassen. Aber wenn irgendwann Benutzer hinzukommen oder entfernt werden, ist die Regelung mittes ssh-Gruppe besser, da der Server nicht neu konfiguriert werden muss.
Wenn mehrere Geräte gleichzeitig verwaltet werden
Wenn möglich keine SSH-Ketten
Das wurde schon angesprochen, es macht einfach keinen Sinn, Daten über eine größere Anzahl an Geräten zu übertragen.
Vermeide Loops
Ein Loop wäre bei Kay folgende Verbindungen: Laptop->raspi001->raspi002>raspi003>raspi001. Dazu vielleicht noch raspi003>raspi002. Nun blickt Kay nicht mehr durch, wie die Daten übertragen werden.
Nutze die Struktur eines Baumes
Kays Laptop ist der Stamm, die Raspberry Pis sind die Äste. Kay arbeitet mit 3 Shells, wo jeweils eine Verbindung zu einem Raspberry Pi vorhanden ist. So hat er immer den Überblick.
Sollen Daten von raspi001 auf raspi003 übertragen werden, bedeutet das natürlich ein höherer Aufwand. Er müsste erst die Daten auf sein Laptop ziehen und dann auf raspi003 schieben. Hier spricht nichts dagegen, kurzzeitig eine Verbindung von raspi001 zu raspi003 zu erstellen, die Daten zu übertragen und die Verbindung zu beenden.
