Модуль PAM невядомы: які працэс насамрэч не спрацаваў

Чытайце гэтую фразу як сцвярджэнне пра агульны аб'ект і ўказальнік на функцыю, а не пра пароль. Тыя ж словы могуць прыйсці ад OpenVPN плагіна, ад стэка PAM, загружанага для адной службы, або знутры дэмана RADIUS, і гэта тры розныя расследаванні. Спачатку вызначце працэс.

Праверкі ніжэй мяркуюць, што паведамленне ўзнікла праз інтэграцыю Linux-PAM пры ўваходзе ў VPN. Калі яно прыйшло з уласнай канфігурацыі сервера RADIUS, пачынаць трэба з доказаў гэтага дэмана.

Спачатку назвіце працэс, потым пакет

Тры кампаненты называюць модулем, і ні адзін з іх не ўзаемазаменны. Плагін аўтэнтыфікацыі OpenVPN загружаецца дэманам VPN і рэалізуе інтэрфейс зваротнага выкліку гэтага дэмана. Модуль PAM — гэта агульны аб'ект, які загружае libpam для названай службы, які рэалізуе такія пункты ўваходу, як pam_sm_authenticate. Модуль FreeRADIUS — гэта частка ўласнай канфігурацыі гэтага дэмана. Паведамленне з тымі ж словамі можа прыйсці ад любога з трох, таму першае пытанне — які радок журнала яго спарадзіў.

Суаднясіце адзнаку часу адной няўдалай спробы ў журнале VPN і ў сістэмным журнале аўтэнтыфікацыі, затым прачытайце радкі перад зводкай. Канкрэтнае паведамленне загрузчыка звычайна ўжо там.

Прачытайце памылку загрузкі, затым пункт уваходу

PAM паведамляе пра невядомы модуль, калі не можа загрузіць выбраны агульны аб'ект або калі загружаны аб'ект не прадастаўляе функцыю, якую патрабуе гэты радок стэка. Гэта розныя выпраўленні: першае — праблема шляху, упакоўкі ці ABI, другое — неадпаведны пункт уваходу. Радку аўтэнтыфікацыі патрэбны pam_sm_authenticate а радку ўліковага запісу — pam_sm_acct_mgmt, і бібліятэка, якая рэалізуе толькі адзін з іх, не спрацуе для другога, як код дыспетчара паказвае. Знаходжанне файла на дыску не даказвае ні аднаго.

Узяць бібліятэку з падобным імем з іншага дыстрыбутыва ці архітэктуры працэсара — не выпраўленне, і гэта можа пакінуць працэс, які загружае модуль, ніколі не правераны супраць яго libpam. Праверце пакет, якому належыць патрэбны шлях, і рэальную архітэктуру файла, перш чым нешта змяняць.

Захавайце гарантыі, якія даваў стэк

Самы хуткі спосаб заглушыць гэтую памылку — адначасова найгоршы: пазначыць патрабаваны модуль як неабавязковы, выдаліць этап уліковага запісу, або ўставіць безумоўны дазвол. Кожнае з гэтага ператварае няўдалую праверку ў адсутную праверку, і ўваход потым атрымліваецца з прычын, якіх ніхто не планаваў. Скід пароляў і змена агульнага сакрэту таксама не даюць адсутнай функцыі, бо збой адбываецца раней, чым якія-небудзь дадзеныя ўліковага запісу дасягаюць бэкенда.

Шматмодульны стэк мог запусціць іншы бэкенд да збойнага радка, таму памылка не даказвае, што запыт RADIUS не адпраўляўся.

Правярайце ўваход, а не модуль

Пасля выпраўлення неадпаведнасці праверце фактычны шлях допуску. Сапраўдны ўліковы запіс павінен прайсці, няправільныя дадзеныя па-ранейшаму не прайсці, а забаронены запіс па-ранейшаму быць адхілены. Пераканайцеся таксама, што патрабаванне сертыфіката ці дадатковага фактару ўсё яшчэ выконваецца, бо выпраўлены стэк, які прапускае этап, з боку кліента выглядае як поспех.

Чыстая загрузка модуля — гэта прагрэс, а не завершаны тэст.

Запішыце, якая назва службы, якія файлы палітык і якія пункты ўваходу былі задзейнічаны, разам з адзінай спробай, якую вы выкарысталі як доказ. Менавіта гэты запіс робіць наступны выпадак пошукам, а не археалагічным практыкаваннем.