OpenElec SSH „PasswordAuthentication no“

OpenElec SSH

Ich wollte für einen Bekannten ein OpenElec (Kodi) auf einem RaspberryPi via SSH nach außen zugänglich machen. Das eigentliche Problem ist, dass man die Zugangsdaten (Username root oder Passwort openelec) in der Kommandozeile nicht ändern kann, aufgrund von deaktiviertem sudo. So entsteht, wenn man eine Portweiterleitung im Router auf den Raspberry einstellt, eine unangenehme Sicherheitslücke. Wenn man das Passwort nicht ändern kann, bleibt noch die Möglichkeit den Zugang zu SSH über Passwörter zu deaktivieren. Schlau gedacht und damit /etc/ssh/sshd_config angepasst: PasswordAuthentication no. Schade, das Filesystem ist read-only, speichern nicht möglich. Einen Remount mit rw ging nicht.

Aber man kann dem SSHDaemon trotzdem Startparameter unterschieben.
Der SSHD Start wird in folgender Datei definiert:
/usr/lib/systemd/system/sshd.service.
Und die sucht Konfigurationen wiederum hier:
/storage/.cache/services/sshd.conf.
In Zeile 2 kann man nun folgendes eintragen:
SSH_ARGS="-o 'PasswordAuthentication no'".
Beim nächsten Neustart ist die Passwortabfrage deaktiviert.
Darum vorsicht, den Public Key vorher in
/storage/.ssh/authorized_keys kopieren.

Blockiertes Gast-Netzwerk umgehen

Ports blockiert, wie umgehen

Ich war neulich auf Reisen und bekam eine LTE Verbindung mit Volumenbegrenzung von 10GB spendiert. Problem war, dass ich von einer Flatrate ausgegangen war. Nun hatte ich darauf verzichtet vorher alle für die Arbeit benötigten Daten auf lokale Speichermedien zu kopieren, da ich dachte, dass ich ja auch später noch alles was fehlt nachträglich über das Netz laden kann. Doch wenn man sich seine 10GB doch einteilen muss, sucht man nach anderen Internet-Quellen. Die nächste Flatratequelle war in diesem Fall ein kostenloses Gastnetzwerk in der Nähe. Auf diesem Gastnetzwerk waren nicht viele Ports offen: 80, 443, 25, 143, 993, 995, 8080, um den Großteil zu nennen. Alle Ports die ich für eine Downloadverbindung zum Server brauchte, waren verschlossen und da meine OpenVPN Verbindung auf UDP 1194 eingestellt war, kam ich damit auch nicht weiter.

SSH Port Weiterleitung am Router

Welche Ports blockiert werden, kann man ganz einfach mit curl portquiz.net:993 herausfinden. Wobei 993 der Port ist, den man testen will. Die Seite portquiz.net bietet auch noch andere Testvarianten.

Zum Hauptproblem fand ich mehrere Lösungswege. Der erste schien mir am schnellsten. Wollte ich doch zu erst meine SSH Verbindung wieder nutzen, ohne den Port vom SSH Client zu ändern. Ich hatte zwar schon eine Portweiterleitung eingerichtet, aber die benutzte einen Port, der ebenfalls blockiert wurde.
Die Portweiterleitung ändere ich eigentlich am einfachsten mit dem Webinterface meines entfernten Routers, der die Zugänge zu meinem Server hinter dem Router regelt. Dort leite ich einfach einen im Gastnetzwerk freien Port (bspw. 993) auf meinen SSH Client um.
Das funktionierte leider nicht sofort und ich habe erst später gemerkt, woran es lag. Ich hatte in meiner Portweiterleitung mehrere Weiterleitungen angelegt, die alle auf den gleichen Port zeigten. Doch es fand weiterhin nur eine Weiterleitung über meinen alten Port statt, nie über die neu angelegten. Und der alte war nach wie vor im Gastnetzwerk gesperrt. Nach langem Rumprobieren kam ich drauf, dass ich die Portweiterleitungen, die ich für den Zielport 22 angelegt hatte, ein mal alle komplett abschalten musste, abspeichern und dann auf dem neuen Port wieder aktivieren musste. Dann übernimmt er die neue Weiterleitung. Doch darauf war ich erst ganz am Schluss gekommen. Denn vorher habe ich meine OpenVPN Verbindung auf TCP 443 eingestellt.

Open VPN auf https-Standardport 443 einstellen

Mit dem Umstellen von UDP Port 1194 auf TCP 443 habe ich eine sichere Fallback Lösung für alle Fälle, denn 443 müsste immer und überall offen sein und mit der VPN Lösung sollte ich immer alles über das Netzwerk bekommen, was ich brauche. Was ist eigentlich besser: OpenVPN via UDP oder TCP? (engl)

SSH Tunnel mit lokaler Portweiterleitung

Die dritte und und interessanteste Lösung war der SSH Tunnel, den ich ausprobieren musste, um ihn wirklich zu verstehen.
Angenommen ich erreiche meinen SSH Client neuerdings über Port 25, gebe ich im Terminal folgendes ein
sudo ssh -p 25 user@sshclient.de -L 8080:meinserver.de:5006 -N
macOS wollte sudo, weil Privileged ports can only be forwarded by root.
Ich verbinde mich also zuerst mit -p Port 25 auf meinen SSH Client.
Warum noch mal 25? Ist beispielhaft für einen Port im Gastnetzwerk, der nicht gesperrt ist, so dass nun der angerufene Router den Verkehr von 25 auf 22 weiterleiten kann.
Jetzt steht schon mal eine SSH Verbindung im blockierten Gastnetzwerk.
Wenn ich jetzt mit dem Browser auf das unerreichbare Webinterface meines Servers kommen möchte brauche ich noch -L offenerPort:angerufenerServer:geblockterPort.
Mit -L leite ich alle „local“ Anfragen, auf den im Gastnetzwerk freien Port 8080, über die etablierte SSH Verbindung. Mein verbundener SSH Client erzeugt einen Tunnel auf dem offenen Port 8080 und holt darüber die Pakete von dem im Gastnetzwerk unerreichbaren Port 5006 aus meinem Server.
Das -N weist SSH an, keine Befehle zu erwarten, das heißt, SSH stellt keine Eingabeaufforderung her, sondern ist im Horch-Modus.

Um die Adresse, die ich normalerweise mit https://meinserver.de:5006 aufrufen würde, zu erreichen, gebe ich jetzt im Browser https://localhost:8080 ein. Dann kann ich über den Port 8080 in den Tunnel meiner SSH Verbindung steigen und komme am anderen Ende auf meinem Server mit dem Port 5006 raus.

Mit diesen drei Lösungsmöglichkeiten ist man wirklich gut ausgestattet, um seine Daten in blockierten Umgebungen zu erreichen.

Firefox Fehlermeldung

Ein Problem gibt es aber noch, nämlich wenn man im Browser über einen Nicht-Standard-Port in den Tunnel möchte. Wenn man, wie ich, über Port 993 seine getunnelte Seite ansurfen will, gibt es bei allen Browsern eine Fehlermeldung, bspw. Firefox Fehler: Port aus Sicherheitsgründen blockiert.

Um den Fehler zu beheben gibt man in die Firefox Adresszeile about:config ein und sucht oder erstellt den Eintrag network.security.ports.banned.override. Als Wert wird der Port eingetragen bspw. 993.

Out of home office, draußen arbeiten dank NAS

Meine überarbeitete Website habe ich zu großen Teilen in freier Natur mit vim geschrieben. Nicht immer habe ich dafür einen Laptop benutzt. Auch das Smartphone, ein iPad oder Zuhause der stationäre Rechner, kamen zum Einsatz.

Damit ich unabhängig vom Gerät die gleiche Entwicklungsumgebung habe, musste ich mich erst mal mit dem Gedanken anfreunden, dass ich mich von der grafischen Oberfläche meines hoch geschätzten Atom-Editors verabschieden muss und die Grundlagen von vim, als Texteditor, und tmux, als Terminal Multiplexer, zu lernen habe. Beides Programme die auf der Kommandozeile laufen. Denn nur die Kommandozeile ist auf jedem Gerät und jedem OS installierbar und somit der kleinste gemeinsame Nenner aller Geräte, sei es Smartphone, Tablet oder Computer. Diese beiden Programme sind der Schlüssel zum Cloud Computing. Die wichtigste Rolle spielt dabei tmux.

weiterlesen…