Forum Debian Users Gang

hardek · 2019-01-04 22:30:25

Witam

Od kilku tygodni walczę z libnss-pgsql + libpam-pgsql na Debian Stretch (wszystko na razie testowo, na tej samej maszynie). Na początku, bez jakichkolwiek problemów skonfigurowałem serwer PostgreSQL oraz samą baze danych wprowadzając do niej testowego użytkownika o nazwie test oraz skonfigurowałem samą bibliotekę libnss-pgsql. Wszystko działa (polecenia getent passwd, getent shadow, getent group zwracają prawidłowe wartości), użytkownik test jest widoczny w systemie. Następnie mając użytkownika, próbowałem skonfigurować libpam-pgsql, tak by móc zalogować się na niego, lecz tutaj zaczęły się schody, nie działa to tak jak powinno - tzn. autoryzacja działa, lecz nie wyświetla się konsola (loguje się na użytkownika poprzez su - test) - wygląda to tak, jakby sesja użytkownika uległa zawieszeniu.

Konfiguracja została wykonana bazując na następujących opisach:
https://github.com/pam-pgsql/pam-pgsql
https://jbsky.fr/authentification-pampostgres/
https://habr.com/sandbox/25719/

W logu mam następujące zapisy (user - użytkownik standardowy użytkownik systemowy, na którego jestem zalogowany):

Kod:

Jan  4 21:58:11  debian-nss PAM_pgsql [21106]: attempting to authenticate: test, select password form account where username = %u
Jan  4 21:58:11  debian-nss PAM_pgsql [21106]: query: select password from account where username = %u
Jan  4 21:58:11  debian-nss PAM_pgsql [21106]: (su) user test authenticated.
Jan  4 21:58:11  su[21106]:  pam_unix(su:account): account test has password changed in future
Jan  4 21:58:11  su[21106]:  Successful su for test by user
Jan  4 21:58:11  su[21106]: + /dev/pts/36   user:test
Jan  4 21:58:11  su[21106]: pam_unix(su:session): session opened for user test by (uid=1000)

Z zapisów można wywnioskować, że uwierzytelnienie użytkownika test przeszło bez problemów, natomiast problemem wydaje się być otwarcie sesji (wisi na ": session opened for user test by (uid=1000)"). Po wielu próbach oraz intensywnych poszukiwaniach zauważyłem, że w plikach konfiguracyjnych /etc/pam.d/common-session oraz /etc/pam.d/common-session-noninteractive wprowadzałem zapis dot. pam_pgsql.so, natomiast w logu mam pam_unix (czy on to w ogóle bierze pod uwage?). Czy należy wykonać dodatkowe kroki, by zmusić to do działania czy mój tok rozumowania jest nieprawidłowy? Byłbym wdzięczny za jakąkolwiek pomoc lub podsunięcie rozwiązania. Dodam, że wszystko było instalowane ze standardowego repozytorium.

Ostatnio edytowany przez hardek (2019-01-04 22:31:21)

Jacekalex · 2019-01-28 15:57:44

Chyba przekombinowałeś trochę:

Kod:

cat /etc/pam.d/xmpp
auth required /lib64/security/pam_mysql.so user=USER_BAZY passwd=HASEŁKO_DO_BAZY host=localhost db=bazaauth table=pacjenci usercolumn=username passwdcolumn=password crypt=0
account required /lib64/security/pam_mysql.so user=USER_BAZY passwd=HASEŁKO_DO_BAZY host=localhost db=bazaauth table=pacjenci usercolumn=username passwdcolumn=password crypt=0

Pam_Mysql, Salsauthd i Prosody, wszystko działa bez problemu.

Podejrzewam, że identycznie musisz zrobić z Postgresem.

Poza tym pam_*sql nieźle się sprawdza przy serwerze poczty, uwierzytelnieniu przez serwer www, ftp czy jabbera, ale logowanie po SSH bym zostawił przy standardowej autoryzacji Linuxa.

Wystarczy uceglenie serwera SQL albo bazy z autoryzacją przez badsektor na dysku,
i możesz uceglić cały system, jeśli całą autoryzację zostawisz na jednym serwerze SQL.
Także lepiej z tym uważać.

Pozdro

Ostatnio edytowany przez Jacekalex (2019-02-12 16:51:40)

hardek · 2019-02-12 16:37:47

[quote=Jacekalex]Chyba przekombinowałeś trochę:

Kod:

cat /etc/pam.d/xmpp
auth required /lib64/security/pam_mysql.so user=USER_BAZY passwd=HASEŁKO_DO_BAZY host=localhost db=bazaauth table=pacjenci usercolumn=username passwdcolumn=password crypt=0
account required /lib64/security/pam_mysql.so user=USER_BAZY passwd=HASEŁKO_DO_BAZY host=localhost db=bazaauth table=pacjenci usercolumn=username passwdcolumn=password crypt=0

Pam_Mysql, Salsauthd i Prosody, wszystko działa bez problemu.

Podejrzewam, że identycznie musisz zrobić z Postgresem.

Poza tym pam_*sql nieźle się sprawdza przy serwerze poczty, uwierzytelnieniu przez serwer www, ftp czy jabbera, ale logowanie po SSH bym zostawił przy standardowej autoryzacji Linuxa.

Wystarczy uceglenie serwera SQL albo bazy z autoryacją przez badsektor na dysku,
i możesz uceglić cały system, jeśli całą autoryzację zostawisz na jednym serwerze SQL.
Także lepiej z tym uważać.

Pozdro[/quote]
Dzięki za podpowiedź. Takiego rozwiązania również próbowałem, lecz efekt jest ten sam. Kilka osób próbowało również wykonać to samo zadanie, z takim samym efektem. Prawdopodobnie występuje problem z pakietem lub z samą komunikacją (pam -> systemd). Na chwile obecną jedynym rozwiązaniem, a w zasadzie obejściem jest zastosowanie oprogramowania samba (np. w roli DC) + winbind, stworzenie w DC linuksowego konta - wtedy logowanie działa bez problemu. Wydaje mi się, że libpam-*sql jest mechanizmem trochę zapomnianym, używanym wyłącznie do uwierzytelniania w poszczególnych usługach niż w samym systemie.

Ostatnio edytowany przez hardek (2019-02-12 16:41:55)

Jacekalex · 2019-02-12 16:56:27

Pewnie pam_pgsql koliduje z innymi modułami pam.
Może chodzi o pam_systemd czy coś innego.

Dlatego pam_*sql się używa tylko do lekkich usług niezbyt krytycznych.

Trzymanie kont systemowych na pam_*sql to więcej potencjalnych kłopotów niż realnych korzyści.

Jeśli natomiast chciałbyś na jednym haśle pocztę, jabbera, webmaila na serwerze http i serwer ftp, to wtedy owszem, pam-*sql jest idealnym rozwiązaniem, prostym i skutecznym.

Jak koniecznie upierasz się przy autoryzacji w bazie SQL, to raczej postaw Radiusa ze wsparciem SQL i autoryzację pam_radius.
To powinno zaskoczyć podobnie jak Samba.

I pam-sql nie jest zapomniany, ale żaden rozumny administrator serwera nie używa go do autoryzacji systemowej, bo do SSH używa się kluczy SSH, natomiast do powłoki systemu się lamerów nie wpuszcza, żeby kłopotów nie narobili.

Ostatnio edytowany przez Jacekalex (2019-02-12 17:08:00)

hardek · 2019-02-13 00:17:06

[quote=Jacekalex]Pewnie pam_pgsql koliduje z innymi modułami pam.
Może chodzi o pam_systemd czy coś innego.[/quote]
W trakcie wcześniejszych prób powyłączałem wszystkie zbędne moduły (włącznie z libpam-systemd), lecz niestety nie rozwiązało to problemu.

Jak koniecznie upierasz się przy autoryzacji w bazie SQL, to raczej postaw Radiusa ze wsparciem SQL i autoryzację pam_radius.
To powinno zaskoczyć podobnie jak Samba.[/quote]
Wygląda ciekawie. W wolnej chwili zainstaluję i przetestuje.

I pam-sql nie jest zapomniany, ale żaden rozumny administrator serwera nie używa go do autoryzacji systemowej, bo do SSH używa się kluczy SSH, natomiast do powłoki systemu się lamerów nie wpuszcza, żeby kłopotów nie narobili.[/quote]
Tutaj zamysł był nieco inny. Chciałem wykorzystać baze danych PostgreSQL jako centralną baze użytkowników i zarządzać nimi z jednego miejsca. Przykład: w jednej bazie tworze zwykłe konto dla Księgowej o nazwie basia i ta osoba może zalogować się na konto basia z dowolnego komputera w firmie (przy założeniu, że komputer kliencki ma zainstalowany system Linux, będzie korzystał z libnss-pgsql + libpam-pgsql i nie będzie serwerem). PostgreSQL oczywiście będzie się replikował na inny serwer zapewniając wysoką dostępność.

Offline

Time (s)	Query
0.00011	SET CHARSET latin2
0.00004	SET NAMES latin2
0.00100	SELECT u., g., o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='18.117.154.134' WHERE u.id=1
0.00066	REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '18.117.154.134', 1732194484)
0.00055	SELECT * FROM punbb_online WHERE logged<1732194184
0.00049	SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=30797 AND t.moved_to IS NULL
0.00006	SELECT search_for, replace_with FROM punbb_censoring
0.00159	SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=30797 ORDER BY p.id LIMIT 0,25
0.00111	UPDATE punbb_topics SET num_views=num_views+1 WHERE id=30797
Total query time: 0.00561 s

Forum Debian Users Gang

Ogłoszenie

#1 2019-01-04 22:30:25

hardek - Użytkownik

Niemożność logowania się na użytkowników (pam-pgsql)

Kod:

#2 2019-01-28 15:57:44

Jacekalex - Podobno człowiek...;)

Re: Niemożność logowania się na użytkowników (pam-pgsql)

Kod:

#3 2019-02-12 16:37:47

hardek - Użytkownik

Re: Niemożność logowania się na użytkowników (pam-pgsql)

Kod:

#4 2019-02-12 16:56:27

Jacekalex - Podobno człowiek...;)

Re: Niemożność logowania się na użytkowników (pam-pgsql)

#5 2019-02-13 00:17:06

hardek - Użytkownik

Re: Niemożność logowania się na użytkowników (pam-pgsql)

#6 2019-02-13 05:25:54

Jacekalex - Podobno człowiek...;)

Re: Niemożność logowania się na użytkowników (pam-pgsql)

Stopka forum

Informacje debugowania