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!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
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):
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
Chyba przekombinowałeś trochę:
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)
Offline
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=0Pam_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
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)
Offline
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
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)
Offline
Strony: 1