I'm building custom Debian environments on a remote server, which I connect to over SSH. This involves building a debootstrap environment, then chrooting into it to run a custom installer. As part of the custom install process, I need the installer to be able to ssh out of the chroot environment to a further remote server, re-using the SSH credentials my ssh-agent outside the chroot knows about.
I simply can't think how to do this. In principle, I think I should be able to use socat to forward the $SSH_AUTH_SOCK into the chroot environment before calling chroot like this:
socat UNIX-CONNECT:$SSH_AUTH_SOCK UNIX-LISTEN:chroot_root$SSH_AUTH_SOCK,fork &
sudo -E chroot chroot_root /bin/bash
But that gives me a broken pipe from socat as soon as I try to use ssh inside the chroot, which I guess is understandable (in a way).
Is there any way around this? I've got a fallback of setting up an SSH master socket before chrooting and using that for everything inside the chroot, but that would involve a fairly intrusive rewrite of the installer, so I'm really not keen on that plan.
UPDATE
It turns out that I can get the effect I want simply by creating a hard link to the socket. I honestly didn't expect that to work.
Best Answer
You can forward the SSH Agent into a chroot but you have to jump through a few hoops, the first of which is making the socket accessible in the chroot and the second is telling users within chroot about it.
To make the socket available, the OP's suggestion to use
socat
works as long as permissions are set properly. Assuming that you're using a script to launch the chroot, the following snippet usessocat
to provide the agent socket in the chroot:It establishes the
uid
andgid
of the user (alice in the example) within the chroot that should be able to access the agent. It then creates that directory and establishes asocat
in pretty-much the same manner as the OP. The addition is theuser=${_owner%:*}
pirce which sets the uid on the socket within the chroot so that alice can access it.It then remembers the
socat
PID so that it can be torn down when the chroot exits. Finally it exports theSSH_AUTH_SOCK
variable to make it available within the chroot.Now,
chroot
can only be done byroot
so my guess would be that the script is run withsudo
from a regular user who owns the agent process. If this is accurate, then there is one more thing to do which is to permitsudo
to pass the environment varaible into the script. To do this, edit/etc sudoers
(the approved mechanism is to sosudo visudo
) and add the following:This change also needs to be made to
/etc/sudoers
within the chroot ifsudo
will be used within the chroot (i.e. to switch fromroot
toalice
).Here is an example of an agent socket within a chroot viewed by a regular user.