Issue with FTP-like access for migrated domains

I have set up a new Pro server. Virtual servers added to it are set up with SFTP by default. This works.

I just migrated a bunch of domains from an older (but updated and current) Pro server that used FTPS by default. I can access these domains on the new server via plain FTP and FTPS, but I cannot access them via SFTP.

If I try and set up an SFTP jail for a migrated domain, nothing FTP-related works at all. The logs in Filezilla appear to imply that the user name and password are wrong, but I reset the password through Edit Virtual Server -> Configurable settings and this changes nothing. There is no way to change the password at Edit Users.

Simply put, I was delighted when I found that Virtualmin's implementation of SFTP worked properly on the new server, but it's broken on migrated domains, and trying to fix it on a migrated domain completely borks all FTP-like access. I want to figure out how to do it, or do it properly.





Howdy -- thanks for contacting us!

For the accounts where you're having trouble logging in via SFTP, what shell are they using?

From Administration Options -> Edit Owner Limits -> Other restrictions, a completely broken domain that I tried to fix has "Email, FTP and SSH" selected from the drop-down, with "Chroot jail domain Unix user?" marked "Yes". /ets/passwd shows /home/chroot/149805397720821/./home/aeszambi:/sbin/jk_chrootsh .

A migrated domain that I have not tried to fix has "Email and FTP", with "Chroot jail domain Unix user?" set to "No". /etc/passwd shows /bin/false.

Is there somewhere else I should be checking this?

Now that I think of it, this is probably tangentially connected to my ticket about features, plans and templates.

When you say "SFTP" do you mean file access over SSH, or the regular FTP protocol in encrypted mode?

I mean the terms as they are defined, as far as I know:

  • SFTP: SSH File Transfer Protocol (so your first option)
  • FTPS: File Transfer Protocol over SSL (your second option)

Am I confused? Or have I confused the issue? I tried to be very precise.

OK, I see now - some users say "SFTP" when really they mean FTPS.

Anyway, as I understand it, for SFTP to work, the user's shell needs to be set to something that allows file access but not running arbitrary shell commands. What gets logged to /var/log/secure when you try a SFTP login and it fails?

Well, I did use both terms in one sentence in the OP, so I don't see how they could have been referring to the same thing. Anyway, moving on.

Here is what you asked for:

Oct  8 03:00:38 nc041 sshd[27830]: Accepted password for aeszambi from port 34697 ssh2
Oct  8 03:00:38 nc041 sshd[27830]: pam_unix(sshd:session): session opened for user aeszambi by (uid=0)
Oct  8 03:00:39 nc041 sshd[27830]: pam_unix(sshd:session): session closed for user aeszambi
Oct  8 03:00:45 nc041 sshd[27836]: Accepted password for aeszambi from port 44077 ssh2
Oct  8 03:00:45 nc041 sshd[27836]: pam_unix(sshd:session): session opened for user aeszambi by (uid=0)
Oct  8 03:00:45 nc041 sshd[27836]: pam_unix(sshd:session): session closed for user aeszambi is my workstation's IP address.

Any response to the information you asked for that I provided?

Only asking to be sure for yourself.

SFTP only username password or with key's. OLD box <> new box

Hi Jfro,

While I appreciate your response, I am directing my support request to the vendor of Virtualmin, not to you. Thanks.



Is there any additional information you need from me to address this question? I'm confused by the fact that there has been almost two weeks of silence.

I realise that there is no way for Virtualmin to read my mind and know that I would prefer SFTP over FTPS for migrated virtual servers that used FTPS on the old server. However, I don't understand why Virtualmin is breaking all FTP-like access when I use it to try and change the access from FTPS to SFTP for a migrated virtual server, and I especially don't understand why plain FTP (which intentionally did not work on the old server) is now explicitly allowed on the new server to which the virtual server was migrated. In fact, the latter alone would seem to me to be a security bug.

I've currently paused a migration pending resolution of this issue, but I'm going to have to go ahead and complete the migration and hope that you can either tell me how I've used Virtualmin incorrectly, or how Virtualmin expects me to use it to accomplish what seems logical to me.



Is this only a problem for domains with a jail enabled? And are you setting up that jail using Virtualmin's built-in support?

Hi Jamie,

To answer your second question first, I do pretty much anything on a Virtualmin server through Virualmin if I can unless it's faster or more efficient on the command line and I'm working outside of the Virtualmin configuration (e.g., tailing logs). It would be disingenuous of me to come here looking for support for Virtualmin and not tell you that, oh by the way, I ran rm -rf /home and now "Vitualmin has broken everything." Not trying to be snarky, but please don't assume I'd break something on the command line and then come here and blame Virtualmin.

So yes, the jails I have set up on new virtual servers on the new server are all set up using Virtualmin. As I said in my original post, I was delighted to see that jailed SFTP works on the new server (thanks to Virtualmin) when it didn't work to my satisfaction on the old server when I set it up about two years ago.

To answer your first question, as far as some kind of secure FTP-like access is concerned:

  • I am having no problems with new virtual servers that are set up with SFTP and a jail by default,
  • I am having problems with migrated domains (migrated from an old but current Virtualmin server) in two areas:
    • Plain FTP access now works even though I do not want it to and I did not configure it anywhere (that I'm aware of), and
    • If I try to set up an SFTP jail on a migrated domain all FTP-like access (SFTP, FTPS and plain FTP) breaks. (Since it has been three weeks now, I'd have to do this again to make notes on exactly what I did if you need to know.)
  • FTPS and plain FTP access on a new domain do not work, but that's the way I want it so that's good!

So I suppose this ticket is part bug report, part support request:

  • The bug report is that plain FTP starts working on a migrated domain when it was explicitly not allowed on the server from which it was migrated.
  • The support request is two-fold:
    • Is there a way for me to convert a migrated domain from having FTPS access to having jailed SFTP access? (If there is no straightforward way to do it within Virtualmin then I'll leave migrated users with FTPS access, but it's not ideal for me for my user base to have two different ways to use FTP-like access and have to remember or check which access a user has when they ask for support.)
    • How can I disable plain FTP access on a migrated domain?

I hope I've provided enough detail to move this forward. Thanks.


Can you check what the shells are for the users for which FTP, FTPS and SFTP does and does not work?

Generally the shell is used to control which users can login via FTP(S), and for SFTP if the shell is set to something that doesn't exist in the chroot jail it's not going to work.

Is this question different to the one asked of me in message #1 that I answered in message #2?

Yes, for jailed users, what is their shell set to in the /etc/passwd file inside the chroot?

I tried to answer this question with a Markdown table, but my Markdown is not interpreted. Your instructions at point to , but the instructions in the "Tables" section at that URL do not work on your website.

I also can't upload a screenshot attached to this comment, so here's a screenshot of my post that will hopefully make my tables relatively clear.

Here is the text of my attempted post:

OK, in answer to message #13:

DOES work DOES NOT work FTP USER1:x:1027:1027:NAME1:/home/USER1:/bin/false USER2:x:1031:1031:NAME2:/home/chroot/15721293756270/./home/USER2:/sbin/jk_chrootsh FTPS USER1:x:1027:1027:NAME1:/home/USER1:/bin/false USER2:x:1031:1031:NAME2:/home/chroot/15721293756270/./home/USER2:/sbin/jk_chrootsh SFTP USER2:x:1031:1031:NAME2:/home/chroot/15721293756270/./home/USER2:/sbin/jk_chrootsh USER1:x:1027:1027:NAME1:/home/USER1:/bin/false

The references to FTPS are all "explicit FTP over TLS". "Implicit" doesn't work at all, which is just fine.

To be clear about what is desirable and what is not desirable, with reference to the above table:

 | DOES work                                     | DOES NOT work

---- | --------- | ------------- FTP | NOT desirable (i.e., I desire it NOT to work) | Desirable (i.e., I desire it NOT to work) FTPS | NOT desirable | Desirable SFTP | Desirable | NOT desirable (i.e., I DESIRE it to work)

USER1 is a user imported from the old server; USER2 is a new user set up on the new server, which works exactly as I'd like all users on the server to work. I'd like to refer you back to message #12 for a detailed explanation of what I'm asking for here, in terms of what I think must be a bug and what support I'm actually asking for.

I understand what you mean in the second paragraph ("Generally the shell is used to control ..."), but I'm only working within Virtualmin here so whatever is in /etc/passwd is put there by Virtualmin.



Jamie, I keep providing the information you ask for, and then you keep not following up. It did occur to me that perhaps you are/were trying to reproduce my situation on development and testing installations, but if you are you certainly haven't told me or given me any time lines, and this ticket has now been open and unresolved for over a month, with my last providing information you asked for over a week ago.

Can we please resolve this issue? Thank-you.

And another week comes to an end with no response from Virtualmin.

Sorry, I meant to follow up on the shells question .. taking a look now.

By the way, in comment #15, what I was referring to is the file /home/chroot/15721293756270/etc/passwd . Yes, this is generated by Virtualmin, but it would still be useful to see what it contains.

So, let's take a look at this in two parts, since the issue of FTP working when it shouldn't and SFTP not working when it should are mostly separately.

For regular FTP or FTPS, these are handled by the ProFTPd server. Per-user access is controlled by their shell, which has to be in the /etc/shells file. It looks like all the users you don't want it working for have /bin/false as the shell, which I assume is in /etc/shells on your system?

The catch is that the sftp server also uses /etc/shells for access control, so denying FTP while allowing SFTP is a little tricky. Come to think of it, do you ever need to access your system via FTP or FTPS as any user? If not, one possible fix is to just shut down ProFTPd.

Ah, I didn't realise you were referring to /etc/passwd within the chroots. I thought you were asking about the /etc/passwd file in the root file system.

The contents of /home/chroot/15721293756270/etc/passwd are as follows:

[13:49:12 root@server ~]# more /home/chroot/15721293756270/etc/passwd
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
systemd-network:x:192:192:systemd Network Management:/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
rpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/sbin/nologin
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
dovecot:x:97:97:Dovecot IMAP server:/usr/libexec/dovecot:/sbin/nologin
mysql:x:27:27:MariaDB Server:/var/lib/mysql:/sbin/nologin
USER:x:1031:1031:CLIENT NAME:/home/USER:/bin/bash
[13:49:14 root@server ~]#

/etc/shells looks like this:

[13:52:33 root@server ~]# more /etc/shells
[13:52:42 root@server ~]#

Yes, a quick scan of /etc/passwd seems to show that the vast majority of users have /bin/false set as their shell. This is because the vast majority of users were imported from the old server where they were configured to use FTPS. I would love to shut down ProFTPd and only allow access via jailed SFTP, but I can't because of all these imported/migrated users.

So that was why I was looking for a way to somehow "convert" the migrated users from using FTPS to use SFTP. However, it's looking like a straight "conversion" (so to speak) is either not possible or not worth the effort.

So that leaves me with the less-than-ideal (but tolerable) situation of having some users using FTPS and some using SFTP. What I would still like to accomplish though is disabling plain FTP for those users left using FTPS.

Is that possible?

If you're OK with shutting down ProFTPd entirely and thus turning off FTP / FTPS, the next question is why SFTP isn't working. Do all the users that were created anew on the new system have /sbin/jk_chrootsh as their shell?

If so, does switching a migrated user to turn on a chroot also fix the SFTP problem? (Apologies if you mentioned this above already, or if it was rejected because it would cause other problems).

If that doesn't help, is there a difference for working vs. non-working between the shell set for the domain user in the /etc/passwd file under the chroot?

More apologies for dropping the ball on this ticket too.

Do all the users that were created anew on the new system have /sbin/jk_chrootsh as their shell?

Off the top of my head I'd say yes. Is there a list in Virtualmin of all of the virtual servers using Server Template X? If there is I can compare against a list grepped from /etc/passwd.

... does switching a migrated user to turn on a chroot also fix the SFTP problem?

Umm, where do I do this? There doesn't seem to be such an option at Edit Virtual Server or under Edit User -> USER.

You can get the list of domains on a template from the command line, with a command like :

virtualmin list-domains --template "Template name" --name-only

The chroot option for existing domains is at Administration Options -> Edit Owner Limits, under "Other restrictions"

I feel like I'm running into new obstacles here. I have two Server Templates, one I created that was renamed by the process of importing the virtual servers (and Server Template) from the old server. I set up the new server and created Template A. When I imported virtual servers from an older server Virtualmin renamed Template A to Template B, and created a new Template A. (I referenced this in ticket .)

Anyway, I used virtualmin list-domains --template "Template A" --name-only to list the virtual servers using that template and virtualmin list-domains --template "Template B" --name-only to list the virtual servers using that template. They both produced the same list of the same virtual servers, and the list was only about a tenth of the virtual servers on the system. Only when I used the ID numbers of the templates (e.g., virtualmin list-domains --template 156679030620318 --name-only) that I got from the URLs in my web browser did I get correct lists. Well, almost correct. One virtual server was not listed under either Server Template, but is listed in the full list. It, of course, does have a Server Template. This is a mystery to me, especially as it's also listed at Virtualmin -> List Virtual Server. Any ideas why it wouldn't appear in either of the lists by Server Template?

Anyway, to re-answer your questions in comment #23:

Do all the users that were created anew on the new system have /sbin/jk_chrootsh as their shell?

Oddly, no. All but two users created anew have /sbin/jk_chrootsh as their shell. I can't explain why those two don't, considering they were both created with Server Template B, which is supposed to chroot/jail new users. However, I don't want to get sidetracked by this anomaly; I'll blame it on myself.

So we're back to the main problem of this ticket. I tried what you suggested ("... does switching a migrated user to turn on a chroot also fix the SFTP problem?") and now I cannot use anything -- plain FTP, FTPS or SFTP -- to log in as the user I changed, although the chroot was created and I can log into Virtualmin as the user.

If that doesn't help, is there a difference for working vs. non-working between the shell set for the domain user in the /etc/passwd file under the chroot?

I'm not sure I follow you here, so I compared the /etc/passwd files under the chroots for a working user vs. this non-working user:

[08:11:17 root@server ~]# diff /home/chroot/157485088313436/etc/passwd /home/chroot/149805397720821/etc/passwd
< WORKING_USER:x:1088:1087:NAME:/home/WORKING_USER:/bin/bash
> BROKEN_USER:x:1089:1088:NAME:/home/BROKEN_USER:/bin/false
[08:11:49 root@server ~]#

Does that help?

Sorry it sometimes takes me days to answer. It can take hours to put my replies together.