Issue SFTP login failed for webspace users after AlmaLinux 8 to 9 upgrade

[Azurel]

Server operating system version

AlmaLinux 9.8

Plesk version and microupdate number

18.0.80#1

After upgrading my server from AlmaLinux 8 to AlmaLinux 9, non-root users could no longer log in via WinSCP (SFTP). Root login via SSH and SFTP continued to work fine. The error in WinSCP was:"Cannot initialize SFTP protocol. Is the host running an SFTP server?" During the upgrade, Leapp added this line to the top of /etc/ssh/ sshd_config:

in "/etc/ssh/ sshd_config" leapp added:

# Added by leapp during upgrade from RHEL8 to RHEL9
Include /etc/ssh/ sshd_config.d/*.conf

I created a new override file "/etc/ssh/ sshd_config.d/00-plesk-sftp.conf" containing:

Subsystem sftp internal-sftp

After executing "systemctl restart sshd", SFTP logins for domain users started working again.

My questions:
1. Is creating this custom config file the correct/recommended solution on AlmaLinux 9 with Plesk, or is there a official Plesk-native way to fix this?
2. Should the Include /etc/ssh/ sshd_config.d/*.conf line added by Leapp remain in sshd_config permanently?

@Sebahat.hadzhi its here not allowed to write here the text "/etc/ssh/ sshd_config" without space? "I get Failed to load resource: the server responded with a status of 403 ()" with reason:

This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.

 

[Sebahat.hadzhi]

Hi, @Azurel . There's really no official solution suggested for the issue you have experienced. I found couple of old cases reporting a similar behavior after upgrades of other OSes, but the exact root cause was unclear. Your approach sounds reasonable and if SFTP is working now all should be good. As far as I am aware, the line should remain. There shouldn't be an issue to post /etc/ssh/sshd_config. Something else likely triggered the error.

 

[Azurel]

My original post was incorrect. I had created a file called `00-plesk-sftp.conf` containing `Subsystem sftp internal-sftp`. This was wrong for Plesk, because it bypasses the Plesk chroot and gives the user access to the entire filesystem. I removed that file. On AlmaLinux, the correct configuration is `Subsystem sftp /usr/libexec/openssh/sftp-server` and this was already present in my `/etc/ssh/sshd_config`.

Source: https://support.plesk.com/hc/en-us/...restrict-user-to-the-subscription-s-directory

However, SFTP will not work for the subscription user. WinSCP reported:

Cannot initialize SFTP protocol. Is the host running an SFTP server?

I then followed the link in the last note of the Plesk article and rebuilt the Plesk chroot environment using the procedure described here:
https://support.plesk.com/hc/en-us/...1-How-to-rebuild-the-chroot-template-on-Plesk

I ran `./update-chroot.sh --rebuild` and after rebuilding the chroot environments, SFTP is working again and the user is correctly restricted to the subscription directory. During the rebuild, Plesk produced quite a few messages like these for every domain:

mysql: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb' instead
Removing chrooted environment on domain.com: chrootmng[85438]: Failed to stat '/var/www/vhosts/domain.com/usr/lib64/libcrypt.so.2': Success
chrootmng[85438]: Failed to stat '/var/www/vhosts/domain.com/usr/lib64/libffi.so.8': Success
chrootmng[85438]: Failed to stat '/var/www/vhosts/domain.com/usr/lib64/liblber.so.2': Success
chrootmng[85438]: Failed to stat '/var/www/vhosts/domain.com/usr/lib64/libssl.so.3': Success
chrootmng[85438]: Failed to stat '/var/www/vhosts/domain.com/usr/lib64/libnettle.so.8': Success
chrootmng[85438]: Failed to stat '/var/www/vhosts/domain.com/usr/lib64/libcrypto.so.3': Success
chrootmng[85438]: Failed to stat '/var/www/vhosts/domain.com/usr/lib64/libldap.so.2': Success
chrootmng[85438]: Failed to stat '/var/www/vhosts/domain.com/usr/lib64/libhogweed.so.6': Success
chrootmng[85438]: Failed to stat '/var/www/vhosts/domain.com/usr/lib64/libevent-2.1.so.7': Success
chrootmng[85438]: Failed to stat '/var/www/vhosts/domain.com/usr/lib64/libsigsegv.so.2': Success
chrootmng[85438]: Failed to stat '/var/www/vhosts/domain.com/usr/lib64/libnss_mymachines.so.2': Success
chrootmng[85438]: Failed to stat '/var/www/vhosts/domain.com/etc/passwd': Success
chrootmng[85438]: Failed to stat '/var/www/vhosts/domain.com/etc/group': Success
Done! Action have been completed.

Despite these warnings, the rebuild completed successfully and fixed the SFTP problem. I think.

So, in my case, the problem after upgrading from AlmaLinux 8.10 to AlmaLinux 9.8 was apparently the Plesk chroot environment. Rebuilding the chroot fixed it.

 

[Azurel]

@Sebahat.hadzhi
Shouldn't the “Plesk Repair” extension have detected the chroot problem and fixed it on its own? It didn't detect this kind of issue.

 

[Sebahat.hadzhi]

No, I don't think so. Repair is primarily intended to correct the filesystem integrity in terms of ownership, permissions, and certain mandatory files/directories. There's a separate script specifically for rebuilding the chroot template (from the article you linked).