Nutzen von sudo in SSH Jail (KeyHelp Pro) [SOLVED]

[space2place]

Ich bin sicher, dass die Ursache des Problems bei KeyHelp liegt
Ja


Server-Betriebssystem + Version
Debian 11


Eingesetzte Server-Virtualisierung-Technologie
KVM


KeyHelp-Version + Build-Nummer
23.0 (Build 2921)


Problembeschreibung / Fehlermeldungen
Ich benötige für einen Kunden sudo in der eingeschränkten SSH Umgebung.
Dazu habe ich in der Konfiguration "/usr/bin/sudo" als zusätzliches Binary hinzugefügt.
Ein sudoer Eintrag für den Benutzer existiert in einer Datei unter "/etc/sudoers.d/".

Bei den ersten Versuchen erschienen Meldungen die ich mit diesen zusätzlichen Pfaden beheben konnte:

Code: Select all

/usr/lib/sudo/
/etc/sudoers
/etc/sudoers.d/

Leider bekomme ich immer noch diesen Fehler:

Code: Select all

sudo: unable to initialize PAM: Critical error - immediate abort

Hat jemand das schon umgesetzt mit KeyHelp Pro und der eingeschränkten SSH Umgebung?

Erwartetes Ergebnis
sudo command funktioniert

Tatsächliches Ergebnis
sudo: unable to initialize PAM: Critical error - immediate abort

Schritte zur Reproduktion
Benutzer neu anlegen und direkt SSH (Eingeschränkte SSH-Umgebung) aktivieren. Mit SSH in den Jail verbinden.
Sudo mit einem erlaubten command ausführen.

Zusätzliche Informationen


Gruß
Sascha

[mhagge]

Widerspricht sich sudo und jailed-SSH nicht so ein bißchen? Was nützt mir der jail, wenn per sudo sowieso alles umgangen werden kann? Zumindestens sollten dann die für den User erlaubten Befehle sehr restriktiv gehandhabt werden, meiner Meinung nach

https://unix.stackexchange.com/question ... thout-sudo - da hat so was jemand anscheinend mal realisiert - da mussten noch ein paar Bibliotheken in den Jail. Die werden angesichts des Alters des Beitrages möglicherweise veraltet sein, aber vielleicht ist das ja ein Denkansatz

Edit: Ursache bei Keyhelp ganz sicher nicht. Ursache im JailedSSH - und so eine Möglichkeit möchte ich niemals im Standard-Setup sehen

[space2place]

Zumindestens sollten dann die für den User erlaubten Befehle sehr restriktiv gehandhabt werden, meiner Meinung nach

So habe ich es auch geschrieben. Nur das Binary was benötigt wird freigegeben.

Edit: Ursache bei Keyhelp ganz sicher nicht. Ursache im JailedSSH - und so eine Möglichkeit möchte ich niemals im Standard-Setup sehen

Ich habe es doch im Forum Probleme gepostet und nicht als Feature Request.. Damit solltest Du Dir bzgl. Standard keine Sorgen machen.

[mhagge]

Ist es dann nicht einfacher, das entsprechende Binary in den Jail aufzunehmen (gut, dann wäre es standardmäßig bei allen Usern drin - evtl. kann man sich selber eine Lösung basteln, wo das nur für diesen speziellen User in den Jail kopiert wird oder so)

Ich habe es doch im Forum Probleme gepostet und nicht als Feature Request.. Damit solltest Du Dir bzgl. Standard keine Sorgen machen.

Du hast es in das Forum Fehler/Probleme gepostet und in der Beitragsvorlage bejaht, dass die Ursache bei Keyhelp liegt. Es ist allerdings definitiv kein Problem, was irgendwas mit Keyhelp zu tun hat, sondern mehr eines zur Bedienung / Einrichtung eines JailedSSH

[mhagge]

Ich habe das Thema nun nach "Off Topic" verschoben

[Tobi]

sudo im SSH Jail ist wie der Fuchs im Hühnerstall.
Da kann man die Tür auch gleich offen lassen, braucht den User nicht zu jailen und die „Probleme“ haben sich erledigt .

[Jolinar]

Ich benötige für einen Kunden sudo in der eingeschränkten SSH Umgebung.

Magst du uns die Notwendigkeit vielleicht etwas näher spezifizieren? Eventuell gibt es ja einen eleganteren Lösungsansatz, der die Security nicht schwächt...

[space2place]

Gerne...
Angefangen hatte es damit das der Kunde folgendes meldete wenn er "git log" eingibt

git log
error: cannot run pager: No such file or directory

Darauf habe ich gebeten folgendes auszuführen:

git config --global core.pager ""

Hier kam dann auch eine Fehlermeldung:

error: could not lock config file //.gitconfig: Permission denied

Ok dachte ich mir.. Dann halt mit sudo. Also einen Sudo Eintrag für den User für das Command "git" erstellt.
Ich bin dann aber auf der Console "su - username" in den User gewechselt und habe das Command ausgeführt:

sudo git config --global core.pager ""

Nur ist es ja ein Unterschied ob ich mich per SSH mit dem User verbinde oder in der Shell in den User wechsel.

Also per ssh mit dem User verbunden und festgestellt das sudo mit git nicht funktioniert.

git log

funktioniert jetzt aber.

Das ist die Geschichte dahinter.

Gruß
Sascha

[24unix]

Also ich habe einfach den User, der git braucht zum Besitzer seines Home-Dirs gemacht.

[Tobi]

error: could not lock config file //.gitconfig: Permission denied

Diese Datei musst du als root anlegen und auf den User chmodden.

[space2place]

error: could not lock config file //.gitconfig: Permission denied

Diese Datei musst du als root anlegen und auf den User chmodden.

Das hatte ich auch schon gemacht... Nun habe ich die Datei nochmal manuell als root angelegt und dem User zugeordnet.
Der Inhalt lautet:

[core]
pager =

Damit sind die Meldungen nun verschwunden.
Ich werde den sudo Eintrag auch entfernen.. Das mit dem Fuchs und dem Hühnerstall ist schon richtig..

[Tobi]

Also ich habe einfach den User, der git braucht zum Besitzer seines Home-Dirs gemacht.

Ich möchte allen Usern ohne das nötige Hintergrund- und Fachwissen DRINGEND davon abraten irgendwelche Rechte innerhalb von KeyHelp zu verbiegen. Das kann im schlimmsten Fall dazu führen, dass die Webseiten und das Panel gleich mit dazu offline gehen!

[Tobi]

Damit sind die Meldungen nun verschwunden.
Ich werde den sudo Eintrag auch entfernen.. Das mit dem Fuchs und dem Hühnerstall ist schon richtig..

Freut mich, dass es nun funktioniert.

[OlliTheDarkness]

Also ich habe einfach den User, der git braucht zum Besitzer seines Home-Dirs gemacht.

Ich möchte allen Usern ohne das nötige Hintergrund- und Fachwissen DRINGEND davon abraten irgendwelche Rechte innerhalb von KeyHelp zu verbiegen. Das kann im schlimmsten Fall dazu führen, dass die Webseiten und das Panel gleich mit dazu offline gehen!

Lass doch biegen und brechen.

Wenn nichts mehr geht hilft ein beherztes rm -R / * als root User und alle Probleme sind gelöst.
Nicht vergessen wenn fertig nen reboot hinterher zu legen.
Safety first und so

[24unix]

irgendwelche Rechte innerhalb von KeyHelp zu verbiegen

Ich habe nicht irgendwelche Rechte verbogen, sondern den Benutzer zum Besitzer seines Home-Dirs gemacht.

Und ich habe nicht geschrieben, dass andere das nachmachen sollen, aber spaces2places traue ich durchaus zu zu verstehen, was er macht wenn er es macht wie ich.

Wenn man ängstlich ist, kann man das natürlich via sudo machen und dann mit chmod dem Benutzer zuschustern.

Und das ganze dann noch mit .pm2, .npm, .oh-my-zsh, .ssh, .config, .idea …

Es gibt auch Leute die mit dem Account produktiv arbeiten wollen.