Hello, This question refers to section 4.6.4 ‘Command Line’ (pages 165–166 of the manual). The documentation presents Jailkit as a standard way to confine remote users. Could you clarify the expected behaviour regarding SSH authentication in this context? —Is SSH authentication (key or password) expected to work reliably with chrooted remote users using Jailkit? —Or should Jailkit mainly be considered a confinement mechanism whose behaviour may depend on the environment and is not guaranteed in all cases? Thank you for the clarification.
Jailed SSH users work reliably and in the same way as non-jailed users work. The jail is enforced by the jailkit shell, which is set for the user in /etc/passwd, so authentication happens before the user is jailed.
Sorry for reviving old thread, but in that matter I'd like to ask if those .ssh/authorized_keys in shell-users home-dirs matter anything. Or more precisely if a website is hacked but executing a chrooted/jailed PHP script, can hackers modify non-jailed user .ssh/authorized_keys and thus obtain a non-jailed shell with a terminal ?
They can not modify the authorized_keys of SSH users of other sites, no matter if jailed or not. But if you have multiple SSH users in one site, then you must jail them all as all users of a site share the same UID.
Thanx Till, Apology, now when I read my self in my previous message, I become to realize that I wasn't clear enough in my question. To clarify, I was aware that shell-users cannot modify .ssh/authorized_keys of the shell-users of another website. What I was concerned is that if one website has a mix of non-jailed, and jailed users, then the jailed users (more precisely the most-vulnerable jailed-PHP-processes) can modify non-jailed users .ssh/authorized_keys of the same website. If that is correct, then indeed what you said "you must jail them all as all users of a site share the same UID" -> is the only solution to prevent non-jailed intrusions. In other words: allowing a website to have at least one non-jailed shell-user is a bad practice, regardless if the owner of the credentials of this non-jailed shell-user is trusted or not?
Yes. All shell users of a site have to share the same UID, they won't be able to edit website files with the right UID otherwise. But this also means that one shell user is able to edit files of another shell user of this site.
Ok. Thank you. I've made an ISPConfig extension which targets exactly this weakness (allowing jailed to edit the files of non-jailed(if any)). And I request to publish it in "Plugins/Modules/Addons" as a new thread. Much is explained, and is fully documented. I pretty much prepared my posting, just asking for permission. github.com/talutahelan-star/ispconfig-advanced-jailkit-tools/tree/main I am more inclined to think that this new extension (in its current state), is more usable for admins/orgs that spin ISPConfig to host and manage their own PHP websites, rather than shared hosting service for fully untrusted clients. But everyone will read and check if it meets their needs, because it is comprehensively documented. And it is MIT license, so one can decide to rewrite it to make it fit shared hosting services needs also.
Sure, feel free to make a post in Plugins/Modules/Addons forum. Basically, as a hoster, you would set the client limits to allow only jailed users, so your client cannot create any non-jailed users in such a setup.