SFTP Stops Working After Installing HestiaCP on Ubuntu 22.04 LTS

Community Support
1

After installing HestiaCP on my Ubuntu 22.04 LTS server, I encountered a persistent issue with SFTP. Initially, everything was working fine—I could connect via SSH and SFTP as root without any problems.

However, as soon as I installed HestiaCP, SFTP stopped working. The SSH service remained active, but every attempt to use SFTP (even as root) failed with the following error from clients like WinSCP or FileZilla:

Error

Connection has been unexpectedly closed. Server sent command exit status 127.
Cannot initialize SFTP protocol. Is the host running an SFTP server?

It seems that SSH could not launch the SFTP subsystem, likely due to a misconfiguration in /etc/ssh/sshd_config.

Troubleshooting Steps:

  1. Verified that the SSH service was running:

    sudo systemctl status ssh

  2. Checked SSH logs:

    sudo journalctl -u ssh
sudo tail -n 100 /var/log/auth.log

  3. Inspected the SSH configuration and ensured that the following line was present:

    Subsystem sftp internal-sftp

  4. To fix the issue, I executed the following command:

    sudo sed -i '/^Subsystem sftp /d' /etc/ssh/sshd_config && echo 'Subsystem sftp internal-sftp' | sudo tee -a /etc/ssh/sshd_config && sudo systemctl restart ssh

After running this command, SFTP started working again—temporarily.

Problem Worsens After Creating a New User in HestiaCP:
After creating a new user via HestiaCP, the issue returned, but this time it was worse! The SSH service itself stopped working, and attempts to connect resulted in:

ssh: connect to host [server IP] port 22: Connection refused

Before losing SSH access, I noticed that HestiaCP was modifying /etc/ssh/sshd_config, injecting lines like:

Match User sftp_dummy99,username
    ForceCommand internal-sftp -d /home/%u

This modification caused the SSH daemon to crash upon restart. The ForceCommand internal-sftp -d /home/%u syntax can be problematic in many OpenSSH setups, especially without proper Chroot configuration.

How to Recover Server Access:
Since SSH was no longer responding, the only way to regain access was through a recovery console (VNC or similar) and then:

  1. Restore a working version of /etc/ssh/sshd_config or manually fix it:

    • Remove any Match User blocks added by HestiaCP.
    • Remove any ForceCommand lines.
    • Ensure the following line exists:
      Subsystem sftp internal-sftp

  2. Restart SSH:

    sudo systemctl restart ssh

Conclusion and Recommendations:
This is a known issue with HestiaCP, where adding new users or enabling SFTP support causes it to auto-edit sshd_config in unsafe ways, leading to a total loss of SSH and SFTP access unless manually corrected.

Suggested Solutions:

  • HestiaCP should provide an option to prevent automatic modifications to sshd_config.
  • A feature should be implemented to allow users to review and confirm changes before applying them.
  • An automatic validation check should be added to ensure SSH remains functional after modifications.

Has anyone else encountered this issue? What solutions have you tried?

3 Likes
2

Thanks for the detailed info! I encountered this issue yesterday after doing apt-update/upgrade. I could use ssh but not sftp.
And after adding ForceCommand internal-sftp I could use sftp but not ssh.
So I after following step 1, I got everything working again

I would like to note though that in my sshd_config I found the following line which I commented out .

# override default of no subsystems
Subsystem sftp internal-sftp-server

So Subsystem sftp internal-sftp-server doesn’t work
but Subsystem sftp internal-sftp works.