• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • 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.

SFTP no longer working with chrooted shell

B

bcorcoran

Guest
I've been having this problem since 10.1.1, and thought maybe upgrading to 10.3.1 would solve it... no such luck.

My issue is that if I set /sbin/nologin or /bin/bash (chrooted) as the shell to enable SFTP access with no/limited shell access, the user can not log in. If I give them any other normal shell, i.e. /bin/sh, /bin/bash, /bin/tcsh, etc they can log in just fine... but that's not secure enough for me.

Is there any sort of "plesk integrity" check I can do that will check all binaries related to plesk?

In /var/log/secure, I'm not seeing anything odd other than the session closes right after it's started:

Code:
Oct  9 06:17:26 server sshd[32392]: Accepted password for USERNAME from x.x.x.x port 52843 ssh2
Oct  9 06:17:26 server sshd[32392]: pam_unix(sshd:session): session opened for user USERNAME by (uid=0)
Oct  9 06:17:26 server sshd[32394]: subsystem request for sftp
Oct  9 06:17:26 server sshd[32392]: pam_unix(sshd:session): session closed for user USERNAME

I've seen other threads dealing with this subject on older versions of Plesk, but they remained mostly unresolved. Any ideas as to how I can fix this?
 
Last edited by a moderator:
Hi,

I've just done a little testing (very little) and the following appears to work :

1) Follow this guide : http://www.tomvernon.co.uk/blog/2009/12/ftps-and-sftp-on-plesk-with-proftp/ (Ok its ridiculously brief but its where I got the info from).

2) Reset the list of shells available to Plesk in MySQL :
DELETE FROM BackendCache WHERE `key` = "sysinfo:getshell";

It's a little odd, since if you ssh in it just doesn't provide you with a shell and eventually times out cutting the connection. I'd recommend testing it more thoroughly before using it and I'd be interested if you do get things working.

Paul.
 
Doing what you said works... but the user is still not jailed to their directory... so they can browse up to the root and see all the folders there. It also doesn't help fix /bin/bash (chrooted) and /sbin/nologin still being broken.

Could it be that I updated OpenSSH and jailed chroots are no longer working because of it? If so, how can I fix that?
 
Any Resolution

Was there ever any resolution found to this problem? We face the same problem where users cannot connect via SFTP and we don't want to allow them SSH access.
 
Does this help? I wrote this for 8.6 but maybe somethig in here will help regarding how to get it to work and how to Jail correctly. Subdomain/webusers file locations and things have changed in 10.x, so those parts of my notes may be incorrect for 10.x:

Also note that in this version of my notes, I don't use the Plesk GUI to change the shell to scponly. That didn't work for me with the particular scponly RPM I had used to install it.


Note that the following applies to chrooted sftp, which requires that the shell is set to scponlyc rather than scponly

The above is the key to getting things jailed. If you use scponly as the shell, there will be no chroot jail.


For "normal" domain FTP users

1) In Plesk, change the shell to bash - chroot jail
(this is actually very important - not optional. See notes on subdomains later on)


2) Run the following command

Code:
usermod -s /usr/sbin/scponlyc username (where username = ftp username)


( the above is the same as editing /etc/passwd to change the shell to /usr/sbin/scponlyc )

3) All done.

NOTE: normal FTP access *for this user* will no longer work. Only sftp.



Subdomain and web users

What about Plesk *subdomain* FTP users? You cannot assign a shell to subdomain users in Plesk 8.6 (not sure about later versions) and possibly not for "web users" either.

You can still enable scponly for them, but it is a tad harder. Just a tad, mind you!

When you tell Plesk to give shell access to a normal domain user, it basically changes /etc/passwd to give it the appropriate shell, and, in the case of the chroot jailed shell, it copies certain files to /var/www/vhosts/domain.tld/bin, etc, var, lib, usr and dev.

Since you can't use this automated option for *subdomain* users (and possibly web_users), you need to copy the appropriate files manually to the user's chrooted jail root.

For a *subdomain* user, the root would be /var/www/vhosts/domain.tld/subdomains/subdomain-name/

As to the necessary files themselves, the simplest option is to give a normal FTP user bash-chroot shell access temporarily, then copy SOME files from there. Remember to disable the bash chroot access for that user afterwards!

I say SOME files because you don't need ALL the files that Plesk actually copies. All you really need are the following:

bin (but only scp -- none of the rest are needed and copying them may pose a security risk)
lib (all)
usr (all)

Actually, in usr you'll find a share and a lib directory. The lib directory is empty and you don't really need it. I don't actually know if you need the share directory or not. I'd guess not, however.


So, just to make this clear, in the case of a *subdomain* user, you'd end up with the following:

/var/www/vhosts/domain.tld/subdomains/subdomain-name/bin/scp
/var/www/vhosts/domain.tld/subdomains/subdomain-name/lib/(lots of "so" files)
/var/www/vhosts/domain.tld/subdomains/subdomain-name/usr/libexec/openssh/sftp-server
/var/www/vhosts/domain.tld/subdomains/subdomain-name/usr/share/(lots of files - may not be needed)
/var/www/vhosts/domain.tld/subdomains/subdomain-name/usr/lib (empty -- not needed really)

Incidentally, all the above are root:root. use cp -rp when copying them from their original locations.


Common error messages
If you miss out bin/scp and/or the lib directory, you'll get an error such as...


Code:
failed: /usr/libexec/openssh/sftp-server with error No such file or directory(2) 
[CODE]


..even if you actually do have 
/var/www/vhosts/domain.tld/subdomain-name/usr/libexec/openssh/sftp-server

If you just can't get this error to go away, try copying the entire bin, lib and usr directories.


[B]Testing:[/B]
If all is well, you should be able to connect via sftp using the appropriate ftp username and password, and crucially you should NOT be able to get further up the directory tree than /var/www/vhosts/domain.tld/subdomains/subdomain-name and you should NOT be able to connect to any normal shell when using ssh and the ftp username and password (you will get an scponly "welcome message", however) 


[B][COLOR="Red"]!!WARNING!![/COLOR][/B]
Again I'll emphasise that this was written for 8.6, but in theory the important points should help people running 10.x

Also note that you make these system-level changes at your own risk. If it goes wrong, you are on your own. BACKUP before you start, or you may regret it.

These notes were based on the use of the scponly rpm from the ART repo on Centos 4.
 
Last edited:
Hi Faris,

I've just tried your potential solution and it doesn't seem to have fixed the issue. I had to install scponly via yum, but don't know if there were extra steps I was supposed to take. I also don't know where to look to see why sftp-server is immediately disconnecting. There is nothing useful in /var/log/secure, and there doesn't seem to be a log folder within the chrooted user's home folder, either.

I'm experiencing the exact same issue as above, where connecting via sftp results in being immediately disconnected. I'm able to connect via SSH, though, and the chroot jail does seem to be working properly.

I'm running Plesk 10.1.1

I would assume sftp-server can't access something it needs to, but I have no idea where the configuration files are (I'm a MediaTemple customer and I have a dedicated-virtual server with them).
 
If you're referring to the main account for the domain you should have no problem. Creating additional FTP accounts in Plesk in a chrooted environment can cause the client to be disconnected as soon as they connect. Normally the response is "Connection closed by server with exitcode 1".

This is because the additional accounts are not given the correct permissions to access the chrooted environment but are given access to connect. This causes the server to immediately disconnect them.

I've written an article on how to address these issues. It can be found here.

Hope that helps you understand it a bit better.
 
Last edited:
What the KB article neglects to mention is that you'll need to recreate all existing users chroot environment. Switching it to forbidden and back to bash (chrooted) is not going to do it either...

http://kb.parallels.com/en/818

Not that that works well on 11, not here anyways, as there is no shell variable called ${HTTPD_VHOSTS_D} and the --target=all is removed.

So you'll have to specify full paths yourself and run it for every domain required. Please use hardlinks for the directories under /var/www/vhosts/chroot to the domains - this will make things easier and save diskspace. Not to mention the misery you have now with security updates (first you yourself will have to check if one of the libs is replaced - if it's replaced (on the / filesystem) you'll have to replace it in the chroot skeleton and then recreate all the chroot jails).

Quite the PITA. Will be hard to get around too - can probably get away with hard linking the skeleton into the domains as they're all under /var/www/vhosts (and many have a separate /var partition - I know we do) but hardlinking it into the skeleton (so no issues with security updates) will usually not be possible.
 
Just ran into similar issue on Plesk 8.6.0 running on Fedora Core 4.

User informed me that he had 2 domains on the same server, 1 allowed him to use SFTP, the other did not.
On inspection, both had chroot shell enabled.

No apparent differences at first.
/var/log/messages nor /var/log/secure showed any errors.


TL;DR: Issue fixed by switching user to /bin/bash and back to /usr/local/psa/bin/chrootsh


Reading Faris' post, I quickly came to the following conclusion:

Code:
# grep -i sftp /etc/ssh/sshd_config
Subsystem       sftp    /usr/libexec/openssh/sftp-server

# getent passwd user1
user1:x:10122:10001::/home/httpd/vhosts/user1.com:/usr/local/psa/bin/chrootsh
# getent passwd user2
user2:x:10533:10001::/home/httpd/vhosts/user2.com:/usr/local/psa/bin/chrootsh

# find /home/httpd/vhosts/user1.com/ -name "*sftp*"
/home/httpd/vhosts/user1.com/usr/libexec/openssh/sftp-server
# find /home/httpd/vhosts/user2.com/ -name "*sftp*"
<nothing>

Since Faris said that when you enable chrootshell, Plesk copies the binaries and modules,
I just figured I had to switch user2 to /bin/bash and back to /usr/local/psa/bin/chrootsh

Code:
# find /home/httpd/vhosts/user2.com/ -name "*sftp*"
/home/httpd/vhosts/user2.com/usr/libexec/openssh/sftp-server


Thanks Faris for the research!
 
Last edited:
Back
Top