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
Related
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!
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?
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
I am using a new CentOS 6.3 minimal install with fresh httpd installed
When I go to my virtual host it is showing me the apache test page, and then if I go to mydomain.co.uk/index.html (That I have just set up to test with) it says forbidden. All the usual answers to this don't seem to be working and I have honestly looked through tons of forums and other people questions/answers and nothing seems to be working for me.
I have created a group called 'www' that I have added the user 'apache' to.. This is my root directory in httpd.conf file, I have left it pretty open just for testing:
<Directory />
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from All
</Directory>
This is my vhosts file:
NameVirtualHost *:80
<VirtualHost *:80>
DocumentRoot /var/www/html/
</VirtualHost>
<VirtualHost *:80>
ServerName domain.co.uk
ServerAlias www.domain.co.uk
DocumentRoot /home/domain/public_html
<Directory "/home/domain/public_html">
Options Indexes FollowSymLinks ExecCGI
AllowOverride AuthConfig FileInfo
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
From /home/ onwards I have set the group to www
When ls -lA on home folder I get
drwxrwsr-x. 5 root www 4096 Feb 5 20:57 home
The error I am getting in my logs file is a permission one:
[Wed Feb 06 10:24:42 2013] [error] [client 62.254.7.226] (13)Permission denied: access to /index.html denied (filesystem path '/home/domain/public_html/index.html') because search permissions are missing on a component of the path
As is everything else in that folder. I really don't know what to try next. I have come to the point of needing to ask for my specific setup as following other tutorials or answers has not worked for me. Any help is greatly appreciated!
Error 13 means that the user/group specified in your apache configuration (httpd.conf) didn't have permission to access the files. The files, and all the directories above them, need to have permission that allow for that user and group.
One of the trickier bits can be extended permissions. If you are running selinux, the server user could be denied because of the extended permissions on the file. To check for this, run (from the command line):
setenforce 0
If the problem goes away (i.e. the page is visible) then your extended permissions are blocking access.
See http://wiki.apache.org/httpd/13PermissionDenied for details.
Selinux is not expecting the http server to access files under /home/domain since it is not a standard path.
You can change it with following command:
chcon -R --type=httpd_sys_rw_content_t /home/domain/public_html/
I am getting
[Tue Apr 24 12:12:55 2012] [error] [client 127.0.0.1] client denied by server configuration: /labs/Projects/Nebula/bin/
My directory structure looks like (I am using Symfony 2, should be similar structure for other web frameworks)
I have vhosts setup like:
<VirtualHost nebula:80>
DocumentRoot "/labs/Projects/Nebula/web/"
ServerName nebula
ErrorLog "/var/log/httpd/nebula-errors.log"
</VirtualHost>
<Directory "/labs/Projects/Nebula/">
Options All
AllowOverride All
Order allow,deny
Allow from 127.0.0 192.168.1 ::1 localhost
</Directory>
I wonder whats the problem and how do I fix it?
Apache 2.4.3 (or maybe slightly earlier) added a new security feature that often results in this error. You would also see a log message of the form "client denied by server configuration". The feature is requiring an authorized user identity to access a directory. It is turned on by DEFAULT in the httpd.conf that ships with Apache. You can see the enabling of the feature with the directive
Require all denied
This basically says to deny access to all users. To fix this problem, either remove the denied directive (or much better) add the following directive to the directories you want to grant access to:
Require all granted
as in
<Directory "your directory here">
Order allow,deny
Allow from all
# New directive needed in Apache 2.4.3:
Require all granted
</Directory>
OK I am using the wrong syntax, I should be using
Allow from 127.0.0.1
Allow from ::1
...
In Apache 2.4 the old access authorisation syntax has been deprecated and replaced by a new system using Require.
What you want then is something like the following:
<Directory "/labs/Projects/Nebula/">
Options All
AllowOverride All
<RequireAny>
Require local
Require ip 192.168.1
</RequireAny>
</Directory>
This will allow connections that originate either from the local host or from ip addresses that start with "192.168.1".
There is also a new module available that makes Apache 2.4 recognise the old syntax if you don't want to update your configuration right away:
sudo a2enmod access_compat
I had this issue using Vesta CP and for me, the trick was remove .htaccess and try to access to any file again.
That resulted on regeneration of .htaccess file and then I was able to access to my files.
Can you try changing "Allow from 127.0.0 192.168.1 ::1 localhost" to "Allow from all".
If that fixes your problem, you need to be less restrict about where content can be requested from
Here's my symfony 1.4 virtual host file on debian, which works fine.
<Directory /var/www/sf_project/web/>
Options All Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>
If you wan't to restrict access to a specific ip range, e.g. localhost use this:
Allow from 127.0.0.0/8
The mod_authz_host is responsible for filtering ip ranges. You can look up detailed things in there.
But maybe the problem could be related to some kind of misconfiguration in your "apache2.conf".
On what OS is the apache running?
if you are having the
Allow from All
in httpd.conf then make sure us have
index.php
like in the below line in httpd.conf
DirectoryIndex index.html index.php
In my case the key was:
AllowOverride All
in vhost definition.
I hope it helps someone.
This code worked for me..
<Location />
Allow from all
Order Deny,Allow
</Location>
Hope this helps others