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

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. — BobDoolittle, Oct 06 '14 at 19:54

score 5 · Answer 1 · edited Apr 13 '17 at 12:13

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://manager@my.repository.org/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 manager@my.repository.org
```

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.

Thanks again MiniQuark. Actually, the updates are unattended, but this is a great method that I could apply for testing purposes. — Humber, Feb 22 '10 at 12:50

score 4 · Answer 2 · answered Feb 11 '10 at 13:05

4

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.

answered Feb 11 '10 at 13:05

Antoine Benkemoun

7,314
3
42
60

1

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. – Humber Feb 11 '10 at 13:16
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. – Antoine Benkemoun Feb 11 '10 at 13:23

MiniQuark · Answer 3 · 2010-02-22T10:45:38.397

2

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

login as root on the client machine
type ssh-keygen, then ssh-copy-id your_login@your.repository.org

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

deb ssh://your_login@your.repository.org/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).

edited Feb 22 '10 at 10:45

answered Feb 21 '10 at 22:41

MiniQuark

3,875
2
21
23

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 Feb 22 '10 at 12:28

MiniQuark · Answer 4 · 2010-02-22T10:45:06.853

2

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

edited Feb 22 '10 at 10:45

answered Feb 22 '10 at 09:42

MiniQuark

3,875
2
21
23

1

This is probably the best solution, also it's not netrc but /etc/apt/auth.conf. Docs here: https://manpages.debian.org/testing/apt/apt_auth.conf.5.en.html – Nicholi Dec 13 '17 at 02:19

score 0 · Answer 5 · answered Feb 21 '10 at 23:06

0

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

answered Feb 21 '10 at 23:06

Justin

3,856
18
21

1

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 – Humber Feb 22 '10 at 12:32
1

chmod 600 /etc/apt/sources.list – Justin Feb 22 '10 at 12:36

Securely restrict access to a private Debian repository

5 Answers5