Remote chroot

Sometimes, it can be useful to open a chroot of a filesystem on box A in box B, so that you're running the distro which is stored on A in B. The process to get such a remote chroot is fairly straightforward.

Step zero: check some of the limits
Before doing anything else, check the following: If you can answer any of these questions with "no", then stop right here. If you want to build remotely, then use DistCC. You cannot use this method.
 * box A and B have the same architecture (x86 is not the same as amd64). Architecture of the systems is use an ssh connection to connect and then chroot, but using an nfs share of sftp based share, system architecture does matter. If your local system is 64 bit, you can chroot into a 32 bit environment, but to do so, issue the chroot command as "linux32 chroot" rather than just "chroot" below. A 32 bit system cannot chroot into a 64 bit directory/chroot at all; binaries will not be executable.
 * box A CFLAGS are either 1) a specifically defined -march= entries that match box A's CPU type, 2) empty or 3) able to be used when compiling on box B. Be aware that if you use -march=native for CFLAGS, box B will interpret that as native for it during compilation, which may produce binaries not able to be executed by the CPU in box A.
 * you know what you are doing and why you should check the above

Step one: mount remote filesystem
The first step is to mount box A's filesystem over the network from box B. The recommended protocol is SFTP, which is included with the OpenSSH package, but you could also use NFS is the remote system is on your private LAN. To read more on mounting an SFTP share on your filesystem, read Mount SFTP share. Let's say you mounted box A's filesystems on of box B. Using FUSE, the mounting command would be as such:

Step two: chroot into the mount
Step two is to the chroot, since you now have its filesystem mounted. If the remote system has screen installed, opening a screen session before continuing will allow progress to continue even if your connection is disrupted. If using nfs or an sftp based method to view the "remote" filesystem rather than using ssh to conect, screen will do no good: if the connection drops, your progress will hault.

You are now in a remote chroot.

A word of caution
Permitting root logins over ssh/sftp compromises security if precautions are not taken. Configuring RSA authentication is fairly trivial and much more secure than permitting root logins using password authentication on an untrusted network. RSA keys setup to permit ssh sessions will also work for sftp based remote mounts.

Do *not* use nfs shared directories over public Internet to make a remote chroot environment accessible. NFS is an appropriate solution only for use on a LAN.