Jailed SSH Issues - Problems with /etc/group

13 posts / 0 new
Last post
#1 Tue, 10/09/2018 - 10:03

Jailed SSH Issues - Problems with /etc/group

I've got a pretty much clean, unmodified Virtualmin / Webmin instance running on a fresh Ubuntu 16.04 server. Everything seems to be working great, except for jailkit functionality. I have 5 different virtual servers running now, 4 of which have a website. I also have email running for one domain. All 4 sites are database driven as well.

Everything seems to be working correctly and running great, except for jailed SSH. Anytime I try to log in through SSH as a Virtualmin server admin, it fails. The only thing that works is my main administrator login for the actual server itself. A few notes:

  • I run SSH on a non-default port
  • SSH is enabled on the server, and the users I'm trying to log in as have SSH access granted
  • I get this error in my /var/log/syslog when trying to SSH as a user that doesn't work: "abort, failed to get group information in the jail for group ID 1005: Success, check /home/chroot/15386910117794/etc/group".
  • The main /etc/passwd and /etc/group files look fine, however the chrooted clones don't. The /etc/passwd file looks right, but /etc/group is missing an entry for the user. If I manually add this entry, I can connect just fine

So it appears that the proper /etc/group info isn't being copied over when a new virtual server is spun up. The jail is created and files are copied over, but the /etc/group file that lives inside of this new jail doesn't have the proper entries required to make this work. This means that every single domain ends up needing manual intervention. Has anyone had a similar issue, or know of any way to go about fixing this?

Mon, 10/15/2018 - 11:22

Just a quick bump here. Is anyone else having issues with jails on Ubuntu? This was all a clean install, so I'm not entirely sure what would be going on here...

Thu, 10/18/2018 - 17:35

Exact same issue here on Debian 9.

Fri, 11/02/2018 - 10:26

Same here, using debian 9, i can connect with the sudoers , but i cant' with a standard virtualmin user

Sat, 11/17/2018 - 10:50

I'm having the exact same issue... has anyone found a solution to this yet?

Sat, 11/17/2018 - 14:28

I have yet to find a solution to this. My only temporary fix has been to disable jails for any environments that I actually need SSH access to. As the server administrator, this is an alright stop gap solution for me, however it prevents me from being able to feel comfortable distributing SSH / SFTP access to users. I do understand that jails are just a false sense of security anyway, however for most of my shared hosting clients it would be nice to provide access, and if they were able to see other sites on the same server it would certainly set off alarm bells in their heads. It's not so much for my own security as it is to make my clients feel more secure in their environment.

Point is, if you don't publicly distribute SSH creds to users, you can get away with turning off jail functionality for the domain in question, which will at least allow you to SSH in with proper permissions. If you plan on distributing SSH creds, however, then this will require a formal fix in core more than likely. The fact that we now have four separate reports of the same issue on different operating systems shows that this is indeed somehow a bug and not a one off issue with configuration.

Maybe with any luck, someone with more knowledge and the ability to fix these bugs and publish those fixes will weigh in here :)

Wed, 11/28/2018 - 11:25

same problem here, why integrate a functionality that is broken out of the box ..

Thu, 11/29/2018 - 02:58

Same here on Debian 9 out of the box installations.

Thu, 11/29/2018 - 05:18

my debian9 installation is on an uprivilegied LXC container, is it the source of the problem ?

Thu, 11/29/2018 - 05:22 (Reply to #9)

Nope, it happens on dedicated servers as well. The problem comes from the /etc/group file which is not correctly set up in the different jails.

Sat, 12/22/2018 - 11:59

I got same problem - Debian 9.

Will this be resolved?

There is quick and easy workaround:

cd /home/chroot; for i in $( ls ); do cp /etc/group $i/etc/group; done
Tue, 01/29/2019 - 13:26

Just wanted to check in to see if we have the attention of any administrators that would be equipped to patch this issue up. This seems like a relatively quick core fix, and the initial ticket was submitted three months ago now. Any news or updates?

Fri, 10/11/2019 - 02:23

no update yet i think? i am still experiencing this problem on fresh 16.04 install ;c

Topic locked