I had wonderful fun with the ART scponly RPMs this evening, and I thought I should post here so that it is recorded for posterity:
Note that the following applies to chrooted sftp, which requires that the shell is set to scponlyc rather than scponly
Are you sitting comfortably? Then I'll begin:
For "normal" domain FTP users1) In Plesk, change the shell to bash - chroot jail
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: For whatever reason, normal FTP access *for this user* seems not to work - they can only connect using sftp once this is done. I've not yet figured out why, or if it was something I did wrong at some point in the past.
Subdomain and web usersWhat 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 messagesIf 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)
..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.
Testing: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)
Faris.