• 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 on Plesk 10?

I realize that enabling sftp for users other than the domain user is not possible in Plesk 10.
Is there any way around this?
I really need to enable SFTP for a web user/other FTP user.
 
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)
 
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)

Except for the fact that the chroot shell breaks the SFTP:

Couldn't open /dev/null: Permission denied

It only works with /bin/bash which of course gives users too much access. SFTP does work in Plesk 8 and 9.
 
Has anyone found a solution to this? Someone in Parallels must know why chrooted bin/bash SFTP access works for Plesk 9 but not for Plesk 10.
 
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:
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
 
No Solution?

I don't see any solutions here. Did anyone get SFTP for an account besides the account root figured out?
Thanks,
Don
 
I just gave up with chrooting and just used normal /bin/bash access. As long as the users are trusted users and you make sure they have a long/strong password then SFTP will work. They still won't have root access.
 
I just gave up with chrooting and just used normal /bin/bash access. As long as the users are trusted users and you make sure they have a long/strong password then SFTP will work. They still won't have root access.
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.
 
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.
 
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.
 
Last edited:
@TSCADFX,
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 file

Suggestions? 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:

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 username

If 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
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/bash

Again 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:

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/bash

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.
 
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!
 
Back
Top