Digest authentication for debian repository - authentication

I created a debian repository using dpkg-scanpackeges for binary packages and connected it with a site which is using apache2 directory listing. It worked fine. After that, I set a digest authentication for the site. I added the following line to the /etc/apt/sources.list file.
deb http://username:password#subdomain.domain.com ./
I can reach the site with browser using this notation, however, when I try to run sudo apt-get update I am getting "401 Unauthorized" error. Is there any way to make apt-get update command be able to authenticate?
This is the configuration file for apache.
<VirtualHost *:80>
ServerName subdomain.domain.com
DocumentRoot /var/www/archive
<Directory /var/www/archive >
Options Indexes FollowSymLinks Multiviews
Order allow,deny
Allow from all
AuthType Digest
AuthName "Restricted Access"
AuthDigestDomain /
AuthDigestProvider file
AuthUserFile /var/www/passwd/archive
Require valid-user
</Directory>
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

I've been researching this topic for a while.
It still not being possible to enable digest authentication for debian apt repositories, despite David Purdy reported this as a bug.
This is important for me, because we have a private repository and want to avoid the sending of the credentials as plain text.
What do you think about writing together a paper about this topic?

Related

Open Street Map Tile Server using mod_tile authentication

I am creating a cluster of tile servers for a client application, due to bandwidth costs we would like to add some sort of authentication to the mod_tiles module in apache. I would prefer a app token using either oauth, but would be fine if I had to use basic auth or something like that.
I had a similar issue and I solved it with the apache basic authentication.
First thing I've done is disabled mod_tile over insecure connection. This is necessary because basic authentication has no encryption and asking users' login/password over insecure connection is a generally bad idea.
Then, my virtual host file (in my case it's /etc/apache2/sites-available/000-default-le-ssl.conf) looks like this:
<IfModule mod_ssl.c>
<VirtualHost *:443>
DocumentRoot /var/www/html
ServerName example.com
ServerAdmin admin#example.com
# Standard dir connfiguration
<Directory /var/www/html>
Options +FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>
# Set BasicAuth on location
<Location />
AuthType Basic
AuthName "Authentication Required"
AuthUserFile /usr/local/.tileauth
Require valid-user
</Location>
# Enable tile server
LoadTileConfigFile /usr/local/etc/renderd.conf
ModTileRenderdSocketName /var/run/renderd/renderd.sock
ModTileRequestTimeout 0
ModTileMissingRequestTimeout 30
# Specify certificate and key using letsencrypt
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>
So, the thing that sets basic authentication is inside <Location> block. The password file is generated like this:
$ htpasswd -c /usr/local/.tileauth tile_server_user
Additionally to that, I would also recommend to use fail2ban to monitor basic authentication attempts, because apache itself has no brute-force attack protection. Hope this helps!

Htaccess password authentication Ubuntu 14.04 LTS

When I upgraded my VPS from Ubuntu 13.10 to 14.04 password protected directories are now giving the error below even if the correct password is entered.
Unauthorized: This server could not verify that you are authorized
to access the document requested. Either you supplied the wrong
credentials (e.g., bad password), or your browser doesn't understand
how to supply the credentials required.
Apache error.log says "No requires line available"
Files are as follows:-
/etc/apache2/sites-available/example.com.conf
<VirtualHost *:80>
ServerName example.com
DocumentRoot /var/www/mysite
</VirtualHost>
<Directory /var/www/mysite>
Options -Indexes
AllowOverride AuthConfig
Order allow,deny
Allow from all
</Directory>
/var/www/mysite/.htaccess
AuthType Basic
AuthName "Protected"
AuthUserFile /var/www/mysite/.htpasswd
require valid-user
/var/www/mysite/.htpasswd
admin:gIlFunhlCwBeY
Please will you help me to get authentication working again.
It appears apache 2.4 has added new values for the auth* modules. A grant is required now to return similar behavior. This is performed such as :
Require all granted
Some of this is outlined on the Apache HTTPd documentation site:
http://httpd.apache.org/docs/2.4/upgrading.html
I suggest referencing that if you are having similar messages in your log entries.
For Ubuntu 14.04 just edit the .htaccess file as below. It works for me:
AuthType Basic
AuthName "Restricted Files"
AuthUserFile /var/www/mysite/.htpasswd
Require valid-user

Access to /svn is forbidden

I set up SVN on Ubuntu using the tutorial How to set up a Subversion (SVN) server on GNU/Linux - Ubuntu, but when I try access the repository from other machine using CMD it says Access to /SVN is forbidden.
I changed the permission of the folder and tried other methods to resolve the issue like configuration of the Apache server, but that did not solve my problem.
How can I fix this problem?
Apache can read and write the repository, but its user (www-data) needs to be given ownership of it:
sudo chown -R www-data:www-data /var/svn/repositories/your_repo
To be able to authenticate users who access the repository a password file is needed:
sudo htpasswd -c /etc/subversion/passwd your_user_name
Enter a password for the user your_user_name. For additional users repeat the command without the -c option to make sure the existing file is appended to rather than replaced.
Then edit the Apache configuration file:
sudo gedit /etc/apache2/apache2.conf
Add the following to the end of the file:
#svn users
<Location /svn>
DAV svn
SVNParentPath /var/svn/repositories/
SVNListParentPath On
AuthType Basic
AuthName "Test"
AuthUserFile /etc/subversion/passwd
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
</Location>
Save the configuration file and restart Apache:
sudo /etc/init.d/apache2 restart
The test repository can now be accessed via:
http://localhost/svn/your_repo
Make sure you have your virtual host set up like this for Apache:
<VirtualHost *:80>
DocumentRoot /home/svn/html
ServerName svn.domainname
ErrorLog logs/svn.domain.com-error_log
CustomLog logs/svn.domain.com-access_log common
<Directory "/home/svn/html">
Order allow,deny
Allow from all
AllowOverride all
</Directory>
<Location /repos>
DAV svn
SVNParentPath /home/svn/repos
Require valid-user
SVNListParentPath on
AuthType Basic
AuthName "Your Super SVN"
AuthUserFile /home/svn/svn-passwords-file-to-be-used-only-when-AuthType-is-used
AuthzSVNAccessFile /home/svn/svn-repos-acl-file-but-optional
</Location>
</VirtualHost>
And make sure Apache can access the repos folder mentioned in SVNParentPath. This issue is mostly because of permissions. Try chmod -R 0777 repos-folder and try again.
This might help someone if they are troubleshooting a setup that had previously been working. Today the new guy at our company inadvertently introduced a typo in the file used by AuthzSVNAccessFile and that caused all of us to experience the dreaded E175013

Apache 2.4 "..authentication failure..:Password Mismatch"

I am running Apache 2.4 in Windows Server 2008 R2. I am attempting to password protect a subdirectory and successfully did so in Apache 2.0. After upgrading I took Apache's advice and am attempting to put the authentication config in httpd.config. I am allowing the reading of the password file and everything appears to be in order, but when I test it I get the following error:
[Mon Apr 01 19:58:36.438476 2013] [auth_basic:error] [pid 3984:tid 788] [client xxx.yyy.254.2:49253] AH01617: user master: authentication failure for "/restricted/file.zip": Password Mismatch
However, I know that I am sending the correct password. See below for my config, any comments are helpful.
<Directory "C:/www/mydir/restricted">
#AllowOverride AuthConfig
#Order allow,deny
#Allow from all
AuthType Basic
AuthName Restricted
AuthUserFile "C:/www/mydir/passwords/pass"
Require valid-user
</Directory>
<Directory "C:/www/mydir">
Require all granted
</Directory>
<VirtualHost *:80>
ServerAdmin admin#.com
DocumentRoot "C:/www/mydir"
ServerName "fakeurl.com"
ErrorLog "C:/www/mydir/logs/error.log"
CustomLog "C:/www/mydir/logs/accesslog/access.log" common
</VirtualHost>
<VirtualHost *:80>
ServerAdmin admin#.com
DocumentRoot "C:/www/mydir"
ServerName "www.fakeurl.com"
ErrorLog "C:/www/mydir/logs/error.log"
CustomLog "C:/www/mydir/logs/accesslog/access.log" common
</VirtualHost>
I just had the same issue, was driving me nuts for the last hour. I can confirm that Steve's suggestion to enter the password in the command line works - so in my case "htpasswd -b passwordfile user password" did the trick.
Here is the relevant bug report at Apache.
Did you create your password with 'htpasswd'?
htpasswd in httpd-2.4.4 is broken (https://issues.apache.org/bugzilla/show_bug.cgi?id=54735).
As I understand it, the problem is specific to htpasswd in httpd-2.4.4, and only occurs if you enter the password manually, so you can work around the issue by doing one of:
supply the password on the command line (e.g. "htpasswd -b .htpasswd user password");
use the version of htpasswd out of httpd-2.4.3;
use Digest Authentication instead of Basic Authentication (htdigest isn't affected);
wait until httpd-2.4.5 is released;
apply the patch in the bug report (which seems to work) and rebuild htpasswd from source.
If you are using Shibboleth, there is a conflict between mod_shib and basic authentication. You can solve it by using the following Apache directive:
ShibCompatValidUser On
For details, see Shibboleth on Apache 2.4 Using Mixed Authentication Methods
I have got same situation on Apache/2.4.6 (CentOS)
None of above solved the problem
Path to htpasswd is correct from $_SERVER['DOCUMENT_ROOT'];
OK maybe some will find it helpfull, I have solved by:
htpasswd -nb username newpassw > <path-to>/htpasswd
btw in Apache 2.4.6 on CentOS 7 problem still exists

SVN Error E175002 while checking out code from repository

While trying to checkout code from a repository online I got the following error:
E175002: REPORT of '/repos/xxx/!svn/vcc/default'
I am trying to checkout the code from a remote computer.
After long research, I finally found a solution the solution was to put allow from all in the svn configuration on httpd.conf:
<Directory /repos>
...
allow from all
...
</Directory>
The svn checkout is working fine now
The above are for apache 2.2
if you use apache 2.4
<Directory /repos>
...
require all granted
...
</Directory>
In my case I had E175002 because of missing DNS records of Subversion server.
I had 2 issues:
a) The svn folder was not readable by apache user
b) Possibly the Directory was not setup correctly
In my example, SVN repository is installed under /home/svn.
1) chown apache.svn -R /home/svn
2) Modify subversion.conf:
<VirtualHost svn.xxx.com:443>
ServerName svn.xxx.com
DocumentRoot /home/svn/
<Directory "/home/svn/">
AllowOverride None
Order allow,deny
Allow from all
Options None
</Directory>
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/pki/tls/certs/ca.crt
SSLCertificateKeyFile /etc/pki/tls/private/ca.key
<FilesMatch "\.(cgi|shtml|jsp|html|htm|php?)$">
SSLOptions +StdEnvVars
</FilesMatch>
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
CustomLog /var/log/httpd/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
alias /svn /home/svn
<Location /svn>
DAV svn
SVNPath /home/svn
SVNListParentPath On
AuthType Basic
AuthName "Repositorio Subversion"
AuthUserFile /etc/httpd/dav_svn.passwd
Require valid-user
allow from all
</Location>
</VirtualHost>
I have changed the windows password and then I have tried checking out the code and I end up with the above unknown host error.
I have restarted eclipse and restarted virtual machine where my eclipse has been set up.
Now I am able to checkout. Hope this helps.
I had the same error, but the cause for the error was, that I am behind a proxy server. I could resolve this issue by configuring SVN to use this proxy server.
Details how to do this can be found in the following discussion:
How to configure a HTTP proxy for svn
in OSX environment, can check ~/.subversion/server
if you are behind proxy, can edit http-proxy-xxxxx attribute
This same problem happened for me and it was possible to finish checking the project out by running the UPDATE SVN command on the incomplete checked out folder.
I had this issue in Code Composer Studio today where only one of the four files I was trying to commit produced the error. Using the command line solved it for me.
More detail:
No commands from the plugin would clear the error, but commit from the command line worked fine. (That likely means either a bug or misconfiguration in the plugin. But as long as the CLI works, I can live with it. The plugin--subclipse--seems to be no longer supported, so I use it when it seems to work, and fall back to the command line when it doesn't. So far, every issue that's appeared in the plugin has not occurred with the command line.)