Re: debian-user-digest Digest V2013 #1593
On 29/12/13 14:10, Kevin O'Gorman wrote:
> On Sat, Dec 28, 2013 at 4:28 PM,
> <debian-user-digest-request@lists.debian.org> wrote:
>
>> Date: Sun, 29 Dec 2013 06:36:23 +1100
>> From: Scott Ferguson <scott.ferguson.debian.user@gmail.com>
>> To: debian-user@lists.debian.org
>> Subject: Re: Upgraded apache 2.2 -> 2.4 and cannot get passwords to work
>> Message-ID: <[🔎] 52BF2837.2050101@gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 7bit
>>
>> On 29/12/13 03:52, Dave Woyciesjes wrote:
>>> On 12/28/2013 11:09 AM, Kevin O'Gorman wrote:
>>>> My modest-sized web server was recently upgraded. There were problems
>>>> with access control, fairly well documented and fairly easily fixed.
>>>>
>>>> Authentication, on the other hand, acts as if it's not there -- anyone
>>>> and everyone is let into the few parts that used to be controlled. So
>>>> I have them offline for now. I don't see any writeups of problems
>>>> with this, so perhaps the way I solved access control borked the
>>>> authentication.
>>>>
>>>> I have everything in /var/www and /www, and the authenticated parts
>>>> are in /www, with a Directory stanza containing authentication info
>>>> for each of the two (but apache is apparently ignoring them). I don't
>>>> have /srv.
>>>> Authentication is by a simple text file with less than 100 entries.
Handy because mod_auth_file usually dies before it'll process more than
100 users in a file (that's what the auth_db mods are for)
<snipped>
>>
>> Please expand on your authentication system and the problems plus error
>> messages.
Your authentication scheme seems to be .htaccess, type=basic,
provider=file, authorization=unknown
Please post the output of:-
$ dpkg --get-selections | grep _mod
>>
>> Kind regards
>>
>
> There are about a dozen directories, I won't mention them all, but
> here's the general pattern.
> Consider these aliases
>
> #Alias /theory /www/theory
> Alias /hex /www/web
> Alias /Chocoholic /www/Chocoholic
> Alias /Games /www/Games
> (and more in a similar vein)
>
> The theory one is commented out for now because the authentication
> does not work: it's as if the authentication is not even mentioned and
> access goes smoothly for everyone. The uncommented ones do not have
> authentication, so they work as-is.
>
> /www contains the stuff where the problem is. It's enabled by this stanza:
> <Directory /www>
> AllowOverride FileInfo AuthConfig Limit Indexes
> Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
> <Limit GET POST OPTIONS>
> Require all granted
> </Limit>
> <LimitExcept GET POST OPTIONS>
> Require all denied
> </LimitExcept>
> </Directory>
>
> It has a subdirectory where I share stuff with some collaborators, and
> where I want to authenticate those collaborators:
> <Directory /www/theory>
> AuthType Basic
NOTE: Basic sends passwds *un*encrypted. I'm assuming you have mod_ssl
installed and configured. mod_digest doesn't have that problem. basic
also dies a slow death if fed more than a hundred or so users in a file.
Check that you have the following installed and enabled:-
mod_auth_basic
mod_authn_file
an authorization module (i.e. mod_authnz_ldap or mod_authz_$something)
> AuthName "OHex Advanced"
> AuthBasicProvider file
> AuthUserFile /etc/apache2/hextheory-passwords
I'm guessing the path and permissions are correct for the users file.
Check the format is correct.
Each line has:-
$username; $encrypted password.
NOTES:-
;mod_authn_file will use the first instance of a given username's
password (this prevents realm insanity)
;use htpasswd to encrypt the passwords if you are *not* using
mod_auth_basic, if you are using mod_auth_digest instead you'll need to
reflect it in authentication and use htdigest to encrypt the passwords
instead. (I've not tried to use both).
;AuthUserFile is overridden by AuthConfig
> AuthGroupFile /dev/null
Huh?
I thought anyone in the groupfile had to also be in the password file or
auth would fail. With nothing in the group file..... :/
You'll also need mod_authz_groupfile installed and enabled.
> Require valid-user
This line makes the preceding line redundant. If you are *not* using
groups I'd suggest you comment out AuthGroupFile
> AllowOverride FileInfo AuthConfig Limit Indexes
> Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
> <Limit GET POST OPTIONS>
> Require all granted
The above lines stop POST but allow everything else ( GET, POST, PUT,
DELETE, CONNECT, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK,
and UNLOCK). Is that what you wanted?
> </Limit>
> <LimitExcept GET POST OPTIONS>
> Require all denied
I suspect that directive won't work....
> </LimitExcept>
> </Directory>
>
>
> So: what can I do to have authentication work again as it did in apache 2.4?
>
>
> Hmm, that was poorly put. Let's try this:
> So: what can I do to have authentication work in apache 2.4 as it once
> did in apache 2.2?
/var/log/apache2/error.log could be helpful - you should have got some
errors when you were trying to use .htaccess authentication, if not set
loglevel to alert and renable authentication.
If you enable mod_dumpio (and set the directive "DumpIOOutput On") you
can get everything after between browser and server (bar SSL).
Kind regards
Reply to: