SFTP connection error...

Submitted by a10sth on Mon, 11/05/2018 - 02:49

I am going to reference a thread at the end of this, as it might be related.

Software Versions:
Operating system Ubuntu Linux 16.04.5 (Linux 4.4.0-138-generic on x86_64)
Perl version 5.022001
Path to Perl /usr/bin/perl
BIND version 9.10
Postfix version 3.1.0
Mail injection command /usr/lib/sendmail -t
Apache version 2.4.18
PHP versions 7.0.32, 7.2.11
Webalizer version 2.23-08
Logrotate version 3.8.7
MySQL version 5.7.24-0ubuntu0.16.04.1
ProFTPD version 1.35
SpamAssassin version 3.4.1
Webmin version 1.894
Usermin version 1.741
Virtualmin version 6.04
Theme version Authentic Theme 19.20-beta2

Once again this is a clean, fresh build.

When trying to update my production server with all the current updates, it broke all my websites to unresponsive, so I rolled back the updates.

I have just gotten the chance to re-build a fresh server (this one). While I am using DNS for a domain on it, that is as far as I am able to use it.

I am using chroot jails as before, but now upon creating any virtual server, I cannot log on SFTP or SSH as that admin user at all from the start, I immediately get a "SFTP connection error..." . I will state this, I have already looked at the items that we found that caused a similar issue before, it does not seem to be the same. But this is not my field, Please, Please double check me.

Jamie, The login details you have from before are valid for this re-build. Please help.

Jamie, I made one observation, the 1st virtual server (domain) I created, and when I went back to look at

/etc/webmin/virtual-server/domains/domain-id

for

unjailed_shell=/bin/bash

the unjailed_shell=/bin/bash line was not there. I put it in, rebooted the server, and still the lovely "SFTP Connection Error..." and can't log in via SSH as the Virtual Server admin user(s) or with a sudo user can't "SU" to the user either.

I specifically stated the 1st, because the 2nd one I created had the unjailed_shell=/bin/bash in the corresponding file.

the main passwd file in /etc looks fine to me, and also the one in the /home/chroot/jailed-id/etc/passwd file looks fine as well.

Really look forward to getting this fixed once again. I have not been able to test anything else since I have been unable to upload anything (as to my production server problem with all websites going blank on server update possibility)

I did disable the Fail2Ban on the server while this issue is being troubleshoot

Appreciate any help I can get with this issue

and as I stated above, I would post to the previous post that might have something to do with it.

https://www.virtualmin.com/node/56915

Status: 
Active

Comments

Submitted by marcelorp on Mon, 11/05/2018 - 06:29

Did you have access to the logs of access/auth? And tried to disable the Firewalld?

Submitted by a10sth on Mon, 11/05/2018 - 10:22

Yes i have logs, and disabling the Firewalld does nothing. What does do something, strangely enough, is disabling the chroot jails and creating a user (not using the chroot jails). I did mention that I believed this to be similar to the previous thread, but a bit more aggravating. This problem does have the root cause from chroot jails some how.

In truth, the other reason I was waiting so long to rebuild it was for hopeful support for Ubuntu 18.04

Thank you so much for your reply.

Submitted by a10sth on Mon, 11/05/2018 - 14:36

Here is the expert from the auth log:

Nov  5 15:23:18 host9 sshd[30711]: Connection closed by ORIGIN-IP-ADDY port 16393 [preauth]
Nov  5 15:23:18 host9 sshd[30935]: Accepted password for AFFECTED-USER from ORIGIN-IP-ADDY port 26147 ssh2
Nov  5 15:23:19 host9 sshd[30935]: pam_unix(sshd:session): session opened for user AFFECTED-USER by (uid=0)
Nov  5 15:23:19 host9 systemd-logind[924]: New session 188 of user AFFECTED-USER.
Nov  5 15:23:19 host9 systemd: pam_unix(systemd-user:session): session opened for user AFFECTED-USER by (uid=0)
Nov  5 15:23:19 host9 jk_chrootsh[30977]: now entering jail /home/chroot/15413771693350 for user AFFECTED-USER (1003) with arguments -c /usr/lib/openssh/sftp-server
Nov  5 15:23:19 host9 jk_chrootsh[30977]: abort, failed to get group information in the jail for group ID 1003: Success, check /home/chroot/15413771693350/etc/group
Nov  5 15:23:19 host9 sshd[30976]: Received disconnect from ORIGIN-IP-ADDY port 26147:11: Session closed ok
Nov  5 15:23:19 host9 sshd[30976]: Disconnected from ORIGIN-IP-ADDY port 26147
Nov  5 15:23:19 host9 sshd[30935]: pam_unix(sshd:session): session closed for user AFFECTED-USER
Nov  5 15:23:19 host9 systemd-logind[924]: Removed session 188.
Nov  5 15:23:19 host9 systemd: pam_unix(systemd-user:session): session closed for user AFFECTED-USER

This happens no matter what, If I am on the same network, VPN or through the firewall with port forwarding. I have a production server setup the same way, working. So I know it is not my firewall, or the firewall built into Virtualmin / Ubuntu. This comes from me disabling the Chroot Jails on a user and SSH and SFTP works with no issue.

below is an exerpt from the syslog for the time frame

Nov  5 15:23:19 host9 systemd[1]: Created slice User Slice of AFFECTED-USER.
Nov  5 15:23:19 host9 systemd[1]: Starting User Manager for UID 1003...
Nov  5 15:23:19 host9 systemd[1]: Started Session 188 of user AFFECTED-USER.
Nov  5 15:23:19 host9 systemd[30937]: Reached target Timers.
Nov  5 15:23:19 host9 systemd[30937]: Reached target Sockets.
Nov  5 15:23:19 host9 systemd[30937]: Reached target Paths.
Nov  5 15:23:19 host9 systemd[30937]: Reached target Basic System.
Nov  5 15:23:19 host9 systemd[30937]: Reached target Default.
Nov  5 15:23:19 host9 systemd[30937]: Startup finished in 16ms.
Nov  5 15:23:19 host9 systemd[1]: Started User Manager for UID 1003.
Nov  5 15:23:19 host9 systemd[1]: Stopping User Manager for UID 1003...
Nov  5 15:23:19 host9 systemd[30937]: Failed to enqueue exit.target job: Access denied
Nov  5 15:23:19 host9 systemd[1]: Stopped User Manager for UID 1003.
Nov  5 15:23:19 host9 systemd[1]: Removed slice User Slice of AFFECTED-USER.

Again, I thank you for your time, and I hope to see this issue fixed soon.

Thank you,

Submitted by marcelorp on Mon, 11/05/2018 - 15:28

You can login into with root credentials, right? How did you implement the jailkit?

Submitted by a10sth on Mon, 11/05/2018 - 15:36

I can access SSH, but I cannot access SSH via the virtual server admin users which I should be able to do. Chroot Jails is built right into Virtualmin. This is the reason that I have posted here.

there are some things that is useful if not down right necessary to be able to log in via SSH or SFTP as the owner of the domain so that permissions stay correct and I do not have to go and correct permissions on 45 different users.

I would like to use the product as it is intended, not have to workaround and make my life harder. I have Chroot Jails enabled as a layer of security and do not intend to disable them. Jamie would have a really hard time helping, when he gets a chance if I was unable to create a sudo user for him.

I do appreciate your response

Thank you,

Submitted by marcelorp on Mon, 11/05/2018 - 16:14

Hmm...I really dont known what is that problem...I have virtualmin but I dont remember to activate the chroots jail.

Did you go under 'FTP Directory Restrictions' and recheck the configs? Did you use the virtual SFTP offered by ProFTP to connect your users under SSH? On port 2222?

Submitted by a10sth on Mon, 11/05/2018 - 19:28

Chroot jails is installed by default. Go to the System Settings --> Server Templates ---> edit a template and on the "Administration user" drop down, you will see "Chroot jail new domain Unix users?" Yes or No. The template you edit has to be either the "Default Settings" or one with "For use by... Top-level virtual servers" checked.

Thanks,

Submitted by a10sth on Wed, 11/07/2018 - 22:24

Just checking if anyone has been able to look into this yet. A little surprised to not have heard from Jamie yet.

I really do look forward to hearing from someone, with a reason of why this is happening and hopefully a solution.

Submitted by a10sth on Fri, 11/09/2018 - 23:11

Category: Support request » Bug report

Submitted by JamieCameron on Sat, 11/10/2018 - 12:50

Ok I know what the cause of this error is - it's a bug in the current Virtualmin release that we'll fix in the next version.

Submitted by a10sth on Sat, 11/10/2018 - 16:31

Thanks Jamie, How close is the next release? Anyway to tell me what needs to be changed so I can use this soon?

As always, love the product, and I look forward to hearing from you soon.

Thank you,

Submitted by JamieCameron on Sat, 11/17/2018 - 03:50

Should be happening this week.

Submitted by niko on Wed, 11/28/2018 - 06:22

Hi ! Posting for following the post.

In case it is useful, it is actually not working because the group is not added in /home/chroot/[big_number]/etc/group Adding the corresponding group in this file make everything work.

  1. $> cat /etc/group | grep [alias]
  2. add the result of 1 at the end of the file /home/chroot/[big_number]/etc/group

Hope it helps!

Submitted by a10sth on Wed, 11/28/2018 - 07:16

Niko,

Thank you so much, I can finally move everything from my production server to the new server.

Any clue as to when the 6.05 version comes out that will fix this on new users?

Submitted by niko on Wed, 11/28/2018 - 07:29

you welcome!

In bash, you can automate it like that :

virtualmin modify-domain --domain ${DOMAIN} --enable-jail

DOMAIN_ID=$(virtualmin list-domains --domain ${DOMAIN} --id-only)

cat /etc/group | grep ${ALIAS} >> /home/chroot/${DOMAIN_ID}/etc/group