On 19/08/2014 9:09 a.m., Mike wrote: > Question, when we copy the /etc/squid/passwd file itself from "server 1" > to "server 2", and when using the same squid authentication, why does > server 2 not accept the username and passwords in the file that works on > server 1? > Is that file encrypted by server 1? > Do we need to create a new passwd file from scratch on server 2, and use > a script to "import" it into that new passwd file from server 1? > > The main differences: > Server 1 is 64 bit OS Fedora 8 using squid Version 2.6.STABLE19 > Server 2 is recently installed OS with 32 bit CentOS 6.5 i686 (due to > hardware being 32bit), squid 3.4.5. > > Does that 64 versus 32 bit file setup and creation make an impact? Or > how about the 2.6.x versus 3.4.x? Two possibilities: 1) long passwords encrypted with DES. The current releases Squid NCSA helper checks length of DES passwords and rejects if they are more than 8 charecters long instead of silently truncating and accepting bad input. If your users have long passwords and you encrypted them into the original file with DES then they need to be upgraded. Logging in with only the first 8 characters of their password should still work with DES. 2) OS-specific hash algorithm was used to encrypt. Blowfish and SHA1 algorithms are not universally available. The NCSA helper which is built against a library missing one of these algorithms cannot login users with a password file generated using them. You may have to migrate users via MD5, or ensure libcrypt is used to build the new Squid helper. HTH Amos
