Extra Nutzer für SSH

[Richard]

Hallo,

auf meinem Tablet läuft LineageOS, das auch SSH über das Terminal an Board hat. Leider geht da keine Authentifizierung über eine Schlüsseldatei. Könnte man alternativ am Zielrechner, an den per SSH ein Befehl geschickt werden soll, einen neuen Nutzer anlegen dessen einzige Rechte es sind ein Script im Homeordner des Standardbenutzers auszuführen? Dann könnte man einfach am Handy SSH per Passwort verbinden lassen und es wäre egal wenn das Passwort dort im Klartext steht, weil der Benutzer eh nichts darf.

Also so: Unter /home/pi/script liegt ein Script das normal 'pi' gehört. Ein Nutzer 'pi-ssh' darf nur genau dieses starten, mehr nicht.

Wie müsste ich das einrichten? Zum einem braucht er Zugriff auf genau diese Datei, zum anderen müsste ich alles andere deaktivieren. Reicht es Gruppenzugehörigkeiten zu entfernen?

Richard

[MSfree]

Unter /home/pi/script liegt ein Script das normal 'pi' gehört. Ein Nutzer 'pi-ssh' darf nur genau dieses starten, mehr nicht.

Stop, Denkfehler:

In einem Skript werden ja normalerweise weitere Befehle und Porgramme ausgeführt, z.B. könnte man mit einem Skript auch ein Backup mit rsync starten. Wenn du die Ausführbarkeit auf so ein Skript beschränkst, könnten keine Porgrammaufrufe mehr ausgeführt werden, wie hier z.B. rsync.

[ReturnToSender]

Also so: Unter /home/pi/script liegt ein Script das normal 'pi' gehört. Ein Nutzer 'pi-ssh' darf nur genau dieses starten, mehr nicht.

Wenn sich ein Benutzer 'pi-ssh' anmeldet, bedeutet das, dass er auch erst mal im Homedir des Benutzers 'pi-ssh' auf dem Gerät SSH-Server landet. In dem Fall wird er gar keine Rechte haben, das Homedir des User 'pi' zu öffnen und dort ein Script zu starten. Das Script müsste sich also auch im Homedir des User 'pi-ssh' befinden. Liegt es dort als das einzige Script, kann er auch nur dieses starten. Das bedeutet aber nicht, dass er nicht auch andere, reguläre Programme/Scripte starten kann, die in den üblichen Linux-Verzeichnisen abgelegt sind.

[cronoik]

Zusaetzlich zu den Kommentare meiner Vorredner:
EInschraenken kannst du beispielsweise uber das authorized_keys file (siehe [1] und [2]).

[1] https://www.thomas-krenn.com/de/wiki/Au ... %C3%A4nken
[2] https://unix.stackexchange.com/question ... fic-script

[Richard]

Da gibt es aber ein anderes Henne-Ei-Problem. Ich würde mich hier aussperren, wenn ich den Benutzer anlege, dann - bevor der Zugriff begrenzt ist - die Schlüsseldatei kopieren und entsprechend abändern um nur einen Befehl ausführen zu können. Dann kann ich die authorized_keys aber auch nicht mehr ändern. Ein anderer User aber auch nicht. Das könnte wohl nur root?

[uname]

Wahrscheinlich habe ich dein Problem nicht verstanden. Du willst dich von Tablet zu einen Server verbinden? Wenn der Benutzer sowieso nichts darf, warum willst du dich verbinden? Wenn du die Identität welchseln willst könntest du dem Benutzer in /etc/passwd evtl. die Shell /bin/su geben Was soll der Benutzer denn überhaupt dürfen?

[cronoik]

Das könnte wohl nur root? Da du aber auch einen Nutzer anlegen kannst, hast du doch administrative Rechte.

Ja.

Da gibt es aber ein anderes Henne-Ei-Problem. Ich würde mich hier aussperren, wenn ich den Benutzer anlege, dann - bevor der Zugriff begrenzt ist - die Schlüsseldatei kopieren und entsprechend abändern um nur einen Befehl ausführen zu können. Dann kann ich die authorized_keys aber auch nicht mehr ändern.

Ich bin gerade unterwegs, aber die Begrenzung duerfte nur neue Verbindungen betreffen (Vielleicht laesst du dies noch einmal bestaetigen von jemanden aus dem Forum). Deshalb oeffene einfach zwei Terminals und verbinde dich als pi-ssh. In dem einen machst du die Veraenderungen und meldest dich in diesem dann wieder ab. Danach kannst du testen ob es funktioniert wie gedacht. Falls dies der Fall ist, kannst du dich nun am zweiten Terminal abmelden. Falls nicht, hast du noch eine laufende Session in der du die Aenderungen rueckgaengig machen kannst.

Was soll der Benutzer denn überhaupt dürfen?

Nur ein Skript starten und sonst nix.

Edit: Ich habe gerade gesehen das du nicht mit Schluesseln arbeiten kannst. Dann kannst du dir die authorized_keys schenken. Sorry das hatte ich ueberlesen.

[mat6937]

Also so: Unter /home/pi/script liegt ein Script das normal 'pi' gehört. Ein Nutzer 'pi-ssh' darf nur genau dieses starten, mehr nicht.

Du könntest als Alternative auch z. B. socat, verwenden um das Script auf dem PI auszuführen. socat kannst Du so konfigurieren, dass schon ein Portscan aus dem Internet ausreicht um das Script auszuführen.

[wanne]

Du könntest als Alternative auch z. B. socat, verwenden um das Script auf dem PI auszuführen. socat kannst Du so konfigurieren, dass schon ein Portscan aus dem Internet ausreicht um das Script auszuführen.

Socat kann auch x.509 Clientauthentifkation. Siehe auch socat-openssl.txt.
Auf eine reine Verbindung würde ich nicht setzen. Da laufen zu viele Portscanner, die das versehentlich starten.
Gerade sowas ähnliches gebaut. (Allerdings ohne SSL.)
Für den genannten Zweck würde ich aber eher auf xinetd oder einen kleinen Webserver mit cgi setzen. Der kann dann gleich basic auth oder so.

[Richard]

Ich habe gerade gesehen das du nicht mit Schluesseln arbeiten kannst. Dann kannst du dir die authorized_keys schenken. Sorry das hatte ich ueberlesen.

Gibt es eine andere Möglichkeit statt der authorized_keys das zu begrenzen?

Dann bleibt wieder nur die Möglichkeit die Rechte des Nutzers schon direkt am Server zu begrenzen und das bringt mich wieder zur Eingangsfrage. Von mir aus kann das Script auch im Homeordner des neuen Nutzers liegen. Über Gruppen entfernen sollte doch schon ein bisserl was gehen oder?

[MSfree]

Dann bleibt wieder nur die Möglichkeit die Rechte des Nutzers schon direkt am Server zu begrenzen und das bringt mich wieder zur Eingangsfrage. Von mir aus kann das Script auch im Homeordner des neuen Nutzers liegen. Über Gruppen entfernen sollte doch schon ein bisserl was gehen oder?

Nein, da geht nichts, denn du machst einen Denkfehler:

Natürlich kannst du den User auf die Ausführung dieses einzigen Skriptes einschränken. So weit so gut. Allerdings wäre so ein Skript funktionslos, denn das Skript dürfte nichts aufrufen, weil es unter dem eingeschränkten Benutzer läuft aud folglich nichts aufruden dürfte ausser sich selbst.

[mat6937]

Auf eine reine Verbindung würde ich nicht setzen. Da laufen zu viele Portscanner, die das versehentlich starten.

Nein, das kann nicht versehentlich passieren, denn es ist ja kein einfacher Portscan. Der source-Port muss ein bestimmter sein, ein bestimmtes Bit oder eine Kombination (z. B. ecn und/oder cwr) muss gesetzt sein und die TTL des Portscan muss eine bestimmte sein. Wenn das nicht zutrifft lässt iptables den Portscan nicht durch. Evtl. gibt es noch weitere/zusätzliche Möglichkeiten den Filter für den Portscan zu verbessern/optimieren.

[catdog2]

Warum nicht einfach z.B. https://f-droid.org/de/packages/org.connectbot/ oder https://f-droid.org/de/packages/com.termux/ verwenden?

Gibt es eine andere Möglichkeit statt der authorized_keys das zu begrenzen?

Ein Match block in der /etc/ssh/sshd_config sollte ähnliche Möglichkeiten bieten.

[Richard]

@ catdog2

Was sind das für Apps? Welche die einfach eine SSH-Verbindung herstellen? Das suche ich nicht. Es soll automatisiert per Tasker ein Befehl per SSH geschickt werden. Da müssen Logindaten oder Schlüsselpaar schon drin stehen.

@ MSfree

Natürlich sollte dann auch der Zugriff auf die Programm die vom Script gestartet werden zugelassen werden.

[MSfree]

Natürlich sollte dann auch der Zugriff auf die Programm die vom Script gestartet werden zugelassen werden.

Und genau da wird es sehr, sehr kompliziert. Die einzige Möglichkeit, die ich da sehe, ist, den Benutzer in eine chroot-Umgebung zu sperren und die Executables, die der Benutzer ausführen können soll, per Hardlink in ein Verzeichnis zu linken, auf das der Benutzer in seiner chroot-Umgebung Zugriff hat. Dumm, nur, daß praktisch alle Executables von shared Libraries abhängig sind, die du ebenfalls verlinken müßtest. Am Ende hast du dann 70% des Betriebssystemdateien verlinkt. Dann kannst du dem Nutzer auch gleich wieder vollen Zugriff aufs System zulassen, womit wir beim berühmten Schwanz angekommen sind, in den sich die Katze gerade selbst beißt.

Mit anderen Worten, einen Benutzer so einzuschränken, daß er nur auf ein Skript und alle daraus aufgerufenen Executables Zugriff hat, ist nahezu unmöglich bzw. wird irgendwann absurd, wenn man mehr als nur 1-2 Executables braucht.

Eventuell kann man mit ACLs etwas bewirken, aber das würde ich mit extremer Vorsicht benutzen. Denn du müßtest praktisch alle Dateien des Dateisystems für einen Benutzer per ACLs sperren und dann nur die nicht sperren, auf die der Benutzer zugreifen können soll (das könnten aber die selben 70% sein, die ich oben schon erwähnt habe). Wenn man sowas später mal rückgängig machen wollte, wäre eine Neuinstallation fast schon einfacher als ACLs zu suchen und rückgängig zu machen.

[Richard]

Ihc stell mir da gerade die Frage, wie das Entwickler machen bei denen ein Prozess unter einem eigenen Nutzer läuft. Hab da z. B. Transmission (bzw. seinen Daemon) in Erinnerung. Das hatte ich auf dem Pi mit einem Webinterface eingerichtet und der Daemon läuft als Benutzer debian-transmission (oder so ähnlich). Wenn der Benutzer vieles darf ist das irgendwie sinnlos. Demnach müsste der auch irgendwie beschränkt ( ) sein, würde ich vermuten.

[JTH]

Die Haupteinschränkung ist dabei dann (denke ich) einfach nur, dass ein Daemon gerade nicht als root-Benutzer laufen muss – solange der Daemon dessen Zugriffsmöglichkeiten nicht braucht. Ansonsten hat ein System-User wie debian-transmission dieselben Rechte und Zugriff auf /usr/bin etc. wie jeder „normale“ menschliche Benutzer. Im Einzelnen kanns da sicher noch mehr Einschränkungen durch Gruppenzugehörigkeit etc. geben, aber der Hauptpunkt ist das Nicht-als-root-Laufen.

[catdog2]

Was sind das für Apps? Welche die einfach eine SSH-Verbindung herstellen? Das suche ich nicht. Es soll automatisiert per Tasker ein Befehl per SSH geschickt werden. Da müssen Logindaten oder Schlüsselpaar schon drin stehen.

connectbot ist nur ein ssh client, weiss nicht ob man den per tasker bedienen kann, termux kann bissl mehr:

Termux is an Android terminal emulator and Linux environment app that works directly with no rooting or setup required. A minimal base system is installed automatically - additional packages are available using the APT package manager.

Da gibts auch ein Plugin dafür mit dem man ein eigenes Skript per tasker triggern kann (welches ssh aufrufen könnte), also evtl was für dich: https://f-droid.org/de/packages/com.termux.tasker/

[cronoik]

Ihc stell mir da gerade die Frage, wie das Entwickler machen bei denen ein Prozess unter einem eigenen Nutzer läuft.

Wenn es ein daemon ist, dann wird dieser einmalig auf dem Server durch einen Nutzer der sich per ssh anmelden darf gestartet. Der Nutzer unter welchen der Daemon laeuft, darf sich nicht per ssh anmelden und damit brauch man sich auch nicht weiter darum kuemmern was der darf.
Wenn es wie in deinem Fall um ein Anstossen von einem Skript auf dem Server geht, dann benutzt man Schluessel. Ob/Warum das dein Programm (nicht) kann, weis ich nicht. catdog2 hat dir allerdings eine Moeglichkeit genannt mit der es eventuell gehen koennte. Eine weitere Moeglichkeit waere die LoginShell in /etc/passwd auf dein Skript zu setzen [1]. Wie sicher das allerdings ist, kann ich dir nicht sagen.

Wenn der Benutzer vieles darf ist das irgendwie sinnlos. Demnach müsste der auch irgendwie beschränkt ( ) sein, würde ich vermuten.

In erster Linie darf er nicht root werden und dann ist kuemmert man sich auch in zweiter Linie darum dass den keiner uebernehmen kann. Du verzichtest doch auch nicht auf ein ordentliches Tuerschloss nur weil du dein Hab und Gut mit einem ultra tollen Kleber festgeklebt hast.

[1] https://stackoverflow.com/a/12993743

[mat6937]

IHab da z. B. Transmission (bzw. seinen Daemon) in Erinnerung. Das hatte ich auf dem Pi mit einem Webinterface eingerichtet und der Daemon läuft als Benutzer debian-transmission (oder so ähnlich).

Hat der Benutzer "debian-transmission" den Daemon auch starten können bzw. dürfen? ... oder musste dieser durch root gestartet werden und wechselte nach dem Starten, auf den Benutzer "debian-transmission", für die Dauer der Laufzeit?

[Richard]

Hat der Benutzer "debian-transmission" den Daemon auch starten können bzw. dürfen? ... oder musste dieser durch root gestartet werden und wechselte nach dem Starten, auf den Benutzer "debian-transmission", für die Dauer der Laufzeit?

Ich starte den Daemon zumindest nicht durch root. Daher denke ich er darf das. Das ist mir auch nur aufgefallen als es darum ging den Autostart dafür einzurichten. Sonst hätte ich das gar nicht bemerkt.

[ReturnToSender]

Ihc stell mir da gerade die Frage, wie das Entwickler machen bei denen ein Prozess unter einem eigenen Nutzer läuft.

Das ist der Unterschied... denn ein solcher Prozess wurde durch einen angemeldeten User gestartet oder zum Starten veranlasst. Wenn ich das richtig verstanden habe, soll bei diesem aktuellen Problem ein via SSH auf einem Server angemeldeter User ein bestimmtes Programm starten dürfen, aber er darf nicht die Rechte eines angemeldeten Users haben. Tja, das ist ein imho ein Widerspruch an sich... das eine ohne das andere geht m.M.n. nicht.

Ich würde deshalb vielleicht einen völlig anderen Weg verfolgen, und zwar das Script starten zu lassen, ohne dass sich überhaupt ein/der User dafür anmelden muss und ohne dass es dafür neue Sicherheitslücken durch vielleicht unzureichend geprüfte Autorisierung gibt. Und zwar, in dem der Start des Scripts via sowieso etablierter Netzwerk-Protokolle getriggert wird und es dadurch startet. Dazu fallen mir zwei funktionierende Lösungen ein.

Die erste ist hierfür den telegram-daemon laufen zu lassen, der mit übertragener Nachricht und seinem Eventhandler auf die Nachricht reagiert. Damit kann man von jedem Android, IPhone, Tablet, wasauchimmer, einfach eine Nachricht senden. Der Server interpretiert Absender und Nachricht und reagiert entsprechend darauf.

Ein zweite Möglichkeit wäre auf dem Server netcat im LocalNet lauschen zu lassen und dem Server eine Nachricht via TCP zu senden. Darüber könnte dann auch der Start des Scripts getriggert werden. Um das auch via Internet zu ermöglichen, würde ich dazu einen OpenVPN-Tunnel öffnen, um die notwendige Autorisierungssicherheit zu gewährleisten. Dazu brauchts dann nur ein Minitool auf dem Android-Gerät, welches via TCP-Socket die passende Nachricht senden kann.

[MSfree]

Ich starte den Daemon zumindest nicht durch root...

Wenn man sich mal die Dateiberechtigungen einer normalen Linuxinstallation ansieht, stellt man fest, daß jeder Nutzer auf fast alle Dateien Leseberechtigungen hat und fast alle Executables ausführen darf, nur root darf auch überall schreiben. So kann ein normaler Benutzer z.B. auch fdisk ausführen, Verändereungen an den Partitionen darf er jedoch nocht vornehmen, weil er auf das Disk-Device (z.B. /dev/sda) keine Schreibberechtigung hat.

Daraus ergibt sich, daß auch ein Extranutzer so gut wie alles lesen und ausführen darf. Die Einschränkung auf nur ganz bestimmte Dateien ist so erstmal nicht vorgesehen und bedeutet wesentlich Umbauten an einer Standardinstallation.

Der Grund, einzelne Daemons nicht als root zu starten liegt also hauptsächlich darin, nicht alle Dateien für den Daemon schreibbar zu präsentieren, sonst könnte er z.B. auch einfach das root-Paßwort in /etc/shadow überschreiben, um sich im zweiten Schritt root-Rechte zu erschleichen, sollte er böses im Schilde führen.

[Richard]

Einen telegram-cli-daemon hab ich auf einem anderen Pi schon laufen. Da sende ich aber ausschließlich manuelle Sachen wie DL-Links ohne vorher eine SSH-Verbindung aufbauen zu müssen. Das wäre eine Möglichkeit an die ich bisher nicht gedacht hab. Muss mal gucken ob Tasker automatisierte Nachrichten versenden kann.

netcat kenn ich nicht, müsste ich mir mal ansehen. Hauptfrage ist hier immer ob das automatisiert über Android angestoßen werden kann.

Die weiter oben genannte SSH-App guck ich mir auch mal an.

[ReturnToSender]

netcat kenn ich nicht, müsste ich mir mal ansehen. Hauptfrage ist hier immer ob das automatisiert über Android angestoßen werden kann.

Du kannst das relativ einfach auf Deinem PC testen, um erst mal einen Eindruck zu bekommen, was es überhaupt macht. Um dann bei "Tauglichkeit" das Thema zu vertiefen und vielleicht richtig auszuarbeiten. Öffne zwei Terminalfenster.
Im ersten startest Du:

Code: Alles auswählen

nc -l -p 55555

Im zweiten dann:

Code: Alles auswählen

echo "Hallo Welt" > /dev/tcp/localhost/55555

oder alternativ auch über netcat

Code: Alles auswählen

echo -n "hallo" | nc -w1 localhost 55555

Der Port muss natürlich nicht 55555 sein, der kann frei gewählt werden. Und wenn es kein privilegierter Port sein muss, kann es einfach jeder freie Port von 1025-bis 65535 sein. Innerhalb des LANs kann statt "localhost" natürlich auch eine IP eines beliebigen Hosts vervendet werden, wenn dort eben der netcat lauscht.
Im Internet gibt es viele Mini-TCP-Clients in C, die total simpel eine Nachricht via TCP-Paket übers Netz senden können, kleine Sourcen, die man eigentlich auch auf dem Android kompilieren können sollte. Allerding halte ich es bei dieser Lösung für wichtig, wenn das auch übers Internet erfolgen soll, keine direkte Port-Weiterleitung im DSL-Router einzurichten, sondern das besser über einen VPN-Tunnel abzusichern. Innerhalb des LANs ist das jedoch nicht notwendig. Allerdings muss ich zugeben, das ist ein anspruchsvolles Ziel, welches doch einiges an Sachkenntnis erfordert. Der telegram-Weg ist definitiv leichter zu gehen.