Resolved Domain (SSH) user can see other directories

[JogoVogo]

Server operating system version

Debian 12.8

Plesk version and microupdate number

Plesk Obsidian v18.0.65_build1800241106.13

Hello everyone,

a customer has just pointed out to us that if he contacts Filezilla or SSH logs into his domain, goes up some directories and sees all vhosts (customers) there. A separate subscription is available.

SSH access is (/bin/bash (chrooted)

Write permission does not exist but it should not be able to read it either... Can this be changed!?

Cheers
Ron

 

[Bitpalast]

The nature of a chrooted environment is that it must not be possible to breakout of the chrooted jail. Especially not via FTP or SFTP. I suggest disabling SSH access and in a second step re-enabling it with the chrooted option. If you are still able to breakout afterwards, please contact Plesk support on this.

 

[JogoVogo]

Set once to forbidden or restart the SSH demon?

 

[Bitpalast]

Set to forbidden. Just to make sure that file permissions and internal permissions are updated.

 

[nmdpa3]

We've seen this behavior in the past, and will try your suggestion as well. I personally like having the ability to SSH to a client site, but we turn it off for just this reason, there is to much uncertainty and confusion when enabling this option. I'd be curious to hear others opinion and experience with this, and also their take on even enabling client ssh from the outside to a plesk server....we specifically block port 22 to all plesk servers.

 

[Raul A.]

Other shells thank ``forbidden (/bin/false)`` and ``/bin/bash (chrooted)`` will give access to the entire file system. This means the system user can read all files that have read permissions for other users and access folders that have execute permissions for other users.
However, the actual webspaces/subscription folders can't be accessed by other users since they have 710 permissions. They can be accessed only by the system user associated with the webspace/subscription and the webservers group (psaserv)

If you wish to hide the webspace/subscription folders, run:

chmod 710 /var/www/vhosts

This change will be reverted by plesk repair!

/bin/bash (chrooted) is the simplest way, but it gets more complicated when php access is required. The chrooted environment doesn't have any php.

 

[JogoVogo]

Good day!

This is a serious problem because we have now switched to “/bin/bash (chrooted)”. Nevertheless, it is possible to wander in the directories. We absolutely need a solution for this!

Cheers
Ron

 

[Bitpalast]

I suggest to contact Plesk support on it, because it is not the expected behavior.

 

[JogoVogo]

What should I do here, only Plesk himself can help...

 

[Bitpalast]

https://support.plesk.com/hc/en-us/articles/12388090147095-How-to-get-support-directly-from-Plesk

 

[Raul A.]

Good day!

This is a serious problem because we have now switched to “/bin/bash (chrooted)”. Nevertheless, it is possible to wander in the directories. We absolutely need a solution for this!

Cheers
Ron

That is how SSH is designed to work. You connect to the system and have access to your own files and other locations that have the permissions for other users to access.

The “/bin/bash (chrooted)” shell creates a Linux file system in the webspace/subscription (/var/www/vhosts/domain.tld). You ssh directly there and can't access anything above /var/www/vhosts/domain.tld or anywhere else in the file system. However, this creates the problem with special applications like PHP which need to be copied to the webspace in order to be able to use them.

> Nevertheless, it is possible to wander in the directories

In which directories when you have the /bin/bash (chrooted) shell?

/bin/bash (chrooted) or don't provide ssh access at all. You can also change the permissions on /var/www/vhosts but it can be reverted after a "plesk repair"!

> What should I do here, only Plesk himself can help...

Reach out to your hoster with this problem and your hoster can open a Plesk ticket with your problem.

P.S. system users can't see each other's files. Even though you can see what other websites are hosted by listing /var/www/vhosts or by checking /etc/passwd, you can't actually access /var/www/vhosts/otherDomain.tld.

P.P.S. I highly recommend enabling "Restrict the ability to follow symbolic links" in Apache & Nginx. It will prevent the webserver from accessing symbolic links to other webspaces/subscriptions if the source and destination owners don't match. This feature blocks the lateral movement of an attacker in case one of your websites gets compromised.

 

[JogoVogo]

Hello everyone, thank you very much for your hints and answers!

In the end, it was relatively easy to solve,

https://support.plesk.com/hc/en-us/articles/12377109859735-SFTP-does-not-restrict-user-to-the-subscription-s-directory

Restrict the ability to follow symbolic links, ss enabled for all domains, i also believe by default.

Cheers
Ron

 

[MHC_1]

Hello everyone, thank you very much for your hints and answers!

In the end, it was relatively easy to solve,

https://support.plesk.com/hc/en-us/articles/12377109859735-SFTP-does-not-restrict-user-to-the-subscription-s-directory

Restrict the ability to follow symbolic links, ss enabled for all domains, i also believe by default.

Cheers
Ron

Jeeeebus Christ, you'd think that Plesk Devs would document this gapping hole in their SSH setup (like somewhere highlighted here: (Plesk for Linux) Enabling SSH Access for Website Users ) rather than having to trawl through support forum posts when this issue is discovered.

TLDR:

- To change a SSH connection type the type must be reverted to "Forbidden" before then restarting SSH and then selecting the (chrooted) option to "jail" the SSH user to their own account.
- The Line "Subsystem sftp /usr/libexec/openssh/sftp-server" is required on "/etc/ssh/sshd_config" before restarting SSH as per the documentation. This permits the "(chrooted)" aspect to work, otherwise all SSH connections will be server wide!!!