SSH ProxyCommand ഉം ഹോസ്റ്റ് അടിസ്ഥാനമാക്കിയ പ്രമാണീകരണവും: ഏത് ഹോസ്റ്റാണ് ഒപ്പിടുന്നത്?

പ്രമാണീകരണം നടത്തുന്ന SSH ക്ലയന്റ് ഇപ്പോഴും വർക്ക്സ്റ്റേഷനിൽ പ്രവർത്തിക്കുമ്പോൾ ലക്ഷ്യത്തിന് ബാസ്റ്റ്യനിൽ നിന്ന് വരുന്ന TCP കണക്ഷൻ കാണാം.

Host behind-bastion
    ProxyCommand ssh -W %h:%p bastion

ഇവിടെ സഹായി ബാസ്റ്റ്യനിൽ ലോഗിൻ ചെയ്ത് അതിന്റെ SSH സർവറിനോട് ലക്ഷ്യത്തിലേക്ക് കൈമാറ്റം ചെയ്ത കണക്ഷൻ ആവശ്യപ്പെടുന്നു. വർക്ക്സ്റ്റേഷന്റെ പുറം SSH ക്ലയന്റ് ആ സ്ട്രീമിലൂടെ ലക്ഷ്യത്തിന്റെ SSH പ്രോട്ടോക്കോൾ കൈമാറുന്നു. ബാസ്റ്റ്യൻ ഗതാഗതം നൽകുന്നു; അത് ലക്ഷ്യത്തിലേക്കുള്ള SSH ക്ലയന്റ് ആരംഭിച്ചിട്ടില്ല.

ഹോസ്റ്റ് അടിസ്ഥാനമാക്കിയ പ്രമാണീകരണത്തിന് ഈ വ്യത്യാസം പ്രധാനമാണ്. OpenSSH-ന്റെ ssh-keysign സഹായി ആവശ്യമായ ഒപ്പ് സൃഷ്ടിക്കാൻ പ്രാദേശിക ഹോസ്റ്റ് കീകൾ ഉപയോഗിക്കുന്നു. ബാസ്റ്റ്യന്റെ നെറ്റ്വർക്ക് ഉറവിട വിലാസം ആയിരിക്കുന്നത് വർക്ക്സ്റ്റേഷനെ ബാസ്റ്റ്യന്റെ ഹോസ്റ്റ് കീ ഉപയോഗിച്ച് ഒപ്പിടാൻ നിർബന്ധിക്കുന്നില്ല.

ഇതുമായി താരതമ്യം ചെയ്യുക:

ssh -t bastion ssh target

ഇത് ബാസ്റ്റ്യനിൽ മറ്റൊരു SSH പ്രോഗ്രാം ആരംഭിക്കുന്നു. അതിന്റെ പ്രാദേശിക കോൺഫിഗറേഷനും ലഭ്യമായ ഹോസ്റ്റ് കീകളും ആ യന്ത്രത്തിന്റേതാണ്, അതിനാൽ ബാസ്റ്റ്യനിൽ നിന്ന് ലക്ഷ്യത്തിലേക്ക് മുൻകൂട്ടി ക്രമീകരിച്ച ഹോസ്റ്റ് അടിസ്ഥാനമാക്കിയ വിശ്വാസ ക്രമീകരണത്തിൽ ഇതിന് പങ്കെടുക്കാം. ലക്ഷ്യത്തിന്റെ അനുയോജ്യമായ അനുമതിയും പേര് പരിശോധനയും ഇപ്പോഴും ആവശ്യമാണ്.

രണ്ടാമത്തെ രൂപം സെഷന്റെ പ്രവർത്തനരീതിയും മാറ്റുന്നു: ഇത് ഒരു ദൂര കമാൻഡ് പ്രവർത്തിപ്പിക്കുകയും ടെർമിനൽ ഉപയോഗിക്കുകയും ചെയ്യുന്നു. എല്ലാ SSH ഫയൽ കൈമാറ്റത്തിനും ഓട്ടോമേഷൻ ഗതാഗതത്തിനും ഇത് സുതാര്യമായ പകരമല്ല. ഉറവിട വിലാസം മതിയെന്ന് തോന്നിക്കാൻ സർവറിന്റെ വിശ്വാസ പരിശോധനകൾ ദുർബലമാക്കുന്നതിനുപകരം, ഏത് യന്ത്രം ലക്ഷ്യത്തോട് പ്രമാണീകരിക്കണം എന്നതിന് അനുസരിച്ച് ക്രമീകരണം തിരഞ്ഞെടുക്കുക.