sFTP only and chroot user

[StaringSkyward]

Hi, first let me say thanks for all you have done on ContainerSSH, it's a really cool thing!

We have a specific real-world use case where we deal with old equipment which uses only user and password authenticated sFTP to read files which need to be processed and then write the results after processing.

We would really like to use containerssh under kubernetes to create a more secure sftp system which dumps each user's sFTP session in a chroot directory containing only their files. If I can mount a network file share in the guest image which contains a directory tree organised like {organisation ID}/{user ID}/{user's directories and files} and then create auth and config APIs which can auth a user and return the correct chroot directory path for them given their username, is it possible to restrict that user to sftp only and chroot them into that directory?

Furthermore, because we are stuck with password auth, is there any provision in containerssh for network-level brute force protection such as with SSHGuard or Fail2ban?

Thanks!

[ghost]

Hey @StaringSkyward thank you very much for your feedback.

To answer your question:

1. Yes, it is possible to restrict a user to SFTP only by applying the restrictions documented in the security module.
2. It is partially possible to chroot a user. You can mount the user's home directory in the container, but you cannot chroot SFTP into the home directory so that the user doesn't see the rest of the container. In Kubernetes specifically you would set up your pod spec with the NFS volume, and then mount the appropriate subdirectory into the container using the subPath option. This pod spec can be passed to ContainerSSH from the configuration server.
3. Regarding SSHGuard and Fail2ban, I would recommend replacing these with your desired logic in the authentication webhook. Alternatively, you can just log in whatever format you want from the authentication server and let these programs take it from there.

I hope this helps, please feel free to post in this thread or join our Slack channel.

[kfox1111]

The fail2ban thing is probably a higher level problem. I'd like to see something like it watch logs by getting them pushed to it via something like fluentd at more of a cluster wide level, and be able to then tweak k8s networkpolicy objects. Could be made more generic and work across vm's and k8s's. But not really in the scope of this project I think.

[ghost]

The need and desire is totally understandable and it has been requested before. You can probably somewhat mitigate the issue by providing a workdir in the container so users don't land in the root directory, but they can still click outside the home directory and get lost. Alternatively, you can also keep a lookout for an SFTP binary that can chroot and run that inside the container. At some point we would like to support SFTP directly in the ContainerSSH agent, but right now we don't have the capacity to implement an SFTP server. There are third party libraries in Go for SFTP, so if shouldn't be too hard if someone were to have a "go" at it.

[StaringSkyward]

Forgive my ignorance, but would a standalone sftp server binary work and if the client manages to "get out" of the binary or crash the process, docker terminates the running container and they are thrown out of the sftp session?

[ghost]

The way SFTP works is a bit interesting: the SSH server starts the SFTP server as a normal program and then talks SFTP protocol over the standard input and output. The difference is that the client doesn't request /usr/sbin/my-sftp-binary to run, but instead requests the "sftp subsystem" to run and the SSH server knows which program to start.

Because the request for the SFTP subsystem is translated to a path by the server there is no way for a client to circumvent that and launch a different program. If the SFTP program crashes the SSH session is terminated because there is no shell in-between. (This is true for OpenSSH just as well as ContainerSSH.)

In case of ContainerSSH the SFTP program is run with docker/kubectl exec in connection mode, or with docker/kubectl run in session mode. When SFTP exits the user drops out of the exec/run and can in no way interact with the underlying container.

[StaringSkyward]

One last question: am I correct in thinking that containerssh handles the auth stage and then hands off the session to the sftp server once it has been established? If so, for our particular case it could write authentication failues to /var/log/auth.log in a format that log following agents such as SSHGuard and Fail2ban can act upon, e.g: Dec 7 10:32:59 ip-4-3-2-1 sshd[1995]: Invalid user user from 1.2.3.4 port 46774.

This would work for us if we ran the container under podman on Linux and had SSHGuard running on the host watching the log file. A sidecar container might be able to do the equivalent in kubernetes by watching the log volume/log stream and manipulating network policy rules.

[ghost]

Yes, the SFTP server is only started once the user has successfully authenticated and starts a session with the SFTP subsystem. The container itself is started when the user has successfully authenticated in connection mode, or together with SFTP in session mode.

For Fail2ban I would recommend writing this log from your authentication server as we don't have a guaranteed log format for Fail2ban right now. Alternatively, please feel free to open an issue with a feature request.

[StaringSkyward]

Marking as answered. Thanks to everyone for your help!