[squid-users] Squid proxies won't pop up authentication or even attempt

[Amos Jeffries]

On 22/02/19 7:25 pm, amlgp wrote:
> Hi all, I've been trying to troubleshoot this for the last 2 days and it's
> starting to drive me nuts.
> 
> I am running on a Centos 6 server trying to start up some proxies with
> Squid.
> 
> When I manually try to enter my proxy using Firefox, no window pops up for
> authentication and I just time out.

Please be aware that lack of popups does not mean lack of
authentication. If the Browser is already aware of the credentials it is
expected to use from some earlier interaction it *should* be using them
seamlessly without popups.

>From your description above your actual problem is whatever causes the
timeout. That may not be related to authentication, and given your
config below they are not related here either.


Timeouts without a clearly visible error message are more usually
related to the TCP/UDP level connectivity. DNS resolving taking
extremely long times, TCP connections getting lost in routing, NAT
misconfiguration, firewalls dropping packets, Path-MTU problems, and
other things like those.


> I have read that this might be due to a
> http access or acl error but I can't see anything wrong.

You have an order issue with the auth config. More details inline below.
The timeout is a different problem.


> 
> Steps I have taken so far:
> 
> -Set up network interfaces with Centos(all my IP's ping correctly from
> inside the server and outside the server)

By "from outside the server" do you mean from some other test machine or
from the client machine where your Firefox is running?


> -Set up squid.conf with acl and userpass authentication
> > Squid version: squid-3.1.23-24.el6.x86_64
> 

Since this is a new installation please start by trying an up to date
Squid version. This month we are up to v4.6.

You can find newer packages for CentOS in Eliezers repository referenced
from <https://wiki.squid-cache.org/KnowledgeBase/CentOS>.


> Access logs are empty, error logs are currently empty in
> /var/log/squid/squid.out after I fixed the visible_hostname error. Squid
> starts/restarts/stops without errors.
> 

[ Nabble omitted the config details for some reason. I have re-pasted
the non-default config settings in here. ]

...
> 
> #
> # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
> #
> 
> # Example rule allowing access from your local networks.
> # Adapt localnet in the ACL section to list your (internal) IP networks
> # Example rule allowing access from your local networks.
> # Adapt localnet in the ACL section to list your (internal) IP networks
> # from where browsing should be allowed
> http_access allow localnet
> http_access allow localhost
> 
> # And finally deny all other access to this proxy
> http_access deny all
> 

Here is the start of your *auth* problem. Any http_access lines after
here are irrelevant.

The above rules should be letting clients through just fine without
authentication. So the auth behaviour is most likely a secondary issue
not related to the timeout.


> # Squid normally listens to port 3128
> http_port 3128
> 
...
> 
> acl my_ip_198_abc_123_x myip 198.abc.123.x
> tcp_outgoing_address 198.abc.123.x my_ip_198_abc_123_x

Any particular reason for this?

* Squid will default to letting the OS select outgoing IP based on the
rout the connection needs to travel.

* In such old Squid this will break when contacting IPv6 servers. Newer
Squid resolve that by ignoring impossible config requirements.


I suspect these lines are probably why the timeout behaviour is
happening, or that the real problem is something else that led you to
adding these as a workaround.


> 
> auth_param basic program /usr/lib64/squid/ncsa_auth /etc/squid/passwords
> auth_param basic children 5
> auth_param basic realm proxy

> acl ncsa_users proxy_auth REQUIRED
> http_access allow ncsa_users

 ... these rules of yours should be up in the area just below that line
which clearly says "INSERT YOUR OWN RULE(S) HERE".


Also, "allow" action does not require credentials. It only uses
credentials when they are presented and lets other rules do the denial.
Similarly the "REQUIRED" keyword in the ACL only required that the login
presented is correct It does not fetch credentials from the user.
So, unless those other followup denial rules also use credentials the
authentication may never happen.

It is best to do like so:

 http_access deny !ncsa_users
 http_access allow localnet


Also, the fact of the users being in NCSA is only relevant to the helper
and already clear from the name of the helper being used. If you ever
move to a different auth system, different helper (eg PAM), or even
multiple ways to login. That ACL name will become confusing and maybe
incorrect. I recommend 'login' or 'auth' as less confusing names that
help make future changes smaller.


> 
> visible_hostname localhost
>
> 
> I have tried using the actual hostname that shows up when using the
> "hostname" command and there are no changes, so I just replaced it with
> localhost instead.

I'm not sure exactly what you mean by "the visible_hostname error".
There are a few. Usually this displays messages when the hostname is not
able to resolve in DNS.

If Squid is unable to locate the host name, using the one presented by
the 'hostname' command is right. In full for FQDN, or as a subdomain of
your network domain if not.

Keeping in mind that the hostname should be an FQDN that machines in
your network can resolve with that networks DNS (or mDNS in the case of
'.local' TLD names). Newer Squid deal with these things far better and
will default to localhost without you having to do anything.


HTH
Amos