[How-to] SSH No Passwords + SFTP chroot jails

WARNING:
Do not make these changes without first uploading a key and logging in with the key to make sure it works correctly. For more information on creating keys and uploading them to your server, check out this info.

HestiaCP offers SFTP chroot jails preconfigured upon installation. This is a great way to give users access to upload files securely via SFTP. It prevents them from browsing outside their home directories. Most importantly, they can use SFTP without having shell access.

You can test this out by connecting to the server with one of your user accounts via SFTP. However, if you have configured SSH to only allow key authentication, you get an error message that looks similar to this.

Disconnected: No supported authentication methods available (server sent: publickey)

Locking down SSH to require key authentication is easily obtained with the following config update:

PubkeyAuthentication yes
PasswordAuthentication no

Unfortunately, this configuration prevents SFTP connections via password with the default HestiaCP installation. How can we solve this? Let’s modify our SSH config to allow passwords for all of our SFTP chroot jail users. We just need to add 1 line to the HestiaCP managed Match condition typically located at the bottom of the /etc/ssh/sshd_config file.

Match User sftp_dummy99,admin,user1,user2
ChrootDirectory %h
X11Forwarding no
AllowTCPForwarding no
ForceCommand internal-sftp
PasswordAuthentication yes

We’ve added the last line PasswordAuthentication yes to this match condition. This match condition includes all users that have nologin set. Later, if a user requests shell access, simply give it to them via HestiaCP. Behind the scenes, their username will be removed from this condition. Now they will be able to login via shell but will have to provide a key.

TL;DR
It would be great if there was a way sshd_config config could distinguish FTP traffic from shell-only traffic. We could isolate our configuration a bit better. In the example outlined above, once you give a user shell access, they will have to use a key to authenticate with SFTP as well.

6 Likes

I get this for my ssh users;

sshd[18863]: fatal: bad ownership or modes for chroot directory component "/home/"

OK, this is solved by chown /home as root:root with chmod 755, not more. (Which, by itself creates new problems, but that’s a different story…)

Of course, when I comment the ChrootDirectory %h out, the user can access the entire server up from its home dir, which is very much unwanted…

If you give shell access, you will get
/bin/bash: No such file or directory
because it is not really created as a chroot jail, even if you set it as such in hestia, to have the user get bash…
This part is obviously not done yet?

You may want to warn admins in the UI when they allow users ssh access; They can upload their own public key through hestia’s UI, and then they essentially have access to the entire server, or at least read access to everything root 0755, which includes the backups, and through that you give them access to all user’s web-passwords etc :wink:

The chrooted jail is not difficult to realize, but it requires everything under the jail dir to be root-owned, which is currently not what hestia does. We could create a subdir under the user to become the jail, and then perhaps symlink their web dir to that?

We have support for Chroot if you set the user login to nologin and it should be handled by default. This tutorial is outdated.

Currently we don’t support Chrooted shell access for any users. How ever feel free money to the cause.

1 Like