I had to build some Debian packages recently after a long
time. The experience really made me appreciate
the simple
approach taken by Arch Linux. When I finally built
something up to Debian standards I had to distribute it on the
network. Debian's APT can work over HTTP, FTP... but
also SSH, which is pretty good for creating strong access controls for
the repository, over encrypted connections. There are a lot
of articles
covering this approach, but I didn't find any information on how to
make it work in a chroot environment, and got stuck
there for a while.
But to go back to the beginning, if you're setting up a repository the
reprepro tool is
pretty good for repository management. Having SSH in mind for later,
some decisions have to be made where you'll store the repository and
who will own it. The "reprepro" user is as good as any, so we
can start by adding the user (and group) to the system and making its
home
/srv/reprepro. Then we can setup the bare repository layout,
in this example the repository will reside in the debs
directory:
# su repreproYou'll need two files in the conf sub-directory, those being "distributions" and "options". They are simple to write, and all the other articles explain them. You don't have to worry about the rest of the tree, once you import your first package, or .changes file, reprepro will take care of it then. If you intend to use GPG, and sign your Release file, it's a good time to create your signing key. Then in the distributions file configure the Sign option, and in the conf file add ask-passphrase.
$ cd ~
$ mkdir -p debs/conf
deb ssh://apt@192.168.50.1:/debs/ squeeze main deb-src ssh://apt@192.168.50.1:/debs/ squeeze mainThat's the gist of it. User apt gets read-only access to the repository, if coming from an approved host. You can control host access with TCPWrappers, Iptables and OpenSSH's own whitelist that ties keys to specific hosts. Each APT client should have its key white-listed for access, but give some thought to key management, they don't have to be keys without a passphrase. You can setup the SSH agent on a machine you trust, and unlock a key. Using agent forwarding provided by the OpenSSH client you could login to a machine and install packages without being prompted for the passphrase, and without leaving your keys laying around. This alone would not scale in production, but is a good start.