ProtectHome વિરુદ્ધ TOTP બીજ: VPN લોગિન કેમ નિષ્ફળ જાય છે

પ્રમાણક નવો છ-અંકનો કોડ બતાવે છે, VPN તેને નકારે છે, અને એ જ કોડ તમારા પોતાના શેલમાંથી પરીક્ષણ કરો ત્યારે બરાબર ચકાસાય છે. એ જ અંતર આખી વાર્તા છે. જે PAM મોડ્યુલ નોંધણીનું રહસ્ય ખોલી શકતું નથી, તે ખોટા કોડ જેવી જ દેખાતી નિષ્ફળતા પરત કરે છે, અને ઘરની ડિરેક્ટરીઓ છુપાવતું સેવા વાતાવરણ તેનું સામાન્ય કારણ છે. કોઈપણ પરવાનગી ઢીલી કરતાં પહેલાં નક્કી કરો કે તમે ત્રણમાંથી કઈ સ્થિતિમાં છો.

આ ત્રણ નિષ્ફળતાઓમાંથી કઈ છે?

પ્રથમ એ રહસ્ય છે જે મોડ્યુલ બિલકુલ વાંચી શકતું નથી. બીજું એ રહસ્ય છે જે તે વાંચી શકે છે પણ અપડેટ કરી શકતું નથી. ત્રીજું એ કોડ છે જે ખરેખર ખોટો છે, સામાન્ય રીતે ઘડિયાળના ડ્રિફ્ટ અથવા ફરી વપરાયેલા મૂલ્યને કારણે.

એક નિષ્ફળ પ્રયાસ માટે સેવા જર્નલ અને સિસ્ટમ પ્રમાણીકરણ લોગ વાંચીને તેમને અલગ કરો, પછી ખાતરી કરો કે પ્લગઇન કઈ PAM સેવા લોડ કરે છે અને તે સેવા કઈ મોડ્યુલ લાઇન વાપરે છે. સામાન્ય પ્રમાણીકરણ નિષ્ફળતાનો સંદેશ તેમને અલગ કરતો નથી, અને સફળ જાતે કરેલો કસોટી પણ નહીં, કારણ કે તમારો શેલ સેવાનું વાતાવરણ નથી.

જ્યારે ફક્ત સેવા નિષ્ફળ જાય ત્યારે યુનિટનું ફાઇલસિસ્ટમ દૃશ્ય સામાન્ય દોષિત હોય છે.

systemctl show -p ProtectHome -p ProtectSystem -p ReadWritePaths [email protected]
ls -l /var/lib/vpn-otp/*/.google_authenticator 2>/dev/null | head -n 20

વિકલ્પ A: રહસ્યને ઘરની બહાર ખસેડો

જ્યારે સેવા /home છુપાવે છે અને તમે એ રક્ષણ રાખવા માંગો છો, ત્યારે રહસ્યને એવી જગ્યાએ સંગ્રહો જ્યાં તે તેને જોઈ શકે. મોડ્યુલ secret= પાથ અને ફાઇલ કામગીરી કરતું user= ખાતું સ્વીકારે છે, જે કેન્દ્રીય ભંડારને ઘણી ઓળખોને સેવા આપવા દે છે.

આ સુઘડ વિકલ્પ છે, અને તેને સૌથી વધુ કાળજીની જરૂર છે, કારણ કે વહેંચાયેલો ભંડાર એક ડિરેક્ટરીને દરેક ખાતાની સુરક્ષા સીમા બનાવે છે.

auth required pam_google_authenticator.so secret=/var/lib/vpn-otp/${USER}/.google_authenticator user=vpn-otp

તેના પર ભરોસો કરતાં પહેલાં ત્રણ વસ્તુ ચકાસો: ખાતું અસ્તિત્વમાં છે, મોડ્યુલની કાર્ય પ્રક્રિયા તેમાં બદલાઈ શકે છે, અને ફાઇલો પ્રતિબંધક મોડ સાથે તેની માલિકીની છે. user= સાથે ~ અથવા ઘર-ચલ પાથનો ઉપયોગ કરશો નહીં, અને પાથ કામ કરે તે માટે મોડ્યુલની માલિકી તપાસ બંધ કરશો નહીં. પાસવર્ડ તબક્કો અને બાકીનો સ્ટેક અકબંધ રાખો.

વિકલ્પ B: ફાઇલ રહેવા દો અને પાથ ખોલો

જો રહસ્ય વપરાશકર્તાના ઘરમાં જ રહેવું જોઈએ, તો યુનિટને એક જ ડિરેક્ટરી સમાવતું દૃશ્ય જોઈએ જે હોસ્ટ પરની દરેક ઘર-ડિરેક્ટરી ખુલ્લી ન કરે. drop-in સેન્ડબોક્સ કરેલા ઘર નીચે સાંકડી મર્યાદાનું બાઇન્ડ માઉન્ટ ઉમેરી શકે છે.

આ વપરાશકર્તા દીઠ માલિકીને મોડેલ તરીકે રાખે છે, પરંતુ સેન્ડબોક્સ બદલાય ત્યારે સમીક્ષા કરવી પડે એવા યુનિટ ફેરફારની કિંમતે.

બે મર્યાદા સરળતાથી ચૂકી જવાય છે. સેન્ડબોક્સ જે ડિરેક્ટરી છુપાવે છે તેની નીચે ઉમેરાયેલો ફક્ત-વાંચન પાથ તેને ખુલ્લો કરતો નથી, કારણ કે પિતૃ ડિરેક્ટરી ત્યાં જ નથી. અને જો મોડ્યુલે સ્થિતિ અપડેટ કરવી હોય તો માઉન્ટ લખી શકાય તેવું હોવું જોઈએ, જે આગલો વિકલ્પ લાવે છે. drop-in ને /usr/lib નીચેના પેકેજ કરેલા યુનિટને સંપાદિત કરવાને બદલે અલગ ફાઇલ તરીકે લખો, જેથી પેકેજ અપગ્રેડ તેને શાંતિથી રદ ન કરે.

વિકલ્પ C: સેન્ડબોક્સ રાખો અને સ્થિતિ લેખન સુધારો

રહસ્ય વાંચવું એ પ્રમાણીકરણનો ફક્ત અડધો ભાગ છે. મોડ્યુલ સમય-વિચલન માહિતી, પુનરાવર્તન સંરક્ષણ અથવા કાઉન્ટર ફરી લખી શકે છે, અને વાંચન ચકાસણી પાસ કરતી ફાઇલ લેખનમાં હજુ પણ નિષ્ફળ જઈ શકે છે.

એ નિષ્ફળતા આ પ્રયાસમાં નહીં પણ આગલા પ્રયાસમાં ખરાબ કોડ જેવી લાગે છે, તેથી તેને ઘડિયાળના ડ્રિફ્ટ સાથે ભૂલવામાં આવે છે.

આખું ઘર લખી શકાય તેવું બનાવવાને બદલે તેને પોતાની લખી શકાય તેવી ડિરેક્ટરી આપો અને રહસ્યનો પાથ ત્યાં નિર્દેશ કરો. ડિરેક્ટરીનો માલિક, ફાઇલસિસ્ટમની ખાલી જગ્યા અને યુનિટ બીજે લેખન મર્યાદિત કરે છે કે નહીં તેની ખાતરી કરો. પછી સળંગ બે લોગિનનું પરીક્ષણ કરો, કારણ કે બીજું લેખન પાથ સાબિત કરે છે અને પહેલું ફક્ત વાંચન.

પોતાના તરીકે નહીં, સેવા તરીકે ચકાસો

દરેક મહત્વપૂર્ણ ચકાસણી યુનિટની સેન્ડબોક્સમાં યુનિટની ઓળખ સાથે ચાલવી જોઈએ.

root તરીકે સફળ થતો આદેશ તમને કહે છે કે ફાઇલ અસ્તિત્વમાં છે અને બીજું કંઈ નહીં. વાસ્તવિક સેવા દ્વારા લોગિન તમને કહે છે કે મોડ્યુલ રહસ્ય વાંચી, વાપરી અને જરૂરી હોય તે પાછું લખી શકે છે કે નહીં.

છેલ્લે, જરૂરિયાત અકબંધ રાખો. શૂન્ય-પાસવર્ડ વિકલ્પ ઉમેરવો, ફક્ત-વાંચન નિષ્ફળતા સ્વીકારવી અથવા સેન્ડબોક્સ દૂર કરવો—બધા નીતિ બદલીને લક્ષણ દૂર કરી દેત. જેને કોડ રજૂ કરવો પડે તે વપરાશકર્તાને રહસ્ય અપ્રાપ્ય હોય ત્યારે પણ નકારવો જોઈએ.