Chrooted sftp -- very large uploads fail

This document (7017717) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 11 Service Pack 3 (SLES 11 SP3)
SUSE Linux Enterprise Server 11 Service Pack 4 (SLES 11 SP4)

Situation

A chrooted sftp session is uploading a very large file.  After approximately 36 GB uploaded, the session fails.  The client reports:
 
Write failed: Broken pipe
 
The amount of data transfered before the failure may vary, and may depend upon network speed.

Resolution

For processes which must run for extended periods of time, the random number generator needs to be reseeded.  However, once a session is chrooted, it can no longer reach /dev/urandom or /dev/random, to accomplish this.  When that fails, the sftp session fails.
 
A couple of approaches can be used for this.  NOTE: One instance of openssh can have multiple different chroot locations for different users, groups, etc. So it may be necessary to repeat the approach for many different locations.
 
1.  Recommended:  Bind /dev/urandom and /dev/random underneath the chroot location.  For example, assume the sftp chroot point is /sftpchroot/bob/.  Note this is not necessarily the upload directory, this is the chroot point, or the path which will appear as root (/) to users and processes within the chroot.  In this case, the steps would be:
 
mkdir /sftpchroot/bob/dev/
touch /sftpchroot/bob/dev/urandom
touch /sftpchroot/bob/dev/random
mount --bind /dev/urandom /sftpchroot/bob/dev/urandom
mount --bind /dev/random /sftpchroot/bob/dev/random
 
(Of course, those bind mounts could be placed in /etc/fstab to make them permanent)
 
 
2.  Instead of doing bind mounts as in #1, it is possible to simply create additional devices under a chroot location.  For example, assuming the same chroot location as #1 (/sftpchroot/bob/) the approach would be:
 
mknod -m 444 /sftpchroot/bob/dev/urandom c 1 9
mknod -m 444 /sftpchroot/bob/dev/random c 1 8
 
This might not be ideal, however, especially if multiple chroot locations are needed.  One developer warned:
 
"...leaving /dev/random lying around might cause system hangups from time to time.  Accidentally depleting the entropy by reading file with unexpected properties in an unexpected place would block all other read()s until enough randomness is gathered again."

Cause

In late 2015 / early 2016, changes were added to openssh on many SLES platforms to make sure to reseed the random number generated in long-running processes.  That works fine in most cases, but fails if the session is running within chroot.

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:7017717
  • Creation Date: 13-Jun-2016
  • Modified Date:03-Mar-2020
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback@suse.com

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Join Our Community

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.


SUSE Customer Support Quick Reference Guide SUSE Technical Support Handbook Update Advisories
Support FAQ

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.

Go to Customer Center