SSH ഏജന്റ് ഫോർവേഡിംഗും കീ പകർത്തലും: യഥാർത്ഥത്തിൽ എന്താണ് ചോർന്നുപോകുന്നത്
പൊതു കീ ലോഗിൻ ഒരു ഒപ്പ് അയയ്ക്കുന്നു, സ്വകാര്യ കീയല്ല. ഏജന്റ് ഫോർവേഡിംഗ് എന്നിട്ടും മറ്റൊരു ഹോസ്റ്റിന് ഒപ്പിടാനുള്ള കഴിവ് നൽകുന്നു, അത് വേറിട്ട ഒരു വെളിപ്പെടുത്തലാണ്.
രണ്ട് വ്യത്യസ്ത സംഭവങ്ങളെ ചോർന്ന SSH കീ എന്ന് വിളിക്കുന്നു, അവയ്ക്ക് വ്യത്യസ്ത പ്രതികരണങ്ങൾ വേണം. പൊതു കീ പ്രാമാണീകരണം ഒരു പൊതു കീയും സ്വകാര്യ കീ ഉപയോഗിച്ച് ഉണ്ടാക്കിയ ഒപ്പും അയയ്ക്കുന്നു, അതിനാൽ സ്വകാര്യ കീ ഒരിക്കലും അഭ്യർത്ഥനയിലെ ഒരു ഫീൽഡല്ല. ഏജന്റ് ഫോർവേഡിംഗ് മറ്റൊന്ന് വെളിപ്പെടുത്തുന്നു, കാരണം നിങ്ങളുടെ ഫോർവേഡ് ചെയ്ത ഏജന്റിൽ എത്താവുന്ന ഒരു ദൂര ഹോസ്റ്റിന് കീ ഒരിക്കലും കൈവശം വയ്ക്കാതെ അതിനോട് ഒപ്പിടാൻ ആവശ്യപ്പെടാം. ഇവ രണ്ടിനെയും ഒരു സംഭവമായി കണ്ടാൽ, ഫലം നിരർത്ഥകമായ കീ മാറ്റമോ അല്ലെങ്കിൽ പ്രവർത്തിച്ചുകൊണ്ടിരിക്കുന്ന ഒരു പ്രതിനിധാനമോ ആണ്.
പൊതു കീ ലോഗിൻ കീയല്ല, ഒപ്പാണ് കൈമാറുന്നത്
പ്രാമാണീകരണ കൈമാറ്റം ഉപയോക്താവിന്റെ പൊതു കീയും സെഷൻ ഡാറ്റയിലുള്ള ഒരു ഒപ്പും വഹിക്കുന്നു. സർവർ ആ ഒപ്പ് താൻ ഇതിനകം വിശ്വസിക്കുന്ന കീ ഉപയോഗിച്ച് പരിശോധിക്കുന്നു, അതിനാൽ വിശ്വാസയോഗ്യമല്ലാത്ത നെറ്റ്വർക്കിലൂടെയും സ്വകാര്യ പകുതിക്ക് ക്ലയന്റിൽ തുടരാം. ടണൽ നിരീക്ഷിക്കുന്ന VPN ഓപ്പറേറ്റർ ഏതു സാഹചര്യത്തിലും എൻക്രിപ്റ്റ് ചെയ്ത SSH സെഷൻ കാണുന്നു.
അത് പ്രോട്ടോക്കോളിനെ വിവരിക്കുന്നു, പാതയിലെ ഓരോ അറ്റത്തിന്റെയും വിശ്വാസ്യതയെയല്ല. ഹോസ്റ്റ് ഐഡന്റിറ്റി പരിശോധന അതേപടി നിലനിർത്തുക, കാരണം ഏതെങ്കിലും ഹോസ്റ്റ് കീ സ്വീകരിക്കുന്ന ക്ലയന്റ് ഇവിടെ ചർച്ച ചെയ്യുന്നതിൽ നിന്ന് വ്യത്യസ്തമായ ഒരു നിയന്ത്രണം ഉപേക്ഷിച്ചിരിക്കുന്നു. പിടിച്ചെടുത്ത സെഷനും പിടിച്ചെടുത്ത കീയും വേറിട്ട കണ്ടെത്തലുകളാണ്, അവയിൽ ഒന്ന് മാത്രമാണ് ക്രെഡൻഷ്യലുകളുടെ നഷ്ടം. റിപ്പോർട്ടിൽ രണ്ടും വേറിട്ട വാക്യങ്ങളിൽ സൂക്ഷിക്കുക.
ssh-keygen -lf ~/.ssh/id_ed25519.pub ssh -o StrictHostKeyChecking=yes [email protected]
ആദ്യ കമാൻഡ് പൊതു വിരലടയാളം അച്ചടിക്കുന്നു, അതിനാൽ സർവർ പട്ടികപ്പെടുത്തുന്നതുമായി താരതമ്യം ചെയ്യാം. രണ്ടാമത്തേത് ആരും വായിച്ചിട്ടില്ലാത്ത ഡിഫോൾട്ടിനെ ആശ്രയിക്കുന്നതിനുപകരം ഹോസ്റ്റ് കീ പരിശോധന വ്യക്തമാക്കുന്നു. കീകളിൽ എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് രണ്ടും പ്രവർത്തിപ്പിക്കുക, അടിസ്ഥാനരേഖ രേഖപ്പെടുത്തപ്പെടട്ടെ.
ഏജന്റ് ഫോർവേഡിംഗ് ഒപ്പിടാനുള്ള കഴിവ് പ്രതിനിധാനം ചെയ്യുന്നു
ഫോർവേഡിംഗ് പ്രവർത്തനക്ഷമമാക്കിയാൽ ദൂര ഹോസ്റ്റിൽ ഒരു സോക്കറ്റ് പ്രത്യക്ഷപ്പെടുന്നു, പ്രാദേശിക ഏജന്റ് അതിലൂടെ വരുന്ന അഭ്യർത്ഥനകൾക്ക് ഉത്തരം നൽകുന്നു. സെഷൻ സമയത്ത് ആ സോക്കറ്റ് ഉപയോഗിക്കാവുന്ന ആർക്കും ലോഡ് ചെയ്ത ഐഡന്റിറ്റികൾ സ്വീകരിക്കുന്ന ഹോസ്റ്റുകളിൽ നിങ്ങളായി പ്രാമാണീകരിക്കാം. അത് പ്രവർത്തിക്കാൻ ഒരു സ്വകാര്യ കീയും നെറ്റ്വർക്ക് കടക്കുന്നില്ല.
വെളിപ്പെടുത്തൽ കഴിവാണ്, ഫയലല്ല. അതിനാൽ ഫോർവേഡിംഗ് ലാപ്ടോപ്പ് ഉണ്ടാക്കുന്ന ഓരോ കണക്ഷനുമല്ല, പേരിട്ട ഒരു ജോലിക്കും പേരിട്ട ഒരു ഹോസ്റ്റിനുമാണ്. ഫോർവേഡ് ചെയ്ത ഏജന്റ് ഇല്ലാതെ കണക്ഷൻ കൈമാറുന്ന ജമ്പ് ഹോസ്റ്റ് സാധാരണയായി ആവശ്യം പൂർണ്ണമായി ഒഴിവാക്കുന്നു.
ssh-add -l ssh -o ForwardAgent=no [email protected] ssh -J [email protected] [email protected]
ആദ്യത്തേത് ഏജന്റ് ഇപ്പോൾ കൈവശം വയ്ക്കുന്ന ഐഡന്റിറ്റികൾ പട്ടികപ്പെടുത്തുന്നു, അത് മറ്റൊരു യന്ത്രത്തിന് സോക്കറ്റ് നൽകുന്നതിന് മുൻപ് അറിയേണ്ടതാണ്. രണ്ടാമത്തേത് പ്രതിനിധാനം ഇല്ലാതെ ബന്ധിപ്പിക്കുന്നു. മൂന്നാമത്തേത് ഫോർവേഡിംഗിനെ പലപ്പോഴും പൂർണ്ണമായി മാറ്റിസ്ഥാപിക്കുന്ന ജമ്പ് ഹോസ്റ്റ് മാതൃക കാണിക്കുന്നു.
നിങ്ങളുടെ കൈവശമുള്ള തെളിവിൽ നിന്ന് പ്രതികരണം തിരഞ്ഞെടുക്കുക
വെളിപ്പെട്ടതായി കരുതുന്ന ഒപ്പിടുന്ന ഐഡന്റിറ്റിക്ക് മാറ്റിസ്ഥാപനത്തിന്റെയും റദ്ദാക്കലിന്റെയും നടപടിക്രമം വേണം, അതിനെ വിശ്വസിച്ച സേവനങ്ങളിൽ നിന്ന് അതിന്റെ സ്വീകാര്യത നീക്കണം. ലാപ്ടോപ്പിലെ പകർപ്പ് മായ്ച്ചാൽ മറ്റെല്ലാ പകർപ്പുകളും തൊടാതെ കിടക്കും. സേവനങ്ങളിൽ നിന്ന് തുടങ്ങുക, പിന്നീട് ക്ലയന്റുകൾ വൃത്തിയാക്കുക.
താൽക്കാലിക പ്രതിനിധാന പ്രശ്നം കൂടുതൽ ഇടുങ്ങിയതാണ്. ആവശ്യമില്ലാത്ത ഫോർവേഡിംഗ് അവസാനിപ്പിക്കുക, സംഭവത്തിന്റെ ഉടമയുമായി ഏത് സെഷനുകളെയും ഐഡന്റിറ്റികളെയും അത് ഉൾക്കൊണ്ടിരുന്നു എന്ന് പരിശോധിക്കുക. കീ മാറ്റം പിന്നീട് വന്നേക്കാം, പക്ഷേ അത് തെളിവാണ് തീരുമാനിക്കുന്നത്, ആശങ്കയല്ല.
നിരീക്ഷിക്കപ്പെട്ട ഒരു കയറ്റുമതിയും ഇല്ലാത്തത് നിങ്ങൾ ഭയപ്പെട്ട സംവിധാനം പ്രത്യക്ഷപ്പെട്ടില്ല എന്ന് മാത്രം തെളിയിക്കുന്നു. ആ സോക്കറ്റിന്റെ മറുവശത്തുള്ള ഹോസ്റ്റിന് മറ്റെന്ത് ചെയ്യാമായിരുന്നു എന്നതിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല.
റിപ്പോർട്ടിൽ നിയന്ത്രണങ്ങൾ വേറിട്ട് സൂക്ഷിക്കുക
സ്വകാര്യ വസ്തു സംരക്ഷിക്കുക, അതിൽ നിന്ന് ഒപ്പ് ആവശ്യപ്പെടാവുന്നവരെ പരിമിതപ്പെടുത്തുക, മറുപക്ഷത്തിന്റെ ഐഡന്റിറ്റി പരിശോധിച്ചതായി നിലനിർത്തുക. ഇവ പരസ്പരം ശക്തിപ്പെടുത്തുന്ന മൂന്ന് നിയന്ത്രണങ്ങളാണ്, എന്ത് സംഭവിച്ചു എന്ന് വിശദീകരിക്കുമ്പോൾ ഇവയിലൊന്നും മറ്റൊന്നിന് പകരമാകുന്നില്ല.
വിട്ടുപോയ ലാപ്ടോപ്പോ അതിലെ പ്രത്യേകാവകാശമുള്ള അപ്ലിക്കേഷനോ വളരെ വിശാലമായ സ്വാധീനമുള്ള മൂന്നാമത്തെ കേസാണ്. VPN റൂട്ട് മാറ്റുന്നത് അത് പരിഹരിക്കുന്നില്ല, ഡിസ്കിൽ നിന്ന് വായിച്ചിരിക്കാവുന്ന ഒരു കീയിലുള്ള വിശ്വാസവും തിരികെ വരുന്നില്ല.
ഏത് ഘടകത്തെ വിശ്വസിച്ചു, ഫോർവേഡിംഗ് സജീവമായിരുന്നോ, യഥാർത്ഥത്തിൽ എന്താണ് നിരീക്ഷിച്ചത് എന്ന് എഴുതുക. ആ രേഖയാണ് അടുത്ത തീരുമാനത്തെ ചോർച്ചയുടെ അർത്ഥത്തെക്കുറിച്ചുള്ള ഊഹത്തിന് പകരം സാധൂകരിക്കാവുന്നതാക്കുന്നത്.