I am trying to integrate a passwd/shadow table from an SQL database into a cluster of Debian systems. There are a number of users defined in the SQL database, way too many to allow for the standard flatfile /etc/passwd. So I'd like to combine the two authorization mechanisms and use the best of both worlds: Debian accounts in flatfiles, everyone else in one centralised database.
I have already made NSS look in the database, then in the flatfiles, and it works perfectly well. But with PAM authorisation, I am still experiencing big problems. Versions: libnss-pgsql1 1.0.0-4 libpam-pgsql 0.5.2-7 postgresql 7.3.3-1 Here are the most basic PAM settings I have: /etc/pam.d/common-auth: auth sufficient pam_pgsql.so debug auth required pam_unix.so This is supposed to let people in if pam_pgsql can authorise them. Only if pam_pgsql fails, then pam_unix has the final call. /etc/pam.d/common-passwd: password required pam_passwdqc.so min=disabled,16,12,8,6 password sufficient pam_pgsql.so use_first_pass debug password required pam_unix.so md5 use_first_pass We check the password, then exit if pam_pgsql reports a successful change. If it cannot change the password, the task is on pam_unix Here are the problems I experience: (1) The su and pop3 modules can successfully authorize against pam_pgsql. However, ssh does not work. I get the following log entry: postgres.log: failed to initialize SSL connection: No SSL error reported and sshd receives a signal 11 (segmentation fault). (2) If I try to change the password of a user in the database, it fails with the following error: passwd: Authentication service cannot retrieve authentication info. At the same time, postgres reports: SSL SYSCALL error: EOF detected pq_recvbuf: unexpected EOF on client connecti I can change the password of a user in /etc/passwd just fine. (3) If I place the following into /etc/pam.d/common-account: account sufficient pam_pgsql.so debug account required pam_unix.so then su and pop3 work as before, ssh still does not work, but now I cannot even SSH into the machine with user credentials from /etc/passwd anymore, sshd segfaults. The errors are: postgres.log: failed to initialize SSL connection: No SSL error reported SSH client: debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: channel_free: channel 0: client-session, nchannels 1 Read from remote host gaia.ailab.ch: Connection reset by peer Connection to gaia.ailab.ch closed. All in all, this make pam_pgsql pretty unusable, and I don't really know why. I have never told it to use SSL, and that's where the errors seem to come from. Postgres allows cleartext access: /etc/postgres/pg_hba.conf: host all all 127.0.0.1 255.0.0.0 password why in the world is SSL being used at all? What may be worth noticing is that PostgreSQL started the use SSL when possible in 7.3.3-1. If I connect with psql to localhost, being allowed to use clear text, I am told that I am using a SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256) However, if I connect with psql to localhost on a 7.2.1-2woody2 machine, I do not get this notice and the connection is clear-text. There is no mention in the changelog about this, so maybe Oliver has a comment? And anyone else with some tips or solutions or hints or pads-on-the-back: please give them to me! -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
pgp00000.pgp
Description: PGP signature