સુધારો: OpenVPN પ્રમાણભૂત ઇનપુટમાંથી Auth વપરાશકર્તાનામ વાંચી શક્યું નહીં
OpenVPN ની «could not read Auth username from stdin» ભૂલ સ્થાનિક ઇનપુટ નિષ્ફળતા છે. સેવાને વાંચી શકાય તેવો ઓળખપત્ર સ્રોત આપો; script-security સાથે તેનો સંબંધ નથી.
could not read Auth username from stdin પ્રમાણીકરણની સમસ્યા જેવું લાગે છે અને એવું નથી. OpenVPN એ પ્રમાણભૂત ઇનપુટ પરથી વપરાશકર્તાનામ માંગવાનો પ્રયાસ કર્યો, વાંચી શકાય તેવું કંઈ મળ્યું નહીં અને સર્વરનો સંપર્ક કરવા પહેલાં જ અટકી ગયું. ખાતું સંપૂર્ણપણે માન્ય હોઈ શકે છે; પ્રક્રિયા પાસે પૂછવા માટે કોઈ નથી.
તેથી પ્રથમ ઉપયોગી પગલું એ નક્કી કરવું છે કે ક્લાયન્ટ શું વાંચી રહ્યો છે, કનેક્શન ફરી પ્રયત્ન કરવો કે સર્વર-બાજુની સેટિંગ્સ બદલવી નહીં. નીચેની ચકાસણીઓ ક્રમમાં કરો અને પ્રથમ નિષ્ફળ થતી હોય ત્યાં અટકો.
ભૂલને સ્થાનિક ઇનપુટ નિષ્ફળતા તરીકે વાંચો
જ્યારે auth-user-pass ફાઇલ આર્ગ્યુમેન્ટ વિના દેખાય, ત્યારે ક્લાયન્ટ પૂછવાની અપેક્ષા રાખે છે. ઇન્ટરેક્ટિવ શેલમાં તે પ્રોમ્પ્ટ કામ કરે છે કારણ કે પ્રક્રિયા પાસે ટર્મિનલ હોય છે. systemd, cron કાર્ય કે કન્ટેનર હેઠળ પ્રમાણભૂત ઇનપુટ સામાન્ય રીતે ખાલી હોય છે, અને વાંચન તરત જ તમે જોઈ રહ્યા છો તે ભૂલ સાથે પાછું આવે છે.
સંદેશો નિષ્ફળ થયેલું ક્ષેત્ર પણ જણાવે છે, વપરાશકર્તાનામ કે પાસવર્ડ, જે દર્શાવે છે કે વાંચન કેટલું આગળ ગયું. વપરાશકર્તાનામ ગેરહાજર હોવાનો અર્થ છે કે પ્રક્રિયા બિલકુલ કંઈ વાંચી શકી નહીં. સફળ વપરાશકર્તાનામ પછી પાસવર્ડ ગેરહાજર હોવાનો અર્થ છે કે બે વાંચનો વચ્ચે ઇનપુટ પ્રવાહ પૂરો થયો, જે અડધું લખાયેલી ફાઇલ કે બંધ પાઇપ માટે સામાન્ય છે.
બીજું કંઈ બદલતા પહેલાં ક્લાયન્ટનું પોતાનું દૃશ્ય ચકાસો. તેને સમાન રૂપરેખાંકન અને સમાન વપરાશકર્તા સાથે ફોરગ્રાઉન્ડમાં ચલાવો, અને પ્રોમ્પ્ટ આવે છે કે નહીં તે જુઓ. જો તે તમારા શેલમાં આવે પણ સેવા મેનેજર હેઠળ ન આવે, તો ભેદ ઇનપુટ સ્રોતમાં છે, ઓળખપત્રોમાં નહીં. unit ફાઇલ અને તમારા શેલ વાતાવરણની ઝડપી સરખામણી સામાન્ય રીતે બતાવે છે કે કયું ટર્મિનલ આપે છે.
સેવાને સમર્થિત ઓળખપત્ર સ્રોત આપો
દેખરેખ વિના ચલાવવા માટેનો સમર્થિત સ્રોત એ ઓળખપત્ર ફાઇલ છે જે આર્ગ્યુમેન્ટ તરીકે આપવામાં આવે છે auth-user-pass ને. ફાઇલ સાદા લખાણ તરીકે વંચાય છે: પ્રથમ લીટી વપરાશકર્તાનામ, બીજી પાસવર્ડ. તેને સંપૂર્ણ પથ જેવા કે /etc/openvpn/client/creds થી દર્શાવો, જેથી સેવા ખાતાની કાર્યકારી ડિરેક્ટરી નિર્દેશનો અર્થ બદલી ન શકે.
પરવાનગીઓ પથ જેટલી જ મહત્વની છે. ફાઇલ ક્લાયન્ટ ચલાવતા ખાતા માટે વાંચી શકાય તેવી હોવી જોઈએ અને બીજા બધા માટે નહીં, અને તે સેવા ખાતાની કે root ની માલિકીની હોવી જોઈએ એવા જૂથ સાથે જેમાં સેવાનો સમાવેશ થાય. સામગ્રી છાપ્યા વિના તે ખાતા તરીકે વાંચનક્ષમતા ચકાસો.
સાપેક્ષ પથ એ શાંત નિષ્ફળતાનો પ્રકાર છે. પ્રોફાઇલ એક ડિરેક્ટરીમાં હોઈ શકે જ્યારે systemd પ્રક્રિયા બીજે શરૂ કરે, તેથી તમારા શેલમાં ઉકેલાતી ફાઇલ સેવા માટે ઉકેલાતી નથી. ઓળખપત્રોને નિશ્ચિત સ્થળે ખસેડો અને તેમને સંપૂર્ણ રીતે સંદર્ભિત કરો. પછી સેવા એક વાર શરૂ કરો અને ખાતરી કરો કે એ જ પથ વપરાય છે, પ્રોફાઇલ એડિટરના દૃશ્ય પર ભરોસો કરવાને બદલે.
જો ડિપ્લોયમેન્ટને એકવારના કોડ કે બીજા ઇન્ટરેક્ટિવ પડકારની જરૂર હોય, તો નક્કી કરો કે ક્લાયન્ટનો કાર્યપ્રવાહ ખરેખર તેને દેખરેખ વિના સમર્થન આપે છે કે નહીં. સ્થિર પાસવર્ડવાળી ફાઇલ ફરતા કોડનો જવાબ આપી શકતી નથી, અને જવાબ ન આપી શકાય તેવી પ્રોમ્પ્ટ ફરી પ્રયત્ન કરવાથી કોઈ માહિતી ઉમેરાતી નથી.
script-security કેમ મદદ નહીં કરે
script-security નિયંત્રિત કરે છે કે ક્લાયન્ટ સ્ક્રિપ્ટ ચલાવી શકે છે કે નહીં અને તેમને કેટલું આપી શકે છે, જેમાં એ પણ સામેલ છે કે પર્યાવરણ ચલ દ્વારા સ્ક્રિપ્ટને પાસવર્ડ આપી શકાય છે કે નહીં. વપરાશકર્તાનામ અને પાસવર્ડ મૂળ ક્યાંથી આવે છે તે વિશે તે કંઈ કહેતું નથી.
તેને ઊંચા સ્તરે લઈ જવું સામાન્ય પ્રતિક્રિયા છે કારણ કે સંદેશમાં Auth નો ઉલ્લેખ છે, પરંતુ તે ઇનપુટ સ્રોતને બદલે સ્ક્રિપ્ટ પરવાનગીઓ બદલે છે, અને ક્લાયન્ટ શું ચલાવી શકે તે વિસ્તારે છે. જો સહાયક સ્ક્રિપ્ટ ડિઝાઇનનો ભાગ હોય, તો પહેલા ઇનપુટ સ્રોત સુધારો અને સુરક્ષા સ્તરને ડિપ્લોયમેન્ટને જરૂરી સૌથી નીચા મૂલ્ય પર રાખો.
મેનેજમેન્ટ ઇન્ટરફેસ કાયદેસર વિકલ્પ છે. ફ્રન્ટએન્ડ તેની સાથે જોડાઈ શકે, ઓળખપત્ર વિનંતી મેળવી શકે અને વપરાશકર્તાનામ અને પાસવર્ડ સાથે જવાબ આપી શકે; કેટલાક GUI આ રીતે કામ કરે છે. જો તમે તેનો ઉપયોગ કરો, તો તેને સ્થાનિક સરનામાં સાથે બાંધો, મેનેજમેન્ટ પાસવર્ડ ફાઇલથી સુરક્ષિત કરો અને કોણ જોડાઈ શકે તે મર્યાદિત કરો, કારણ કે તે ક્લાયન્ટ માટે નિયંત્રણ ચેનલ છે.
ક્લાયન્ટ ફાઇલ વાંચ્યા પછી આગલા તબક્કાની ચકાસણી કરો
એકવાર ક્લાયન્ટ ઓળખપત્રો વાંચી શકે, પછીની નિષ્ફળતા સર્વર સાથેની ખરી આપલે છે, અને તેના સંદેશનો અર્થ અલગ છે. તે તબક્કે પ્રમાણીકરણ નિષ્ફળતાનો અર્થ છે કે સર્વરે ખાતું નકાર્યું; પડકાર પ્રતિસાદનો અર્થ છે કે સર્વરને બીજું પરિબળ જોઈએ છે. તેમને એ જ સમસ્યાની પુનરાવૃત્તિ નહીં, નવી સમસ્યાઓ તરીકે ગણો.
સેવા જે રીતે ચલાવશે તે રીતે આખો પથ ચકાસો: એ જ ખાતું, એ જ કાર્યકારી ડિરેક્ટરી, એ જ unit વાતાવરણ. જે કનેક્શન ફક્ત તમારા શેલમાંથી શરૂ કરવાથી કામ કરે તે સંકેત છે કે પર્યાવરણ ચલ કે ટર્મિનલ હજી પ્રવાહનો ભાગ છે.
પછી રહસ્યોને જ્યાં હોવા જોઈએ ત્યાં જ રાખો. કમાન્ડ-લાઇન આર્ગ્યુમેન્ટમાંના પાસવર્ડ પ્રક્રિયા કોષ્ટકમાં દેખાય છે, અને ડિબગ આઉટપુટમાંના પાસવર્ડ ટિકિટમાં પહોંચે છે. સુરક્ષિત ફાઇલ કે મેનેજમેન્ટ ઇન્ટરફેસ વાપરો, લોગ એવા સ્તરે રાખો જે ઓળખપત્રોનું પુનરાવર્તન ન કરે, અને જેને પ્રવેશ હોય તે નીકળે ત્યારે ફાઇલ બદલો.
ચેકલિસ્ટ: સંપૂર્ણ ઓળખપત્ર પથ, સેવા ખાતા તરીકે વાંચનક્ષમ, ટર્મિનલની જરૂર નહીં, script-security તેના ન્યૂનતમ પર, મેનેજમેન્ટ ઇન્ટરફેસ ફક્ત જો બંધાયેલ અને પ્રમાણિત હોય, અને પરિણામી સર્વર પ્રતિસાદને અલગ ઘટના તરીકે ગણવો.