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 ഉള്ളപ്പോൾ ഇൻപുട്ടുകൾ ആദ്യ ഉപയോഗത്തിന് ശേഷം വലിച്ചെറിയുന്നു, അതിനാൽ പിന്നീടുള്ള വീണ്ടും ബന്ധിപ്പിക്കലിന് ഇപ്പോഴും വായിക്കാവുന്ന ഉറവിടം വേണം. ഡെസ്ക്ടോപ്പ് ലോഗിനിൽ തുറക്കുന്ന കീറിംഗ് ആരും ലോഗിൻ ചെയ്യുന്നതിന് മുമ്പ് തുടങ്ങിയ സേവനത്തിന് ലഭ്യമല്ല, കൈ പരീക്ഷണം വിജയിച്ച് റീബൂട്ട് പരാജയപ്പെടുന്നതിന്റെ സാധാരണ കാരണം അതാണ്. ആദ്യ തുടക്കം വിജയിച്ച് പിന്നീടുള്ള വീണ്ടും ബന്ധിപ്പിക്കൽ പരാജയപ്പെട്ടാൽ, അനുമതികൾ വീണ്ടും മാറ്റുന്നതിന് മുമ്പ് വീണ്ടും ബന്ധിപ്പിക്കൽ സംഭവത്തിനായി ജേണൽ വായിക്കുക.
കീയുടെ അരികിൽ പാസ്‌ഫ്രേസ് സൂക്ഷിക്കുന്നത് എൻക്രിപ്ഷൻ നൽകുന്നത് കുറയ്ക്കുന്നു, അതിനാൽ ആ ഫയലും അതിന്റെ ബാക്കപ്പുകളും പരിമിതപ്പെടുത്തുക. കീയുടെ പാസ്‌ഫ്രേസ് നീക്കം ചെയ്യുന്നതിനെ കാണാത്ത ഇൻപുട്ടിന്റെ പരിഹാരമായല്ല, പ്രത്യേക ക്രെഡൻഷ്യൽ തീരുമാനമായി കാണുക. മനുഷ്യ അനുമതിയെയോ ഇന്ററാക്ടീവ് MFA യെയോ ആശ്രയിക്കുന്ന വിന്യാസത്തിന് അതിന്റെ പിന്തുണയുള്ള ഏജന്റോ മാനേജ്മെന്റ് സംയോജനമോ വേണം; സ്ഥിരമായി സൂക്ഷിക്കുന്ന ഒറ്റത്തവണ കോഡ് തുല്യമായ പകരമല്ല.