Authenticated Repositories

Although RPM and Debian repos are generally intended for distributing software to the public, there are times when a more private approach is desired. Whether for proprietary software or merely keeping "the internet" out of development spaces, let's take a look at how to secure linux package repositories in a way that is transparent to native tools.

Recently, at work, I came across a requirement to establish authenticated package repositories (RPM and DEB) for software we distribute. This was a surprisingly non-trivial task. Broadly speaking, there are two ways to pull this off--using HTTP Basic Auth or Client SSL Certs. Which makes sense for you will depend on your goals and environment.

Both RPM and Debian repositories consist, essentially, of a webserver providing structured files at an expected location. Neither format requires (though, software offerings do exist in this area) an application server providing any sort of intelligence to deliver software. If packages are available at the correct paths with the correct metadata in the correct location, you've got a repository server. As a result, the configuration of the server side of both of these authentication mechanisms does not differ from the typical deployment of those mechanism. That is to say, if you can configure an nginx host to use basic auth, then you can configure nginx serving a package repository to use basic auth. The configuration of the clients, on the other hand, requires a bit more work.

• Basic Auth Configure Server - Configure Nginx - Configure Apache Configure Client
  • RPM
  • Debian
• SSL Client Certificates Configure Server - Nginx - Apache Configure Client
  • RPM
  • Debian
    • Attributions

Basic Auth

Configure Server

Basic Auth specifies the mechanism by which the client presents credentials to the webserver. It does not, however, specify what the webserver then does with those credentials. There are a huge number of options for basic auth backends, from simple htpasswd files to more complex systems such as LDAP or any number of proprietary SSO products. For the sake of simiplicity, we'll use htpasswd files here, but a production grade deployment would likely use something more robust.

I'll be using the below htpasswd file generated using the command htpasswd -B -c repo-users.passwd exampleUser. This command will prompt for a password, hash that password using bcrypt (due to the -B flag) and store the results in ./repo-users.passwd.

We must then configure the webserver to authenticate a resource using this file. Doing so requires ensuring that the htpasswd file is readable by the user running the webserver. Nginx typically runs as the user nginx, while Apache could be run by either httpd or apache depending on distribution. In either case, this user may be determined by checking for which user is running the webserver process using ps. Once proper ownership and permissions are applied to the htpasswd file, basic auth may be configured by placing the following stanzas in the webserver configuration.

Configure Nginx

Configure Apache

The Apache webserver can be configured similarly using an Auth stanza within the Directory block.

Configure Client

Now that the server has been configured, we must tell the client tools to perform an HTTP Basic Auth as part of the connection to a particular repository. Unlike configuring the server, these configurations will be different for each type of repository.

RPM

RPM clients (including yum and dnf) expect the configuration of http basic auth credentials to occur in the repo file for the repository. The RPM repo file spec includes username and password directives that may be used for this purpose.

Entry in repo file

Debian

Debian uses auth.conf (typically at /etc/apt/auth.conf) to associate credentials with a particular repository. The structure of this is somewhat similar to ssh_config. A stanza is opened by specificing the remote host (machine, in auth.conf parlance) to which that configuration applies. Subsequent lines indicate configuration options for that machine until the file ends or another stanza begins.

Entry in /etc/apt/auth.conf

SSL Client Certificates

Most system administrators are likely familiar with using x509 certificates to verify the authenticity of webserver. In addition to verifying that a server is who it claims to be, though, these certificates may also be used to authenticate clients. Client certificate authentication can be a great option in those environments where strong identity verification is required, where clients may be configured with a certificate, and in which the management of a private CA is feasible (more on this in a later post). If those things are true, client certificates may provide stronger security than most basic authentication mechanisms and, depending on other available, might be more easily automated.

Configure Server

In order to configure client certificate authentication, our webserver must have some mechanism for establishing the identity of clients. We do this by trusting a certificate authority (or CA) which issues certificates. If we trust a CA, then we also trust those certificates issued by that authority. This section assumes that a CA already exists which may issue certificates to the clients of this repository server.

Nginx

Apache

Configure Client

RPM

Configuration is done in the repo file.

Debian

Configuration is primarily done in the apt.conf.d file which much must correspond to a repo defined in the sources.list file.

Attributions

Thumnail: "Security By Thy Name" by cogdogblog is licensed under CC BY 2.0