Securely restrict access to a private Debian repository

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.

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.


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