SSH പ്രോക്സി അക്കൗണ്ടിന് shell ഇല്ലാതെ പ്രവർത്തിക്കാം

പ്രലോഭിപ്പിക്കുന്ന ക്രമീകരണം AllowTcpForwarding no ആണ്. നിർഭാഗ്യവശാൽ, പ്രാദേശിക SSH SOCKS പ്രോക്സിക്ക് ആവശ്യമായ ഫോർവേഡിംഗും അത് അപ്രാപ്തമാക്കുന്നു. ഡൈനാമിക് ഫോർവേഡിംഗ് സർവർ നയത്തെ മറികടക്കാനുള്ള വഴിയല്ല.

സമർപ്പിത അക്കൗണ്ടിന്, OpenSSH നിരവധി കഴിവുകൾ വേർതിരിക്കുന്നു. ഒരു നയ ഭാഗത്തിന് shell, സബ്സിസ്റ്റം സെഷനുകൾ തടയുമ്പോൾ പ്രാദേശിക ഫോർവേഡിംഗ് അനുവദിക്കാം:

Match User proxyuser
    AllowTcpForwarding local
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

സർവർ മാനുവൽ MaxSessions 0-നെ shell, ലോഗിൻ, സബ്സിസ്റ്റം സെഷനുകൾ തടയുകയും ഫോർവേഡിംഗ് അനുവദിക്കുകയും ചെയ്യുന്ന ക്രമീകരണമായി വിവരിക്കുന്നു. ഇത് നിലവിലുള്ള ഒരു പ്രാമാണീകരിച്ച അക്കൗണ്ടിൽ ഉൾപ്പെടുത്തുക; ഇത് പൂർണ്ണമായ SSH സുരക്ഷാ കോൺഫിഗറേഷനല്ല.

ഫോർവേഡിംഗ് മാത്രം SOCKS മാത്രമല്ല

സ്ഥിരമായ പ്രാദേശിക ഫോർവേഡും ഒരു SOCKS അഭ്യർത്ഥനയും ഒടുവിൽ അതേ തരത്തിലുള്ള ലക്ഷ്യ കണക്ഷൻ സർവറിൽ നിന്ന് ആവശ്യപ്പെടാം. പ്രാദേശിക ഫോർവേഡിംഗ് അനുവദിക്കുന്നത് ഒരു ക്ലയന്റ് പ്രത്യേക SOCKS ഇന്റർഫേസ് ഉപയോഗിച്ചു എന്ന് ഉറപ്പാക്കുന്നില്ല. അക്കൗണ്ട് SOCKS-മാത്രം ഉപയോഗം നിർബന്ധിക്കുന്നതായി വിവരിക്കരുത്.

PermitOpen ഒരു പ്രത്യേക പട്ടിക ആവശ്യകതയുമായി യോജിക്കുമ്പോൾ ലക്ഷ്യ ഹോസ്റ്റ്, പോർട്ട് ജോടികൾ പരിമിതപ്പെടുത്താം. എല്ലാ സ്വകാര്യ നെറ്റ്വർക്കുകൾക്കുമുള്ള ഹോസ്റ്റ്നെയിം റെസല്യൂഷൻ അറിയുന്ന പൊതുവായ വിലക്കല്ല ഇത്. വിശാലമായ വിലാസ നിയന്ത്രണങ്ങൾക്ക് ഉചിതമായ ഹോസ്റ്റ് നെറ്റ്വർക്ക് നയം ആവശ്യമായി വന്നേക്കാം.

അക്കൗണ്ട്, കീ, ഉൾപ്പെടുത്തിയ സർവർ ക്രമീകരണങ്ങൾ ഫോർവേഡിംഗ് കൂടുതൽ പരിമിതപ്പെടുത്താം. മറ്റൊരിടത്തുള്ള സമ്പൂർണ ഫോർവേഡിംഗ് വിലക്ക് ഈ ഭാഗം അനുവദിക്കുന്നതായി തോന്നുന്ന കഴിവ് നീക്കം ചെയ്തേക്കാം.

വീണ്ടെടുക്കൽ പാതയോടുകൂടിയ സാധാരണ സർവർ അഡ്മിനിസ്ട്രേഷൻ നടപടിക്രമം ഉപയോഗിക്കുക, തുടർന്ന് അനുവദിച്ചതും നിഷേധിച്ചതുമായ കഴിവുകൾ വെവ്വേറെ വിലയിരുത്തുക. ഉദ്ദേശിക്കുന്ന ഫലം വ്യക്തമായ ഫോർവേഡിംഗ് അനുമതികളാണ്, അബദ്ധവശാൽ തുറന്നിട്ട ഇന്ററാക്ടീവ് ലോഗിൻ അല്ലെങ്കിൽ സ്വന്തം നിയന്ത്രണത്താൽ അപ്രാപ്തമായ പ്രോക്സിയുമല്ല.