-
Notifications
You must be signed in to change notification settings - Fork 29
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
Enable performant rsync
filetransfer
#55
Comments
For Right now, we use the internal-sftp subsystem to provide sftp, and this works ok. However, we want to provide support for rsync (#55), scp and other file transfer mechanisms too. There's no built-in support for these protocols in sshd. scponly is (was?) a popular program designed exactly for this use case. Instead of acting as a subsystem, it forces acting as a shell - consuming any parameters sent in by the user, and allowing only scp and rsync. Assuming there are not any RCEs in rsync or scp, this should work ok? We still will use a chroot for additional protection. See scponly's SECURITY file for other precautions we need to take. Particularly, we'll need to provision a chroot inside our docker image that has just the bits needed for rsync / scp to function, and nothing else.
|
Hello! |
Unfortunately nope and I won’t have time to work on this for a few months at least. Sorry |
We currently have
jupyterhub-ssh
the Python package + Helm chart, and we have thejupyterhub-sftp
part of that Helm chart that could in practice be its own Helm chart.@yuvipanda describes that even if we solve #41, using
rsync
like that won't be very performant. Perhaps could thejupyterhub-sftp
service be made more general, such asjupyterhub-filetransfer
and be a service directly exposing some file transfer services likersync
,scp
, andsftp
? Maybe... Let this issue represent the wish for having a performantrsync
.The text was updated successfully, but these errors were encountered: