Bash shell via SSH erzwingen?

[buhtz]

Ich habe eine grundlegende Frage, im Kontext der Entwicklung von backintime (upstream Issue #1905), die sich um Shells und SSH dreht.

Meine Anwendung führt, zu verschiedenen Anlässen, auf einem entfernten Server via SSH diverse Kommandos und teilweise auch Script-Code aus. Das führt teilweise zu Problemen, wenn der Server des Users eine "exotische" Shell (z.B. fish) einsetzt, weil die Kommandos dann nicht mehr funktionieren.

Code: Alles auswählen

ssh user@server foobar

Um solche Probleme zu umgehen, denke ich dass es eine gute Idee wäre, eine bash sub-shell aufzurufen.

Code: Alles auswählen

ssh user@server bash -c "foobar"

Meinem Verständnis nach, handelt es sich bei beiden Varianten um eine nicht-interaktive nicht-login-shell. Richtig?
Und die sub-shell erbt die Umgebungsvariablen der Eltern-Shell. Richtig?

Wenn das alles stimmt, dürften keine Probleme zu erwarten sein, vorausgesetzt remote ist "bash" vorhanden. Oder übersehe ich etwas?

[Meillo]

Wenn das dein persoenlicher Account auf dem Server ist, dann koenntest du dort einfch `chsh' ausfuehren, um deine Login-Shell auf die bash umzustellen.

[chrbr]

Hallo Christian,
vielleicht wäre es nicht verkehrt, nur eine "sh" beziehungsweise eine "/bin/sh" voraus zusetzten. Die bash ist zwar sehr verbreitet, aber nicht überall installiert. Zur fish: Das ist eine schöne Shell und ich verwende sie auch, viele Dinge sind aber schon anders (AKA not invented here?). Wenn Du die Eigenarten verschiedener Shells berücksichtigen willst, dann machst Du ein Fass ohne Boden auf. Aber das weißt Du ja selbst.
Viele Grüße,
Christoph

[buhtz]

vielleicht wäre es nicht verkehrt, nur eine "sh" beziehungsweise eine "/bin/sh" voraus zusetzten. Die bash ist zwar sehr verbreitet, aber nicht überall installiert.

Danke für die Rückmeldung.

Könnte man sagen "sh" ist simpler und weniger komplex; sozusagen eine Untermenge einiger anderer shells?
Ich hatte auch schon überlegt, meine shell codes streng auf POSIX anzupassen.
Egal ob POSIX, sh oder bash, ich muss es auf der remote Seite forcieren können, oder ggf. eine ordentliche Fehlermeldung ausgeben, wenn die gewünschte shell dort nicht verfügbar ist.

Ist sh so eine Art inbuild-kernel-shell?
Aber selbst "sh" ist nicht überall verfügbar, z.b. Hetzner-Boxen, die irgendein Art beschnittene shell (busybox oder so?) nutzen.

Also würde ich sowas machen?

Code: Alles auswählen

ssh user@server "sh -c 'foobar'"

Abgesehen von der Wahl der shell, ob ich hier bezüglich der Umgebungsvariablen oder "anderer Dinge" etwas übersehe.

[Meillo]

Die entscheidende Frage ist, was `foobar' genau ist. Ohne darueber mehr zu wissen, ist es schwer, etwas zu den Shells zu sagen. (An sich ist es ja eher ungewoehnlich als SSH-Befehl komplexe Shellscripte inline anzugeben, was in der Praxis der einzige Fall sein duerfte, der zu Problemen fuehrt.)

Du kannst nie sicher sein, mit welcher Shell dein Befehl ausgefuehrt wird. Wenn du eine Bourne-kompatible Untermenge verwendest, oder nur einen Befehl aufrufst, dann wird das fast immer funktionieren, aber man kann es nicht garantieren.

Du koenntest auch erst mit scp ein Shellscript uebermitteln, das eine Shebang-Zeile enthaelt und dann dieses mit ssh ausfuehren, damit koenntest du das Problem mit der ungewissen Login-Shell umgehen.

Ohne genauere Informationen darueber, was fuer Befehle du ausfuehren willst und in welcher Weise du die User-Accounts auf den Servern personalisieren kannst, und was fuer Systeme das sind (Ist beispielsweise ein BSD dabei?), lassen sich nur schwer irgendwelche Aussagen machen.

[chrbr]

Aber selbst "sh" ist nicht überall verfügbar, z.b. Hetzner-Boxen, die irgendein Art beschnittene shell (busybox oder so?) nutzen.

Das war mir nicht klar. Und da gibt es keinen Link, der einem eine sh vorgaukelt?

Ich hatte auch schon überlegt, meine shell codes streng auf POSIX anzupassen.

Das wäre sinnvoll, wenn Du das allgemein halten willst. Nun habe ich aber noch eine Idee. Laut
https://packages.debian.org/bullseye/backintime-common
wird Python3 benötigt. Gilt das auch für die (Remote?)-Systeme, auf denen momentan Probleme mit fish auftreten?
Wenn ja, dann könntest Du ja auch Python anstelle von Shell-Scripts verwenden. Das wäre zwar mit Kanonen auf Spatzen geschossen, wäre aber vielleicht eine Lösung, wenn Python3 sowieso vorhanden sein müsste.
Viele Grüße,
Christoph

[buhtz]

Aber selbst "sh" ist nicht überall verfügbar, z.b. Hetzner-Boxen, die irgendein Art beschnittene shell (busybox oder so?) nutzen.

Das war mir nicht klar. Und da gibt es keinen Link, der einem eine sh vorgaukelt?

Details zum Hetzer Problem gibt es im Issue #1745

Laut
https://packages.debian.org/bullseye/backintime-common
wird Python3 benötigt. Gilt das auch für die (Remote?)-Systeme

Nein.

Shell scripts per scp rüberschieben, muss ich mal prüfen. Back In Time nutzt die ssh shell an so vielen Stellen, das mir derzeit der Überblick fehlt.

Danke erst mal, es hat geholfen.

[buhtz]

Hinsichtlich Nutzen-Aufwand-Risiko-Kalkulation, präferiere ich aktuell das Forcieren einer bash oder sh shell via ssh bash -c "foobar" und hole da gerade ein Stimmungs- und Meinungsbild der Community ein.