Just recently I came over the issue with my Company's apt repository. The problem was that if we use standard http transport anybody else can get package easily. As Company is packaging its own proprietary software and does not want to share it with everybody, http transport becomes a problem. Not a tragedy but a problem. There is couple of ways how to limit access to package - firewalling, restricting access on web-server level, using ssh as a transport. Quite easy to consume reading on this topic could be found here: Restrict Access To Your Private Debian Repository
In our case, we decided to use https transport + client certificate authentication. Briefly, all it takes is:
- Prepare self-signed certificates, client and server (using easy-rsa);
Configure webserver which fronts repository to accept only https;
In case of nginx it might look like:
server {
listen 443;
root /path/to/public;
server_name secure_repo;
ssl on;
ssl_certificate /etc/nginx/ssl/server.crt;
ssl_certificate_key /etc/nginx/ssl/server.key;
ssl_session_timeout 5m;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:;
ssl_prefer_server_ciphers on;
ssl_client_certificate /etc/nginx/ssl/ca.crt;
ssl_verify_client on;
location / {
autoindex on;
}
}
Put client certificate,client key and ca certificate to /etc/apt/ssl and, in case with Ubuntu, add 00https file to /etc/apt/apt.conf.d:
Debug::Acquire::https "true";
Acquire::https::example.com {
Verify-Peer "true";
Verify-Host "false";
CaInfo "/etc/apt/ssl/ca.crt";
SslCert "/etc/apt/ssl/client.crt";
SslKey "/etc/apt/ssl/client.key";
};
Keep in mind, that if you are using self-signed certificate it is important to switch off host verification: Verify-Host "false"; If you don't do this, you'll catch an error:
SSL: certificate subject name (blah-blah-blah) does not match target host name 'example.com'
And here we go, there is no more unauthorized access to repository. So this is quite useful and powerful thing.
