Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!

Ogłoszenie

Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.

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

  hardek - Użytkownik

hardek
Użytkownik
Zarejestrowany: 2011-03-16

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

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)

Offline

 

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

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/urandom
Zarejestrowany: 2008-01-07

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

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)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

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

  hardek - Użytkownik

hardek
Użytkownik
Zarejestrowany: 2011-03-16

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

Jacekalex napisał(-a):

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

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)

Offline

 

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

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/urandom
Zarejestrowany: 2008-01-07

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

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)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

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

  hardek - Użytkownik

hardek
Użytkownik
Zarejestrowany: 2011-03-16

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

Jacekalex napisał(-a):

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

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.

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.

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

 

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

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/urandom
Zarejestrowany: 2008-01-07

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

Jak pam-postgres nie funguje, to zobacz pam_mysql, phpmyadmin działa lepiej do phppgadmin, w praktycznym działaniu różnicy nie odczujesz żadnej, poza tym, że Mysql jest przeważnie szybszy w działaniu od Postgresa, za to potrzebuje więcej RAM, bo cała jego szybkość wynika z buforowania w RAM jak największej liczby tablic.

Wiąże się to z minimalnym zagrożeniem integralnosci danych w razie nagłej i niespodziewanej utraty zasilania spowodowanej atakiem termojądrowym, ale jak możesz postawić kilka serwerów, czy robić regularny backup bazy przez CRONA,
to nie ma problemu.

Np to cale Forum chodzi na Mysqlu, i działa jak na razie znośnie (od ponad 10 lat).
Nawet potrafi wylistować moje wszystkie posty w czasie krótszym niż tydzień. :P

Przy okazji, a propo Radiusa, jak chcesz też obsługiwać autoryzację gratów pracowników do firmowej sieci Wifi i do firmowego VPNa zdalnego, to bez Radiusa się nie obejdzie na pewno, nie ma o czym mówić.

Praktycznie wszystkie sprzedawane routery wifi i AP, poza najgorszym szajsem, potrafią autoryzować pacjentów przez Radiusa.
Podobnie jak np OpenVPN i  Strongswan, czyli moim zdaniem aktualnie najlesze serwery VPN na Linuxa.


Przykład Ipsec - Stronswan, Radius i autoryzacja  EAP-TLS z certami X509:
https://www.strongswan.org/testing/testresults/ikev … us/index.html
Taką samą autoryzację można wdrożyć w WPA2 (na tych samych certach klienckich) co mocno upraszcza sprawę firmowego wifi i firmowego VPN.
Praktycznie we wszystkich obecnych na rynku routerach wifi chodzi ten sam demon hostapd, który jest w repozytorium każdego Linuxa.


Pozdro

Ostatnio edytowany przez Jacekalex (2019-02-13 05:45:49)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

Stopka forum

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
Możesz wyłączyć AdBlock — tu nie ma reklam ;-)