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.