wechseln per sudo in einen anderen Nutzer (Debian) [GELÖST]

[Stephan]

Ich habe für ssh Zugang einen speziellen User in Debian angelegt, der ausschließlich für Fernzugang via ssh (mit Key, ohne Passwort) gedacht ist. Nach dem Login wird gegebenenfalls mit su und root Passwort in den root User gewechselt.

Kann ich in einen Keyhelp User wechseln wenn dieser in der Keyhelp Userverwaltung kein ssh angewählt hat? Bisher hab ich es nicht hinbekommen.

Zum Hintergrund, ich möchte für die Nutzung vom Composer (für PHP Libraries Dependencies Verwaltung) in den Nutzer wechseln, für den Composer PHP Libraries installieren soll. Ansonsten soll der Nutzer aber keinen Fernzugang via ssh erhalten. Composer als root zu verwenden ist keine Option, da es zu Rechteproblemen mit den Libraries führt, wenn diese vom eigentlichen Keyhelp User verwendet werden und auch aus Sicherheitsgründen davon abgeraten wird.

Gruß,
Stephan

[Martin]

Hallo,

dies ist möglich wenn als root die Shell mit angegeben wird:

su - USERNAME -s /bin/bash

Damit wird die bei "kein SSH" eingestellte /bin/false Shell übergangen.

[Stephan]

Vielen Dank! so konnte ich von root in den gewünschten User wechseln.

Ergänzend:
das Composer Kommando "composer require xxxxx/libraryname" habe ich wegen der PHP open_basedir Beschränkung im Ordner /home/users/username/files/ ausgeführt, da dieser Ordner standardmässig in der Keyhelp Userverwaltung als open_basedir Ausnahme definiert ist. Dadurch wird dann der vendor Ordner und die Dateien composer.json und composer.lock im files Ordner angelegt. Zusätzlich habe ich den .composer ordner der vom Composer automatisch in /home/users/username/ angelegt wird in die Keyhelp open_basedir Einstellung angefügt (:##DOCROOT##/.composer)

Damit gibt es dann auch keine Fehlermeldungen mehr wenn ich den Autoloader in meine PHP Dateien einfüge.
require '../files/vendor/autoload.php';

Ich hoffe das ist alles richtig so. Ich denke das sollte jetzt so passen.

Gruß,
Stephan

[select name from me;]

Besser wäre vielleicht, Du schiebst alles eine Ebene weiter runter.
Einfacher zu nutzen und eher kompatibel mit zukünftigen Änderungen an keyhelp.

Code: Select all

[ ] /home/users/BENUTZER
 |- [ ] www
     |- [ ] composer.json 
     |- [ ] htdocs ( « auf diesen Ordner zeigt die Domain)
     |- [ ] vendor

[Stephan]

eigentlich zeigt die Domain auf den www Ordner. Daher wollte ich ja eine Ebene höher, damit vendor und composer.json nicht im Web abrufbar sind.

Besser wäre vielleicht, Du schiebst alles eine Ebene weiter runter.
Einfacher zu nutzen und eher kompatibel mit zukünftigen Änderungen an keyhelp.

Code: Select all

[ ] /home/users/BENUTZER
 |- [ ] www
     |- [ ] composer.json 
     |- [ ] htdocs ( « auf diesen Ordner zeigt die Domain)
     |- [ ] vendor

[Tobi]

Christians Struktur hat den Vorteil, dass man per FTP zugreifen kann und dass mehrere Domains dieselbe Source benutzen können.

[Stephan]

Ich bleibe mal bei der von Keyhelp vorgegebenen Struktur und ich habe, so wie es ist, durchaus mit FTP Zugriff auf die Ebene über www

Christians Struktur hat den Vorteil, dass man per FTP zugreifen kann und dass mehrere Domains dieselbe Source benutzen können.

[Martin]

Hallo,

in der Ebene über www/ sind für KeyHelp User keine Schreibrechte vorgesehen.

Für derartige Projekte wäre meine Empfehlung hier ebenfalls eine Struktur wie von Christian dargestellt.

[Stephan]

Hallo,

in der Ebene über www/ sind für KeyHelp User keine Schreibrechte vorgesehen.

Für derartige Projekte wäre meine Empfehlung hier ebenfalls eine Struktur wie von Christian dargestellt.

Vieleicht sehe ich ja den Grund nicht, warum man das nicht so machen sollte. Dann bitte ich um Aufklärung.

Ich halte mich doch an die Vorgaben von Keyhelp.
Der Ordner /home/users/username/files/ ist per default im Besitz von username:www-data und per default eingetragen in der Keyhelp Userverwaltung als open_basedir Ausnahme.

Warum sollte ich jetzt den aktuell verwendeten Pfad zu meiner Domain eine Ebene höher, nach dem bis dato nicht existierenden Ordner htdocs , verschieben und damit für meine Webanwendung verwendete absolute Pfade zerschießen?

So sieht der Ordner /home/users/username/ standardmäßig aus und die Domain zeigt standardmäßig auf den www Ordner.

drwxr-xr-x 7 root root 4096 Nov 27 00:40 .
drwxr-xr-x 12 root root 4096 Jan 24 11:08 ..
-rw-r--r-- 1 username 220 Mai 15 2017 .bash_logout
-rw-r--r-- 1 username username 3526 Mai 15 2017 .bashrc
drwxr-x--- 2 username www-data 4096 Nov 27 00:40 cgi-bin
drwxr-x--- 2 username www-data 4096 Nov 27 00:40 files
dr-xr-x--- 2 username www-data 4096 Apr 8 06:25 logs
-rw-r--r-- 1 username username 675 Mai 15 2017 .profile
drwxr-x--- 2 username www-data 4096 Nov 27 00:40 tmp
drwxr-x--- 2 username www-data 4096 Nov 27 00:41 www

Warum sollte ich nicht den Composer in den files Ordner installieren lassen? Solange der zusätzliche Order /home/users/username/.composer/ auch im Besitz von username ist und in der Keyhelp Userverwaltung als open_basedir Ausnahme eingetragen wurde, sollte der Zugriff darauf von PHP aus dem /home/users/username/www Ordner doch problemlos funktionieren.

zum files Ordner, siehe viewtopic.php?t=514
Warum sollte der files Ordner, der über dem www Ordner liegt also nicht genau dafür genutzt werden? Für files die nicht aus dem Web erreichbar sein sollen, aber im Zugriff der Webanwendung liegen sollen!? In dem Fall, von Composer verwaltete PHP Libraries.

Gruß,
Stephan