Even if duplicati does not allow authentication per se on its interface, it is still possible to protect access with a password. But since it is accessed through http, in absolute terms, anyone who listens on the network could know it.
When installing a service with a web interface, the reflex to have is as follows:
Install certificates signed by a CA to secure the HTTPS connection.
It may be too much in our case since we only have 4 users in our IS, two of whom know the password and two are too young to sniff the network… But as in all situations, things change ... Without seeing the time pass, the eldest will be 16 years old and will have fun (maybe) with the network (unless she has already done it well before).
To pass the interface to HTTPS, we will go through a reverse proxy. To do this, we will first have to deploy our certificate and our key. Then install apache and use it for HTTPS access.
We have a problem
To use SSL with
duplicati, according to the official documentation, you must start the server with the
--webservice-sslcertificatefile = option, followed by the path to a certificate in PKCS12 format.
In the idea, it is therefore very easy to switch your interface to HTTPs. Except things are never that simple. If you try on Linux, it won't work.
Investigating the problem, we realize that
duplicati is coded in .NET. And that under Linux, .Net is managed by Mono which is an OpenSource implementation of the .NET virtual machine. Mono has problems (see here or [there](https: // forum. duplicati.com/t/ssl-issue-when-using-duplicati/11504)) with the management of certificates in PKCS12 format.
We therefore cannot use this configuration option, and we must work around the problem by installing Apache in front of
If you followed our article about the installation of
duplicati, you have probably changed the port number to access it and opened access to all IPs. If not, check the following points in the
/etc/default/duplicati file anyway, to be sure that it is configured as follows:
--webservice-interface=127.0.0.1: restricts access to the interface to 127.0.0.1.
--webservice-port=8200: allows access to the interface using port 8200.
sudo service duplicati restart
You will not be able to access it for the moment, except from the machine itself.
We are now going to use
apache as a reverse proxy so that it gets between
duplicati and us, the administrators. It is
apache which will then manage the HTTPs part before transferring our requests to
duplicati (in clear, but locally on the machine).
Deployment of the certificate and the key
Let's assume that you already have your PKI and that you already have your certificate and your key. You therefore have the following files:
duplicati.crtfor the certificate,
duplicati.keyfor the key.
We upload these files to the server. Usually, the following directories are used:
/etc/ssl/certs/for the certificate,
/etc/ssl/private/for the key.
We then put the right rights on the files, history that the files belong to root, and that the key file has only write rights.
sudo chown root:root /etc/ssl/certs/duplicati.crt sudo chown root:root /etc/ssl/private/duplicati.key sudo chmod 400 /etc/ssl/private/duplicati.key
If, like us, you have installed
duplicati as a service, these rights will be sufficient.
Installation and activation of modules
We will then install
apache on the command line.
sudo apt-get install apache2
Then we activate all the modules that will be necessary:
- proxy: provides the basic functions of a proxy,
- proxy_http: support for proxy HTTP and HTTPS requests,
- headers: allows you to control the HTTP headers,
- proxy_wsttunnel: provides tunneling support for websockets,
- ssl: provides SSL v3 and TLS v1 support,
- rewrite: allows you to rewrite request URLs on the fly.
sudo a2enmod proxy proxy_http headers proxy_wstunnel ssl rewrite
To configure a virtual host, which will just act as a pass between the rest of the world and
duplicati by adding HTTPs along the way, we create a new file, in
duplicati.conf, with the directives for managing SSL on one side, and those for the reverse proxy on the other.
<VirtualHost *:443> ServerName lynx.arsouyes.org # Guidelines for SSL with Administrators SSLEngine on SSLCertificateFile "/etc/ssl/certs/duplicati.crt" SSLCertificateKeyFile "/etc/ssl/private/duplicati.key" # Reverse proxy guidelines ProxyPreserveHost On ProxyRequests off ProxyPass / http://127.0.0.1:8200/ ProxyPassReverse / http://127.0.0.1:8200/ AllowEncodedSlashes On </VirtualHost>
Slashes encoded in URLs are refused by Apache. But
duplicate uses them when recovering files. The Apache server therefore prevents the correct transmission of the request to
In order to force Apache to forward the request as requested, it is necessary to set
Now that the configuration file is created, we will activate the site:
sudo a2ensite duplicati.conf
Then restart apache with its new configuration.
sudo systemctl reload apache2
Redirection from HTTP to HTTPs
Basically, apache installs a test site in
/etc/apache2/site-available/000-default.conf. We will delete everything that is configured for this host, and be satisfied with a redirection.
<VirtualHost *:80> ServerName lynx.arsouyes.org Redirect permanent / https://lynx.arsouyes.org </VirtualHost>
We restart the configuration one last time.
sudo systemctl reload apache2
You can now access the interface in HTTPs. Thanks to Apache cutting between
duplicati (locally) and the rest of the IS, it is no longer possible to sniff the network and recover the password.
There are many other useful modules of apache that we could now consider restricting access, no longer with a simple password, but to users of an LDAP directory or of a domain, via the module