OpenVPN સેવા ખાનગી કીનો પાસવર્ડ માંગતી વખતે અટકી જાય છે: કેવી રીતે ઠીક કરવું
સેવા પાસે ટર્મિનલ નથી, તેથી એન્ક્રિપ્ટ થયેલી કીને askpass અને વાંચી શકાય તેવી ફાઇલની જરૂર છે. કીનો પાસફ્રેઝ સર્વર લોગિનથી અલગ કરો અને unit તપાસો.
OpenVPN સ્થાનિક મશીન પર ખાનગી કીનો પાસફ્રેઝ માંગે છે, તેથી કામ કરતી લોગિન ફાઇલ ક્યારેય તેનો જવાબ આપતી નથી. સેવામાં ટાઇપ કરવા માટે ટર્મિનલ હોતું નથી, અને શરૂઆત કાં તો અટકી જાય છે અથવા જર્નલની એવી એન્ટ્રી સાથે નિષ્ફળ જાય છે જે કારણને બદલે ઇનપુટનું નામ લે છે. અહીં બે રહસ્યો સંડોવાયેલા છે, અને unit ફરી શરૂ કરતાં પહેલાં દરેકને પોતાનું વાંચી શકાય તેવું સ્રોત જોઈએ. નીચેનું પગલું તેમને અલગ કરે છે, પછી દરેક ફાઇલ ખરેખર ખોલતી ઓળખ ચકાસે છે.
બે વિનંતીઓને અલગ પાડો
કીનો પાસફ્રેઝ સ્થાનિક ખાનગી કીને ડિક્રિપ્ટ કરે છે; એકાઉન્ટની ક્રેડેન્શિયલ સર્વર સાથે સેશનને પ્રમાણિત કરે છે. તે વિવિધ જગ્યાઓથી આવે છે, વિવિધ ક્ષણે નિષ્ફળ જાય છે અને વિવિધ સંદેશા આપે છે. તેમને ભેગા કરવાથી લોકો પાસવર્ડ રીસેટ શોધવા જાય છે જ્યારે એકાઉન્ટ સંડોવાયેલું જ નહોતું. કોઈપણ વિકલ્પ બદલતાં પહેલાં વિનંતીનું લખાણ વાંચો, કારણ કે કયું રહસ્ય ખૂટે છે તેનો એકમાત્ર વિશ્વસનીય સંકેત શબ્દરચના છે.
Community OpenVPN 2.x માં askpass એવી ફાઇલ દર્શાવે છે જેની પ્રથમ લાઇનમાં કીનો પાસફ્રેઝ હોય છે, અને auth-user-pass એવી ફાઇલ દર્શાવે છે જેની એક લાઇનમાં વપરાશકર્તાનામ અને બીજીમાં પાસવર્ડ હોય છે. બંનેમાંથી કોઈ ફાઇલ બીજા વિકલ્પને સંતોષી શકતી નથી. ડેસ્કટોપ એપ અથવા NetworkManager પ્રોફાઇલ બંનેને પોતાના રહસ્ય-સંગ્રહમાં રાખી શકે છે, જે કમાન્ડ-લાઇન ક્લાયન્ટ ક્યારેય વાંચતું નથી, તેથી કોઈપણ પાથ લખતાં પહેલાં નોંધો કે તમે કયું ક્લાયન્ટ ગોઠવી રહ્યા છો.
બંને વિકલ્પોને વાંચી શકાય તેવી ફાઇલો તરફ દોરો
બંને ઇનપુટની જરૂર હોય તેવી પ્રોફાઇલ આખરે ત્રણ ફાઇલ સંદર્ભો સાથે રહે છે: એન્ક્રિપ્ટ થયેલી કી, તેને ખોલતો પાસફ્રેઝ અને લોગિન જોડી. CA અને ઓળખ-ચકાસણીને અડ્યા વિના તેમને ઉમેરો, કારણ કે તે નક્કી કરે છે કે સર્વર કોણ છે અને આ સમસ્યાનો ભાગ નથી. જો ડિપ્લોયમેન્ટ એકાઉન્ટ ક્રેડેન્શિયલ બિલકુલ વાપરતું ન હોય, તો auth-user-pass ઉમેરવાથી એવું ઇનપુટ બને છે જે કોઈ આપી શકતું નથી.
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authવગર-દલીલવાળા વિકલ્પો પાથવાળા વિકલ્પોથી અલગ વર્તે છે, અને સેવામાં આ ફરક મહત્વનો છે. દલીલ વગરનું askpass હજી પણ કન્સોલ વાંચે છે, અને ફક્ત વપરાશકર્તાનામ ધરાવતી auth-user-pass ફાઇલ હજી પણ પાસવર્ડ વિનંતીને રાહમાં છોડે છે. ક્લાયન્ટ ડેમન બન્યા પછી તે ટર્મિનલ પાસેથી ઇનપુટ માંગી જ શકતું નથી, તેથી આ રીતે ગોઠવાયેલી સેવા શરૂ થતી નથી.
નિરપેક્ષ પાથ કાર્યકારી ડિરેક્ટરીનો પ્રશ્ન દૂર કરે છે પણ પ્રવેશ આપતા નથી. પછી માલિકી, મોડ અને પસાર થવું આવે છે, અને ત્રણેય પ્રોસેસ જે એકાઉન્ટ હેઠળ ચાલે છે તેની સામે ચકાસાય છે.
પ્રોફાઇલ પહેલાં unit નું રૂપરેખાંકન વાંચો
ઇન્સ્ટન્સ કયું રૂપરેખાંકન લોડ કરશે તે unit નક્કી કરે છે, તમે સંપાદિત કરી રહ્યા હતા તે ફાઇલ નહીં. તેની કમાન્ડ લાઇન અને બધા drop-in વાંચો, પછી કાર્યકારી ડિરેક્ટરી સાથે ખરેખર વપરાતી પ્રોફાઇલ સુધી જાઓ. બીજી .ovpn ફાઇલમાં ઉમેરાયેલો પાસફ્રેઝ સંદર્ભ આ ઇન્સ્ટન્સ માટે કંઈ બદલતો નથી.
ત્રણ માત્ર-વાંચન આદેશો તેમાંથી મોટા ભાગનો જવાબ આપે છે. પ્રથમ unit અને બધા drop-in છાપે છે, બીજો પ્રોસેસને બાંધતી ઓળખ અને સેન્ડબોક્સ સેટિંગ્સ છાપે છે, અને ત્રીજો છાપે છે કે છેલ્લી શરૂઆત ખરેખર શાની ફરિયાદ કરતી હતી. હોસ્ટ પર અસ્તિત્વમાં હોય તેવું ઇન્સ્ટન્સ નામ વાપરો:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bProtectHome અને પ્રોફાઇલના પોતાના user, group અને chroot વિકલ્પો પર ધ્યાન આપો. હોમ ડિરેક્ટરી હેઠળની ફાઇલ તમારા શેલમાં વાંચી શકાય તેવી હોઈ શકે અને હોમ ડિરેક્ટરીઓ છુપાયા પછી સેવાની અંદર અદૃશ્ય બની શકે. systemd જે એકાઉન્ટ સાથે શરૂ કરે છે તે હંમેશા અંતે કી ખોલતું એકાઉન્ટ હોતું નથી.
સાબિત કરો કે રનટાઇમ ઓળખ બંને ફાઇલો ખોલી શકે છે
માત્ર મોડ વાંચવો પૂરતો નથી, કારણ કે પાથ પરની દરેક ડિરેક્ટરી સમાન ઓળખ માટે પસાર થવા યોગ્ય હોવી જોઈએ. પાથને ઘટક-ઘટક ચાલો, પછી પ્રોસેસ જે એકાઉન્ટ વાપરે છે તે તરીકે ખોલવાનું પરીક્ષણ કરો. root ની માલિકીની અને મોડ 600 વાળી ફાઇલ ફક્ત ત્યારે જ કામ કરે છે જ્યારે પ્રોસેસ હજી root હોય, જે ઘણી પ્રોફાઇલ કરતી વિશેષાધિકાર ઘટાડા પછી સાચું નથી. બે આદેશો પસાર થવું અને ખોલવું બંને આવરી લે છે:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableપ્રથમ આદેશ દરેક ઘટકનો મોડ છાપે છે અને જ્યાં એકાઉન્ટ પસાર થઈ શકતું નથી ત્યાં નિષ્ફળ જાય છે; બીજો એકમાત્ર મહત્વના પ્રશ્નનો જવાબ આપે છે, એટલે કે રનટાઇમ ઓળખ ફાઇલને વાંચવા માટે ખોલી શકે છે કે નહીં. બંનેમાંથી કોઈ ફાઇલનો સંદર્ભ છાપતું નથી, અને ફાઇલમાં પાસફ્રેઝ હોય ત્યારે આ જ મુખ્ય વાત છે. લોગિન ફાઇલ માટે પણ પરીક્ષણનું પુનરાવર્તન કરો, કારણ કે બંને ઘણી વાર અલગ માલિકી સાથે સંગ્રહાય છે.
જો પ્રોસેસ chroot અથવા મર્યાદિત namespace વાપરે છે, તો એ જ પરીક્ષણ તે દૃશ્યની અંદરથી ચલાવો, નહીં તો જવાબ ખોટી ફાઇલસિસ્ટમનું વર્ણન કરે છે. છુપાયેલી હોમ ડિરેક્ટરી હેઠળ સંગ્રહાયેલો પાસફ્રેઝ એ unit ની બહાર પાસ થઈને અંદર નિષ્ફળ જતા પરીક્ષણનું સામાન્ય ઉદાહરણ છે.
પ્રથમ શરૂઆત તપાસો, પછી ફરી જોડાણ
ઇન્સ્ટન્સ એક વાર શરૂ કરો અને છેલ્લી નહીં, પ્રથમ નિષ્ફળતા વાંચો. ખૂટતી ઇનપુટ ફાઇલ, નિષ્ફળ કી ડિક્રિપ્શન અને સર્વર તરફથી AUTH_FAILED એ ત્રણ અલગ ઘટનાઓ છે, ત્રણ અલગ સુધારા સાથે. પરવાનગીની ચેતવણી સુધારવાથી કી ખૂલી કે નહીં તેનું કંઈ સાબિત થતું નથી.
જર્નલની લાઇન કહે છે કે ત્રણમાંથી કઈ સ્થિતિ તમારી પાસે છે. સુધારો એમાંથી આવે છે કે કયું ઇનપુટ નિષ્ફળ ગયું:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
પછી તમને ખરેખર જરૂરી જીવનચક્ર નું પરીક્ષણ કરો: બૂટ પર શરૂઆત અને કોઈપણ સમર્થિત ફરી જોડાણ, ફક્ત તમારા શેલમાંથી હાથે શરૂ કરવું નહીં. auth-nocache સાથે ઇનપુટ પ્રથમ વપરાશ પછી કાઢી નાખવામાં આવે છે, તેથી પછીના ફરી જોડાણને હજી પણ વાંચી શકાય તેવું સ્રોત જોઈએ. ડેસ્કટોપ લોગિન વખતે ખૂલતી keyring એવી સેવા માટે ઉપલબ્ધ નથી જે કોઈ લોગિન કરે તે પહેલાં શરૂ થઈ હોય, અને હાથે કરેલું પરીક્ષણ પાસ થાય અને રીબૂટ નિષ્ફળ જાય તેનું આ સામાન્ય કારણ છે. જો પ્રથમ શરૂઆત સફળ થાય અને પછીનું ફરી જોડાણ નિષ્ફળ જાય, તો ફરી પરવાનગીઓ બદલતાં પહેલાં ફરી જોડાણની ઘટના માટે જર્નલ વાંચો.
કીની બાજુમાં પાસફ્રેઝ રાખવાથી એન્ક્રિપ્શન તમને જે આપે છે તે ઘટે છે, તેથી તે ફાઇલ અને તેની બેકઅપ પ્રતિબંધિત કરો. કીનો પાસફ્રેઝ દૂર કરવાને ખૂટતા ઇનપુટનો સુધારો નહીં, અલગ ક્રેડેન્શિયલ નિર્ણય ગણો. માનવ મંજૂરી અથવા ઇન્ટરેક્ટિવ MFA પર આધારિત ડિપ્લોયમેન્ટને તેના સમર્થિત agent અથવા મેનેજમેન્ટ એકીકરણની જરૂર છે; કાયમ સંગ્રહાયેલો એકવારનો કોડ સમકક્ષ વિકલ્પ નથી.