Home / server / Questions / 111885
In Process
Humber
Asked: 2010-02-12 04:49:25 +0800 CST

Securely restrict access to a private Debian repository

  • 772

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

linux ubuntu debian apt

5 Answers

  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.
    • 5

  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.

    • 4

  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).

    • 2

  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).

    • 2

  5. The link in your question shows multiple methods. You want number 2, https + basic authentication.

    • 0