Facebook
Twitter-
Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
-
We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies! -
The BIND DNS server has already been deprecated and removed from Plesk for Windows.
If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release. -
The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.
SFTP on Plesk 10?
- Thread starter JP Kelly
- Start date
Go to "Web Sites & Domains" in Control Panel, then select "FTP Access".
In the "Account" chose "/ bin / bash (chrooted)" to activate the SFTP protocol
(Note: The user name must be filled, however the password may be empty if the FTP account has already been created earlier)
In the "Account" chose "/ bin / bash (chrooted)" to activate the SFTP protocol
(Note: The user name must be filled, however the password may be empty if the FTP account has already been created earlier)
Except for the fact that the chroot shell breaks the SFTP:
It only works with /bin/bash which of course gives users too much access. SFTP does work in Plesk 8 and 9.
I'm using the latest Plesk 10.4.4 on Ubuntu. If anyone has any ideas that would be great.
Here is the sftp debug ouput:
Here is the sftp debug ouput:
Code:
$ sftp -v [email][email protected][/email]
Connecting to mydomain.com...
OpenSSH_5.3p1 Debian-3ubuntu7, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to mydomain.com [mydomain.com] port 22.
debug1: Connection established.
debug1: identity file /home/ian/.ssh/id_rsa type -1
debug1: identity file /home/ian/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3p1 Debian-3ubuntu7
debug1: match: OpenSSH_5.3p1 Debian-3ubuntu7 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'mydomain.com' is known and matches the RSA host key.
debug1: Found key in /home/ian/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/ian/.ssh/id_rsa
debug1: Trying private key: /home/ian/.ssh/id_dsa
debug1: Next authentication method: password
[email][email protected][/email]'s password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
[email][email protected][/email]'s password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting [email][email protected][/email]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LC_ALL = en_US.UTF-8
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending subsystem: sftp
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email][email protected][/email] reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
Transferred: sent 1648, received 2008 bytes, in 0.0 seconds
Bytes per second: sent 38234.0, received 46586.1
debug1: Exit status 0
Connection closed
burnleyvic
Regular Pleskian
Try replacing /bin/bash with /usr/libexec/openssh/sftp-server (on RedHat) or /usr/lib/openssh/sftp-server (on Debian) as shell. It's not ideal, you'd ideally want a *working* chroot environment, but still no less secure than using /bin/bash.
begattokitchen
New Pleskian
Is totally absurd to give full access to users: they would have access to the whole server!
There must be a way to use SFTP with chroot access, otherwise Plesk 10 and 11 are less secure than 9. I am trying to find a solution but I am afraid this is a bug and hope it will be fixed soon. What does support say about this problem?
Remember that standard FTP is sending user's usernames and passwords in plain text... this is totally old and in many cases not acceptable.
There must be a way to use SFTP with chroot access, otherwise Plesk 10 and 11 are less secure than 9. I am trying to find a solution but I am afraid this is a bug and hope it will be fixed soon. What does support say about this problem?
Remember that standard FTP is sending user's usernames and passwords in plain text... this is totally old and in many cases not acceptable.
I would agree that it's totally absurd to give full access to users and anyone doing so would have to be crazy. A few years ago we ran into this problem and came up with a solution that we blogged about last year.
With Plesk we only allow users sftp access and we have ftp access blocked. When we send out welcome emails they state that any and all additional sftp users will have to manually created and we ask them to submit a ticket if they want them created. We create the user in the plesk panel and then make a few modifications. It works, it keeps them jailed and then can remove the users on their own.
For a detailed description on how we do it take a look at the blog post here.
With Plesk we only allow users sftp access and we have ftp access blocked. When we send out welcome emails they state that any and all additional sftp users will have to manually created and we ask them to submit a ticket if they want them created. We create the user in the plesk panel and then make a few modifications. It works, it keeps them jailed and then can remove the users on their own.
For a detailed description on how we do it take a look at the blog post here.
Last edited:
@TSCADFX,
I followed followed the instructions in your blog post, however I get this error when logging in with the new user:
Suggestions? Here's the full debug in a pastebin.
I followed followed the instructions in your blog post, however I get this error when logging in with the new user:
Code:
user with id=10000 and name=gv not found in chrooted passwd fileSuggestions? Here's the full debug in a pastebin.
Isaac,
Are you sure that you followed all of the steps? I just tested it on CentOS6 x64 with Plesk 11.5.30 mu #9 and it works fine. We routinely add these FTP accounts for clients but I tested it again just in case something changed over the last few days.
Did you create the user in the users control panel first? The chrooted passwd file is the file which is located at /etc/passwd and discussed in the second step of the blog post. If the login name is gv with a uid of 10000 it should look something like this:
If you still can't get it to work let me know what OS and Plesk you have installed.
Are you sure that you followed all of the steps? I just tested it on CentOS6 x64 with Plesk 11.5.30 mu #9 and it works fine. We routinely add these FTP accounts for clients but I tested it again just in case something changed over the last few days.
Did you create the user in the users control panel first? The chrooted passwd file is the file which is located at /etc/passwd and discussed in the second step of the blog post. If the login name is gv with a uid of 10000 it should look something like this:
Code:
gv:x:10000:000::/var/www/vhosts/domain.tld:/usr/local/psa/bin/chrootsh
^ ^ ^ ^ ^ ^
| | | | | |------- Path to shell (Always the same)
| | | | |------- Home Directory (only domain.tld should change to appropriate domain)
| | | |------- Group ID (Same as original sftp account holder)
| | |-------User ID (Same as original sftp account holder)
| |-------- Always x / a would indicate a non-chrooted environment
|-------- The usernameIf you still can't get it to work let me know what OS and Plesk you have installed.
Last edited:
TSCADFX,
Thanks for helping me out with this! I'm working on CentOS 5.9 with Panels 11.0.9 Update #51.
In Power User view, I opened up to the workspace where I'm trying to add the SFTP user. Under FTP Access, I created the new user before finishing the steps from the blog. Below are the relevant lines from the two files:
/etc/passwd
/var/www/vhosts/altrisinc.com/etc/passwd
Again thanks!
Thanks for helping me out with this! I'm working on CentOS 5.9 with Panels 11.0.9 Update #51.
In Power User view, I opened up to the workspace where I'm trying to add the SFTP user. Under FTP Access, I created the new user before finishing the steps from the blog. Below are the relevant lines from the two files:
/etc/passwd
Code:
altris:x:10000:505::/var/www/vhosts/altrisinc.com:/bin/bash
gv:x:10000:505::/var/www/vhosts/altrisinc.com:/usr/local/psa/bin/chrootsh/var/www/vhosts/altrisinc.com/etc/passwd
Code:
altris:x:10000:505::/:/bin/bash
gv:x:10000:505::/:/bin/bashAgain thanks!
On some older versions of Plesk /usr/local/psa/bin/chrootsh does not work. I'm not sure why it wouldn't work because you're now upgraded to 11x but try changing /usr/local/psa/bin/chrootsh to /bin/bash. You can also try /bin/sh (use with caution and test because this may give non-jailed shell access). Remember to restart sshd each time you try it.
This can also be a problem if you migrated a site from one server to another; especially if the architecture or OS version changed; i.e. centos 5 to 6, i386 to x86_64, etc. I've found in many cases the /var/www/vhosts/domain/usr/libexec/openssh/sftp-server is not replaced with the correct one for the platform from the server you're on, found in /usr/libexec/openssh/sftp-server typically. You may have to copy it in.
The /var/www/vhosts/domain/etc/ files are often frequently wrong. The local etc/group should contain:
But make sure the group numbers match what you find in the real /etc/group for psaserv and psacln groups.
The local etc/passwd file should contain:
But make sure the uid matches the real uid for that user from the real /etc/passwd, and the 504 is the correct gid matching the psacln group in /etc/group and the local etc/group files.
The /var/www/vhosts/domain/etc/ files are often frequently wrong. The local etc/group should contain:
Code:
root:x:0:root
psaserv:x:503:apache,psaftp,psaadm
psacln:x:504:But make sure the group numbers match what you find in the real /etc/group for psaserv and psacln groups.
The local etc/passwd file should contain:
Code:
root:*:0:0:Root:/:/bin/false
domainuser:x:10024:504::/:/bin/bashBut make sure the uid matches the real uid for that user from the real /etc/passwd, and the 504 is the correct gid matching the psacln group in /etc/group and the local etc/group files.
Both TSCADFX and Hostasaurus.Com thanks so much for your insight.
I noticed the local etc/group file did not match the /etc/group, so I updated that and restarted ssh. Still no dice.
Setting the shell in /etc/passwd to /bin/bash allows the user to log in but they're able to view/edit beyond their assigned home directory. The /usr/local/psa/bin/chrootsh shell still gives the "user with id=10000 and name=gv not found in chrooted passwd file" error message.
Thoughts guys? Again thanks so much for your time!
I noticed the local etc/group file did not match the /etc/group, so I updated that and restarted ssh. Still no dice.
Setting the shell in /etc/passwd to /bin/bash allows the user to log in but they're able to view/edit beyond their assigned home directory. The /usr/local/psa/bin/chrootsh shell still gives the "user with id=10000 and name=gv not found in chrooted passwd file" error message.
Thoughts guys? Again thanks so much for your time!
