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 <madduck@debian.org>
: :' : 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!
Attachment:
pgpbOkXaOT9wC.pgp
Description: PGP signature