• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue unable to connect to ftp/ftps but can connect to sftp & no chroot

Nessy

New Pleskian
Hello !

I have a new VPS server running plesk obsidian 18.0.33 / Ubuntu 20.04.2.
I want to have severals chrooted ftp users but I run into some problems after setting up my first test user :
It's impossible to connect to FTP/FTPS on port 21. I checked that the firewall let inbound traffic on that port and that the FTP settings in Plesk gave access to both FTP & FTP/TLS. On the other hand, connecting to port 22 via SFTP is possible but expose the whole system ( I start on the home directory, but have access / ).
I checked the proftpd.conf file but it is the same as described in FTP and it should chroot every user in the psacln group.
Using FilleZilla I got :
Status: Connecting to ...someIP...:21
Status: Connection established, waiting for welcome message...
Error: Connection timed out after 20 seconds of inactivity
Error: Could not connect to server

I tried on different computer using different network connection with the same issue.
Any help is welcome !
 
...On the other hand, connecting to port 22 via SFTP is possible but expose the whole system ( I start on the home directory, but have access / )
We don't use FTP at all. Only STFP with access only from certain IP addresses and only via Public/Private Keys NOT password (which is disabled). If your Plesk user access rights / SSH /Chroot SFTP / user rights etc are all setup correctly (takes a bit of time and forethought) then you can avoid any of the full access issue that you've mentioned above with SFTP. However, this setup is on our own server, not VPS which might make a slight difference...
...I checked the proftpd.conf file but it is the same as described in FTP and it should chroot every user in the psacln group
We intentionally, don't use proftp at all (see above)
...Using FilleZilla...
Is what we do, but with SFTP only as described in the 1st paragraph.
As you've stated, your intention is to use FTP not SFTP anyway, but those items just FYI, if, for whatever unlikely reason, you decide to give up with FTP.

You've not stated who your Hosting your VPS with, but the previous post ^^ would definitley be your 1st check anyway but then maybe, just double check that your Hosting Company have not blocked port 21 by default i.e. Not your Plesk Obsidian Firewall but your Hosting Company's Firewall. That's pretty unlikely but worth checking, as many do block port 25 by default - as an example.
 
Last edited:
Is the FTP service running, and bound to 21?

Try telnet <ip> 21
Thanks for your help !

I could not use telnet (not available on my computer), but using a terminal (KiTTY) to reach my IP with telnet-port 21 gave no result (no response from the server).
To check if the ftp server was active, I tried service xinetd status logged as root and it gave me :
● xinetd.service - LSB: Starts or stops the xinetd daemon.
Loaded: loaded (/etc/init.d/xinetd; generated)
Active: active (running) since Fri 2021-03-12 13:50:04 UTC; 1 day 1h ago
Docs: man:systemd-sysv-generator(8)
Tasks: 1 (limit: 2281)
Memory: 6.3M
CGroup: /system.slice/xinetd.service
└─1209 /usr/sbin/xinetd -pidfile /run/xinetd.pid -stayalive -inetd_compat -inetd_ipv6


so I guess the service is running, to check if port 21 is open, I used netstat -a -p |grep ftp and got :
tcp6 0 0 [::]:ftp [::]:* LISTEN 1209/xinetd

Is there something else I can do to diagnose the problem ?
 
We don't use FTP at all. Only STFP with access only from certain IP addresses and only via Public/Private Keys NOT password (which is disabled). If your Plesk user access rights / SSH /Chroot SFTP / user rights etc are all setup correctly (takes a bit of time and forethought) then you can avoid any of the full access issue that you've mentioned above with SFTP. However, this setup is on our own server, not VPS which might make a slight difference...

We intentionally, don't use proftp at all (see above)

Is what we do, but with SFTP only as described in the 1st paragraph.
As you've stated, your intention is to use FTP not SFTP anyway, but those items just FYI, if, for whatever unlikely reason, you decide to give up with FTP.

You've not stated who your Hosting your VPS with, but the previous post ^^ would definitley be your 1st check anyway but then maybe, just double check that your Hosting Company have not blocked port 21 by default i.e. Not your Plesk Obsidian Firewall but your Hosting Company's Firewall. That's pretty unlikely but worth checking, as many do block port 25 by default - as an example.

Thank you for your help.
I am OK with using sftp. What I basically want is to give access to several user to their folders and subfolders (which are part of website), but no access to the server internals. So I figured out that I need chrooted user, but don't know how to achieve this.
Could you explain me how to setup users rights for this (note that I can't restrict access to certain IP adresses because my users will connect from various (and not known) IPs).
I will do some research about my hosting compagny to see if they block port 21 as you suggested.
 
So I figured out that I need chrooted user, but don't know how to achieve this. Could you explain me how to setup users rights for this (note that I can't restrict access to certain IP adresses because my users will connect from various (and not known) IPs).
You're happy with SFTP and required choorted users. Great, well there's no need to replicate what has already been posted, in detail by others. All you've go to do is search, apply, test, modify, test & retain - based on one of many, already available online guides / references / fault-fixes. If you want to start with Plesk iteself: SFTP does not restrict user to the subscription's directory and/or then just search for say sftp chroot if you want external references, as there's plenty!
 
You're happy with SFTP and required choorted users. Great, well there's no need to replicate what has already been posted, in detail by others. All you've go to do is search, apply, test, modify, test & retain - based on one of many, already available online guides / references / fault-fixes. If you want to start with Plesk iteself: SFTP does not restrict user to the subscription's directory and/or then just search for say sftp chroot if you want external references, as there's plenty!
In fact, I had already tried the link that you provided with no results before posting here. When I connect with a SSH terminal, my subscription user is indeed chrooted, but when the same user uses SFTP he isn't. The various pages I visited didn't help me, maybe because there are issues related to both plesk and the sftp-server ?
 
......maybe because there are issues related to both plesk and the sftp-server ?
Well maybe it's the local config of both your Plesk / SFTP Server as opposed to those items generically having issues?

Moving on, do you mean, that when you runs tests, as per that previously mentioned Plesk page, your results are as follows:
/bin/bash (chrooted) is selected as a shell in the Domains > example.com > Access to the server over SSH.
Plus, when logged into SSH, as that ^^ same speciifc chrooted user, your SSH double-check, prodcuces results, exactly as follows:
$ echo -n 'SFTP restrictions '; [[ -e /httpdocs ]] && echo 'active' || echo 'inactive'
SFTP restrictions active
But, if you SFTP wehn logged in to Filezilla as that ^^ same, speciifc chrooted user, your SFTP access is not chrooted at all AND when you run this sshd check:
# grep sftp /etc/ssh/sshd_config | grep -v '^#'
The result is indeed this:
Subsystem sftp /usr/lib/openssh/sftp-server
And finallly... all of this ^^ is AFTER you restarted sshd when you made those SSH changes?

If all of that ^^ is correct, have you already double-checked exactly how you have setup your Filezilla access for that ^^ same, speciifc chrooted user?
Worth double checking as it's a pretty easy mistake, to inadvertently use the wrong account credentials when setting up many users in Filezilla.
 
$ echo -n 'SFTP restrictions '; [[ -e /httpdocs ]] && echo 'active' || echo 'inactive'
SFTP restrictions active

Thanks for yout reply !
The problem is that my output to this command is "SFTP restrictions inactive" and I don't know why because I checked that /bin/bash(chrooted) is selected as shell in the Domains > mydomain > Acces to the server over SSH.
The subsystem in sshd_config was "internal-sftp" and I already tried switching to /usr/lib/openssh/sftp-server with no luck : when set to /usr... all users except root cannot use sftp. They got this error message in filezilla :
FATAL ERROR: Received unexpected end-of-file from SFTP server
And of course, I did service sshd restart after each modification to the server configuration
I guess SFTP restrictions should be active, but I can't figure out how to get it active.
 
The problem is that my output to this command is "SFTP restrictions inactive" and I don't know why because I checked that /bin/bash(chrooted) is selected as shell in
I did some researches and understood what this command exactly does. In fact I got "STFP restriction inactive" when logged as root (not chrooted of course), but "STPF restriction active" when logged as manager of the domain (the account in Domains > mydomain > Acces to the server over SSH). This user is in fact chrooted when accessed via a SSH terminal. However, the same account has full access via sftp... as do standard ftp users.... :(

As I already stated, grep sftp /etc/ssh/sshd_config | grep -v '^#' gave me Subsystem sftp internal-sftp but changing to /usr/lib/openssh/sftp-server is even worse.

And finally I checked my fillezilla setup and found no mistake. I even tried to connect throught another linux box using the sftp command and got the same results as in filezilla (managed to log without chroot with all users when sftp-internal is the Subsystem and got Connection closed immediately after password prompt for all users except root when Subsystem is /usr/lib/openssh/sftp-server).
 
You've not stated who your Hosting your VPS with, but the previous post ^^ would definitley be your 1st check anyway but then maybe, just double check that your Hosting Company have not blocked port 21 by default i.e. Not your Plesk Obsidian Firewall but your Hosting Company's Firewall. That's pretty unlikely but worth checking, as many do block port 25 by default - as an example.

Your hint was good as I checked the hosting settings I saw that port 21 was indeed not allowed (in fact only "basics" port : 22,80,443 and plesk (8443/8447) were open by default). I add "Plesk FTP" rule to the set and got port 21 open, but still can't connect to ftp. Using filezilla I got this output :
Status: Connecting to ...server IP...:21...
Status: Connection established, waiting for welcome message...
Response: 220 ProFTPD Server (ProFTPD) [...server IP...]
Command: AUTH TLS
Error: Connection timed out after 20 seconds of inactivity
Error: Could not connect to server

And sometimes it goes a little further :
Command: AUTH TLS
Response: 234 AUTH TLS successful
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Command: USER testuser
Response: 331 Password required for testuser
Command: PASS ******
Response: 230 User testuser logged in
Command: SYST
Response: 215 UNIX Type: L8
Command: FEAT
Response: 211-Features:
Response: AUTH TLS
Response: CCC
Error: Connection timed out after 20 seconds of inactivity
Error: Could not connect to server


I tried to follow the help topics on plesk with no luck. Any Idea ?
 
@Nessy So, it's as clear as mud then eh? :D
Great that you sorted the blocked port 21 problem, but can't really comment on the FTP issues as we don't use it. Others do, so they may help.

Moving back to SFTP, difficult to know where to start here, as with our own setup, if we pick any of of our hosted & chrooted domains, it will produce ALL of the results expected, after running ALL of the tests shown in post #8 and does work exactly as expected, so no clues there then.

You've ruled out any simple Filezilla setup errors (i.e. a chrooted user given root login credentials in error etc) so the only real clue left, was when you said this:
As I already stated, grep sftp /etc/ssh/sshd_config | grep -v '^#' gave me Subsystem sftp internal-sftp but changing to /usr/lib/openssh/sftp-server is even worse.
That would possibly indicate that there is a local misconfig somewhere which is causing this issue for you. The fact that it "is even worse" when you ensure that if you do run # grep sftp /etc/ssh/sshd_config | grep -v '^#' as your chrooted user & then the result is this: Subsystem sftp /usr/lib/openssh/sftp-server kind of comfirms that too.... If you can't find that local misconfig yourself (maybe starting within etc/ssh/sshd.config?) could you not just raise a support ticket instead, as that will save you lots of time and Plesk Support nearly always find and fix issues like this one, especially when we can't see for looking where the issue was. It would be good to post the actual problem and its fix, plus change this thread to "Resolved" for other users' benefit in the future, once it's all complete too.
 
That would possibly indicate that there is a local misconfig somewhere which is causing this issue for you. The fact that it "is even worse" when you ensure that if you do run # grep sftp /etc/ssh/sshd_config | grep -v '^#' as your chrooted user & then the result is this: Subsystem sftp /usr/lib/openssh/sftp-server kind of comfirms that too.... If you can't find that local misconfig yourself (maybe starting within etc/ssh/sshd.config?) could you not just raise a support ticket instead, as that will save you lots of time and Plesk Support nearly always find and fix issues like this one, especially when we can't see for looking where the issue was. It would be good to post the actual problem and its fix, plus change this thread to "Resolved" for other users' benefit in the future, once it's all complete too.
Thank you for your advice. I'll try do get support from my provider (plesk does not accept support tickets if the product was not bought by them directly). They must be something messed up somewhere...:rolleyes:
I'll post the fix here if I got one (and understand it ! ;))
 
'll try do get support from my provider (plesk does not accept support tickets if the product was not bought by them directly). They must be something messed up somewhere...:rolleyes:
FWIW - A support ticket IS possible regardless of if your hosting company is a Plesk Partner etc.
Here's the relevant lines from that page:
"...However, if you would like to get support directly from Plesk, you may purchase the Plesk support subscription..."
Followed by:
"...How can I purchase it?"
And then what people sometimes don't see or don't read properly:
"...Subscription has a free trial period for 1 month. If you order Plesk support subscription for a license for the first time, then you will be charged $0 for the first month and $10 for each next month..."
So there's a way for you to proceed, without having to sit waiting for your hosting provider / man in the middle who normally, just add delay to things like this
 
Your hint was good as I checked the hosting settings I saw that port 21 was indeed not allowed (in fact only "basics" port : 22,80,443 and plesk (8443/8447) were open by default). I add "Plesk FTP" rule to the set and got port 21 open, but still can't connect to ftp. Using filezilla I got this output :
Status: Connecting to ...server IP...:21...
Status: Connection established, waiting for welcome message...
Response: 220 ProFTPD Server (ProFTPD) [...server IP...]
ftp is a very old protocol and designed to open a seperate connection for the actual data transfer.
With active ftp, the client tells the server an IP and port to connect to and deliver the data. This does not work well with NAT and requires extra configuration for portforwarding and determining the public IP.
With passive ftp, the server opens another port and tells the client to connect there and fetch the data. This does not work well with a server firewall that does not leave any ports open for ftp to use. See also: http://www.proftpd.org/docs/directives/linked/config_ref_PassivePorts.html
WinSCP uses passive ftp by default, so Filezilla probably does too.
 
ftp is a very old protocol and designed to open a seperate connection for the actual data transfer.
With active ftp, the client tells the server an IP and port to connect to and deliver the data. This does not work well with NAT and requires extra configuration for portforwarding and determining the public IP.
With passive ftp, the server opens another port and tells the client to connect there and fetch the data. This does not work well with a server firewall that does not leave any ports open for ftp to use. See also: http://www.proftpd.org/docs/directives/linked/config_ref_PassivePorts.html
WinSCP uses passive ftp by default, so Filezilla probably does too.
Thank you for this information. I didn't know the real difference between active and passive FTP.
I tried to connect via both active and passive FTP but got the same symptoms. I'll have a better look at the FTP passive configuration as it seem to need some extra setup to make it work.
 
That's a very useful post, but for those with initial connection problems @mdraselkhan as it doesn't solve the OP's problem, because IF you change your setup, to exactly as described in that linked post, you are unable to chroot users.... You will be providng full root access. Try it yourself and see. Not using SSH keys (i.e. allowing passwords) is fine as a work around / temp solution for getting conections, but it is always going to be less secure than using SSH keys only - FWIW.
 
Back
Top