ProtectHome vs 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 గా విజయవంతమయ్యే ఆదేశం ఫైల్ ఉందని మాత్రమే చెబుతుంది. నిజమైన సేవ ద్వారా లాగిన్ మాడ్యూల్ రహస్యాన్ని చదవగలదా, ఉపయోగించగలదా, అవసరమైనది తిరిగి రాయగలదా అని చెబుతుంది.

చివరగా, అవసరాన్ని చెక్కుచెదరకుండా ఉంచండి. శూన్య-పాస్వర్డ్ ఎంపికను జోడించడం, చదవడం-మాత్రమే వైఫల్యాలను అంగీకరించడం లేదా శాండ్బాక్స్ను తీసివేయడం — ఇవన్నీ విధానాన్ని మార్చి లక్షణాన్ని మాయం చేస్తాయి. కోడ్ను సమర్పించాల్సిన వినియోగదారు రహస్యం అందుబాటులో లేనప్పుడు కూడా తిరస్కరించబడాలి.