പരിഹാരം: 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 അതിന്റെ ഏറ്റവും കുറഞ്ഞ നിലയിൽ, മാനേജ്മെന്റ് ഇന്റർഫേസ് ബന്ധിപ്പിച്ചും പ്രമാണീകരിച്ചും ഉണ്ടെങ്കിൽ മാത്രം, ഫലമായുണ്ടാകുന്ന സർവർ പ്രതികരണം പ്രത്യേക സംഭവമായി കണക്കാക്കുക.