Securely restrict access to a private Debian repository

Question

I was looking for a method to restrict access to a private Debian repository and be able to authenticate to it non-interactively (i.e. using a script)

The most useful article I found if actually one from Debian administration site but the secure method uses ssh and public/private keys. It works great but each host's public key needs to be inside the remote authorized_keys file to successfully authenticate. It doesn't says nothing about providing password to ssh:// but I suppose it should be possible.

Have you tried other alternatives (e.g. ftps)?

Thanks in advance

Solution 1

If you always run apt-get on your servers by hand (no automatic apt-get commands launched by crons), then you might consider using ssh agent forwarding. This avoids having to manage one public/private keypair per server you manage, and it's probably safer than leaving private keys on every server.

Initial configuration - connect to the servers you want to manage, and add something like this to /etc/apt/sources.list (this example assumes you want your servers to connect to the manager account):

    deb ssh://[email protected]/path other stuff

• create a pair of private/public keys on your own computer, with your login johndoe for example (provided your computer runs on debian: if not, you can do this from a debian server dedicated to management):

  ssh-keygen
  

• make sure it is protected by a strong keyphrase

• copy your public key to the repository server in /home/manager/.ssh/authorized_keys:

  ssh-copy-id [email protected]
  

Once per management session

• start the ssh agent on your machine by typing:

  eval `ssh-agent`
  

• add your key to the agent (this will require your passphrase):

  ssh-add
  

Managing a server

• connect to the server you want to manage using ssh -A (-A activates agent forwarding):

  ssh -A some.server.org
  

• switch to root (if you want to use sudo you need to configure /etc/sudoers or else sudo will break agent forwarding, read this):

  su
  

• you should now be able to connect to the repository's manager account using ssh without typing your password again, thanks to agent forwarding. Therefore, apt-get should work just fine:

  apt-get udate
  

Ending your management session

• Once you have finished managing your servers, remove your keys from the agent:

  ssh-add -D
  

Advantages

• Not much initial configuration is required
• Just one private key is required
• Private key is protected by a strong passphrase
• If someone gains root access to one of your server, they will not have immediate access to your repository server.
  • Note that if the hacker is patient and qualified, he can wait until you connect to the server using agent-forwarding, and he can hijack the forwarding mechanism in order to gain access to your repository server.
  • To help prevent that, you can use ssh-ask in order to accept/refuse every attempt to use your key.
  • In any case, the hacker will not gain access to the private key itself: he will just be able to hijack the forwarding mechanism in order to use the key, and only during the time you are connected to the server.

Solution 2

One way to do this is just to allow a certain set of IPs to access the repository. This works very well for LAN and VPN.

Simple and efficient.

Solution 3

The ssh + public/private keys solution is not that bad:

• login as root on the client machine
• type ssh-keygen, then ssh-copy-id [email protected]

• edit /etc/apt/sources.list and add something like:

  deb ssh://[email protected]/path other stuff
  

Granted, it requires you to put each server's public key in the ~/.ssh/authorized_keys file on the server, but it's not that complicated (see above) and it gives you control over which servers you allow or not at any given time (you can remove a key at any time in authorized_keys).

Solution 4

You could setup an https access to your repository, secured by login/password (basic authentication). The problem is that you need to put the cleartext login/password in /etc/apt/sources.list (note: there is a patch to allow the login/password to be put in /root/.netrc instead).

View more solutions

Comments

[BobDoolittle]

The problem I have with the article above is that it doesn't only give APT repository access - it gives shell access to my APT repository machine. That's unacceptable risk.

[Humber]

Thanks Antoine :). Actually, the repository that I have now is accessible using that method (http over a OpenVPN connection). I restrict the IPs that belong to the VPN. The drawback here is that every host needs to be connected to the VPN to access the repo, with is a little annoying (manage several certificates/keys). Sorry for not specifying that in the question.

[Antoine Benkemoun]

True, it's bothersome to manage OpenVPN but it makes managing the security to your repository very simple. Also, users don't have to bother with credentials once inside the VPN.

[Humber]

Thanks MiniQuark. Yes, this solution isn't that bad, but ssh-copy-id doesn't work if password authentication is disabled in openssh server. I thought on spreading the same key file on each client using the repository to be able to use it. For more security, the a user with minimal permissions would be used. It's almost the same as sharing credentials. I'm currently testing this method to check how behaves/work.

[Humber]

Thanks Justin. I think that https transport with apt only works if apt-transport-https is installed. This is an interesting alternative. The only drawback is the credentials in sources.list

[Justin]

chmod 600 /etc/apt/sources.list

[Humber]

Thanks again MiniQuark. Actually, the updates are unattended, but this is a great method that I could apply for testing purposes.

[MiniQuark]

My pleasure! :) Glad if it helps.

[Nicholi]

This is probably the best solution, also it's not netrc but /etc/apt/auth.conf. Docs here: manpages.debian.org/testing/apt/apt_auth.conf.5.en.html