Erweiterung Befehle Jailed SSH [GELÖST]

[mhagge]

Ich würde mir wünschen, dass die JailedSSH-Umgebung um Ghostscript (/etc/gs) und die ImageMagic Command-Line-Tools (convert etc) erweitert wird.

Diese Binaries werden doch recht häufig auch aus PHP-Scripten direkt aufgerufen. Wenn nun aber ein JailedSSH für den Account aktiv ist geht das nicht mehr, weil diese Programme dann nicht mehr erreichbar sind. Nehme ich den Account nun aber das SSH-Recht weg (oder erlaube ungejailtes SSH) funktioniert alles wieder - das ist etwas "blöd"

[OlliTheDarkness]

Grundsätzlich wäre es vieleicht auch eine Idee , es wie beim OpenBaseDir zu regeln.

Die Anwendungen, welche neben den grundsätzlichen Befehlen, bereitgestellt werden sollen in den Einstellungen anpassbar.

Wäre halt eine Idee , damit die Admins , welche doch teilweise ihre eigenen Süppchen kochen etwas freier sind.

[Alexander]

@Olli, schöne Idee.

Gleich mal versuchen, wie praktikabel das ist . Es wird dann darauf hinaus laufen, dass man als Admin in den Einstellungen festlegen kann, welche Binaries (kompletter Pfad zum Binary) man gern mit in die Chroot übertragen möchte. Die Abhängigkeiten (libs) sucht sich KeyHelp dann selber.

[OlliTheDarkness]

@Olli, schöne Idee.

Gleich mal versuchen, wie praktikabel das ist . Es wird dann darauf hinaus laufen, dass man als Admin in den Einstellungen festlegen kann, welche Binaries (kompletter Pfad zum Binary) man gern mit in die Chroot übertragen möchte. Die Abhängigkeiten (libs) sucht sich KeyHelp dann selber.

@Alex, danke.

Ist halt in meinen Augen die für euch, einfachste Lösung.

Den es gab ja schon den ein oder anderen Beitrag, was man noch ins Jail packen könnte.

Ehrlich gesagt ist die Liste , welche Anwendungen man bereitstellen kann unendlich.

Also einfach die Möglichkeit schaffen, den Admin selbst entscheiden zu lassen und gut.

Win Win Situation.

Ihr als Devs habt eure Ruhe weil der Admin tun kann was er für richtig hällt und der Admin hat Ruhe weil er kann, was er brauch in seinem System bereitstellen.

Und letztlich arbeitet der Admin "EIGENVERANTWORTLICH" !

Sprich , egal was Passiert, der Administrator muss selbst wissen was er tut.

[Alexander]

Hab es soeben eingebaut .

Done!

[mhagge]

Huch, da schaut man mal 2 Stunden nicht hier rein Danke @Alex (und @OlliTheDarkness natürlich auch) !

[[headcrash]]

sehr fein, danke dafür, das hilft uns immens

[Tobi]

Alex mein Held

[Enigma]

Das ist in der Tat extrem hilfreich, vielen herzlichen Dank! Und viel schneller geht's nun wirklich nicht.

Gruß
Jan

[Blackmoon]

Tip Top! Danke!

[Alexander]

Beim Testen fiel mir noch auf, dass es ja nicht unbedingt bei allen Binaries mit dessen automatisch ermittelten Abhängigkeiten getan ist.
Manchmal kann es vorkommen, dass Binaries noch ergänzende Dateien benötigen (diese befinden sich i.d.R. im Ordner /usr/share/).

Aus diesem Grund hab ich noch ein weiteres Eingabefeld dafür hinzugefügt, dass man bei Bedarf mit weiteren Pfaden füllen muss.

===========================

Anbei mal ein Beispiels anhand des "Ghostscript"-Binary ("gs"), um kommenden Rückfragen nach 21.0-Release zuvorzukommen:

Ihr wollte Ghostscript in der Chroot ergänzen:

1) Binary-Pfad herausfinden (z.B. mit "whereis gs" oder "locate gs" etc...)

Code: Select all

root@dev01:~# whereis gs
gs: /usr/bin/gs /usr/share/man/man1/gs.1.gz

2) Den Pfad des Binary "/usr/bin/gs" unter "Konfiguration" -> "Eingechränke SSH Umgebung" unter "Zusätzliche Binaries" einfügen

3) In der Chroot prüfen, ob sich der Befehl "gs" ausführen lässt.

Code: Select all

a1@dev01:/www$ gs
GPL Ghostscript 9.26: Can't find initialization file gs_init.ps.

=> Da fehlt noch was.

4) Herausfinden, wo sich die fehlende Datei befindet (per administrativen Benutzer auf dem Server)

Code: Select all

root@dev01:~# locate gs_init.ps
/usr/share/ghostscript/9.26/Resource/Init/gs_init.ps

5) Den Pfad "/usr/share/ghostscript/" unter KeyHelp -> "Konfiguration" -> "Eingechränke SSH Umgebung" unter "Zusätzliche Pfade" einfügen.

6) In der Chroot prüfen, ob sich der Befehl "gs" ausführen lässt.

Code: Select all

a1@dev01:/www$ gs
GPL Ghostscript 9.26 (2018-11-20)
Copyright (C) 2018 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
  ./base/gsicc_manage.c:1244: gsicc_open_search(): Could not find default_gray.icc 
| ./base/gsicc_manage.c:2261: gsicc_init_iccmanager(): cannot find default icc profile
**** Unable to open the initial device, quitting.

=> Ihm fehlt immer noch was, z.B. "default_gray.icc"

7) Herausfinden, wo sich die fehlende Datei befindet (per administrativen Benutzer auf dem Server).

Code: Select all

root@dev01:~# locate default_gray.icc
/usr/share/color/icc/ghostscript/default_gray.icc

8) Den Pfad "/usr/share/color/icc/ghostscript/" unter KeyHelp -> "Konfiguration" -> "Eingechränke SSH Umgebung" unter "Zusätzliche Pfade" einfügen

9) In der Chroot prüfen, ob sich der Befehl "gs" ausführen lässt.

Code: Select all

a1@dev01:/www$ gs
GPL Ghostscript 9.26 (2018-11-20)
Copyright (C) 2018 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Warning: the map file cidfmap was not found.
GS>

=> Das passt, fertig!

Endergebnis in den Einstellungen sieht dann so aus:

[Blackmoon]

Moin,
gefällt mir sehr gut! Zumal mir erst in einem Support Ticket mitgeteilt wurde, dass eine Erweiterung nicht möglich ist/keinen Sinn macht.

Gibt es evtl. noch eine Möglichkeit, in den beiden Felder jeweils Kommentare zu setzen? Gerade bei Vielzahl von Abhängigkeiten im Kombination mit den verschiedenen CMS. Sprich alle Zeilen die mit "#" beginnen sollen ignoriert werden.

Grüße

[Tobi]

6) In der Chroot prüfen, ob sich der Befehl "gs" ausführen lässt.

Wie kann ich den chroot für den Kunden prüfen wenn ich dessen Passwort nicht kenne?

[Blackmoon]

Wie kann ich den chroot für den Kunden prüfen wenn ich dessen Passwort nicht kenne?

Auf der Shell su - <username> ausführen. Funktioniert natürlich nur, wenn für den Kunde/Benutzer auch SSH aktiviert ist.

[Tobi]

Wie kann ich den chroot für den Kunden prüfen wenn ich dessen Passwort nicht kenne?

Auf der Shell su - <username> ausführen. Funktioniert natürlich nur, wenn für den Kunde/Benutzer auch SSH aktiviert ist.

Leider nicht.
Du nimmst dann deine root-Fähigkeiten mit.

Gerade ausprobiert, Pro Version, SSH-Jail aktiv

Code: Select all

root@server:~# su - username
username@server:~$ whereis gs
gs: /usr/bin/gs /usr/share/man/man1/gs.1.gz
username@server:~$ gs
GPL Ghostscript 9.26 (2018-11-20)
Copyright (C) 2018 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.

Aber laut Markus ist "gs" eben nicht aktiv im Jail.