Issue /bin/bash(chrooted) SSH suddenly denied for all domains

[AgBillings]

Previously all our web customers were setup to access their SFTP using the shell /bin/bash(chrooted). As of 2-17-17 it was working for everyone. The following Monday 2-20-17 it was not. This issue is affecting ALL domains that used /bin/bash(chrooted) as the shell.

When trying to connect via my ftp client cyberduck, FTP error: EOF while reading packet. Please contact your web hosting service provider for assistance.

When trying to connect via SSH on command line, error: Could not chdir to home directory /var/www/vhosts/domain.com: No such file or directory /usr/local/psa/bin/chrootsh: No such file or directory Connection to domain.com closed.

I can't find any record of any relevant updates to Plesk, I certainly didn't change anything. The only update I see in Plesk history is an update from PHP 7 to PHP 7.0.14. I've been doing some searching, what I found(in below examples, I replaced the actual username with "username" and the actual domain with "domain.com"):

1. The FTP user in /etc/passwd shows correctly as far as I can tell: username:x:10057:1004::/var/www/vhosts/domain.com:/usr/local/psa/bin/chrootsh
   
   
2. there have been no changes to user or group permissions. The user is correctly assigned to the psacln group, just like before.
   
   
3. The /var/www/vhosts/chroot folder has everything it needs as far as I can tell, and all permissions and ownership are correct.
   
   
4. I have tried the method from Plesk here: https://support.plesk.com/hc/en-us/...rams-to-a-chrooted-shell-environment-template, didn't work.
   
   
5. I have tried adding user-specific rules to the sshd_config file in /etc: Match User username ChrootDirectory /var/www/vhosts/chroot Then restarting sshd, no go.
   

I have no idea what else to check, and changing the shell to /bin/bash is not an option - besides the security risk we have customers with automated SSH connections that require the chroot for their file/folder pathways. My server support is stumped. Like I said, this was working just fine on friday Feb 17, then over the weekend sometime it broke and I can't figure out why :S

I would appreciate anyone's help!! Thank you.

 

[AgBillings]

Update, I ended up going into /var/www/vhosts/chroot and completely renaming the folder to "chroot_old". Then I reinstalled chroot using the chroot_update.zip from the link at plesk support. Still not working, so it seems I've at least ruled out that the issue is not there?

I also ran the plesk repair utility from this link: https://docs.plesk.com/en-US/onyx/a...epair-utility/plesk-repair-utility-web.74654/ and it found nothing related to my issue.

 

[weelow]

I had the same problem, and I tried this and it worked for me
https://support.plesk.com/hc/en-us/...-sent-publickey-gssapi-keyex-gssapi-with-mic-

 

[AgBillings]

Thanks for the reply weelow. While I don't think this particular method would help in my case, it does have some good troubleshooting techniques I wasn't aware of. To solve my problem, essentially chroot was reinstalled. I had another guy who knows way more than me do it, but I did ask him to try to summarize what he did so it might help anyone else who has to do the same thing:

1. Essentially, he took the executables that existed in the original CHROOT source directory & copied them to the CHROOT source directory I created when I ran the script from the Plesk docs above: https://support.plesk.com/hc/en-us/...rams-to-a-chrooted-shell-environment-template.

2. Then, he cleaned up any remnants of the original CHROOT environment in each account (e.g. removed the bin, sbin, etc and so on directories under the hosting account (/var/www/vhosts/somedomain.com)

3. Then, set shell to anything but the chroot option (in plesk -> subscription -> web hosting access) & save. Then, set the shell to chroot option (/bin/bash(chrooted)). This last item triggers commands to remove & add the chroot environment to the targeted directory.

I'm still in the process of doing step 2 and 3 for my remaining domains, but so far it has worked everytime. Hopefully that will help someone that has a similar issue.