Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to secure the SSH server so that the SSH user can only do backups? #879

mossroy opened this Issue Mar 15, 2018 · 2 comments


None yet
1 participant
Copy link

mossroy commented Mar 15, 2018

I already use backintime for my personal backups, on a self-hosted (debian) server through SSH.
But I would like to open this server to some other backintime users, and make it as secure as possible.

I would create a SSH user for each person, and use encrypted SSH option (so that I'm not able to read the backups of other persons. Hopefully #644 and gocryptfs might further improve that in the future).
I can configure these SSH users without password authentication (to force the use of SSH keys), which is already a good point.

My concern is that, if the computers of these persons get compromised (or if they simply have bad intentions), they have a SSH access to my server. Even if it's a non-root access, it still allows to do a lot of nasty things (on the server itself and/or on the local network). I would like to mitigate that risk.

I've tested a few technical possibilities, without much success for now :

  • BIT seems to need a real SSH connection to connect to, so limiting to SFTP with something like does not work (BIT complains it can not connect)
  • I tried to chroot the SSH users (through openssh configuration). It made me discover a few commands BIT is using (in addition to the shell interpreter itself) : chmod, cp, ls, mkdir, rm, touch, find, rsync. But, after copying these binaries (and their librairies) inside the chroot, it still fails when trying to mount sshfs (and I don't find enough detail to know what's missing)
  • I thought about assigning a limited shell to the users, but did not completely succeed :

Any suggestions?


This comment has been minimized.

Copy link

mossroy commented May 23, 2018

Another option might be to put the SSH server inside a container (Docker, for example), and restrict the network capabilities of this container.
Did anyone try this approach?


This comment has been minimized.

Copy link

mossroy commented Feb 28, 2019

I finally implemented such a Docker container, and wrote a blog article with all the details (in French) :

Another advantage of this approach is that you can create one container instance for each user, giving access only to his own backup data. If one container is compromised, it should not affect the other ones.

@mossroy mossroy closed this Feb 28, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.