SFTP വഴി scp: യഥാർത്ഥത്തിൽ പരിഹരിക്കപ്പെടുന്ന റിമോട്ട് പാതകൾ എഴുതുന്നത്

വർഷങ്ങളായി ഒരു സ്ക്രിപ്റ്റിൽ പ്രവർത്തിച്ച scp കമാൻഡ് ഇപ്പോഴത്തെ ക്ലയന്റിൽ ടണലുമായി യാതൊരു ബന്ധവുമില്ലാത്ത പാത പിശകിനാൽ പരാജയപ്പെടാം. VPN ബൈറ്റുകൾ കൊണ്ടുപോയി; സെർവർ പരിഹരിക്കാനാകാത്ത ഒരു പേര് ക്ലയന്റ് സെർവറിനോട് ആവശ്യപ്പെട്ടു. ഇപ്പോഴത്തെ OpenSSH scp സ്വതവേ SFTP വഴി കൈമാറുന്നു, SFTP പഴയ പ്രോട്ടോക്കോൾ പോലെ ഷെൽ ശൈലിയിലുള്ള വിപുലീകരണം ചെയ്യുന്നില്ല. നിങ്ങളുടെ സ്വന്തം അക്കൗണ്ടിൽ നിന്ന് കമാൻഡ് പുറത്തേക്ക് പിന്തുടരുമ്പോൾ പാത യഥാർത്ഥത്തിൽ എവിടെ വ്യാഖ്യാനിക്കപ്പെടുന്നു എന്ന് കാണാം.

അക്കൗണ്ടിൽ നിന്ന് തുടങ്ങുക, പിന്നെ അതിന് എഴുതാനാകുന്ന ഡയറക്ടറിയിൽ നിന്ന്

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

സെർവറിനോട് അതിന്റെ സ്വന്തം കാഴ്ച ചോദിക്കുക: ssh [email protected] pwd ഒപ്പം ssh [email protected] ls -ld /srv/archive. രണ്ടാമത്തെ കമാൻഡ് അനുമതി നിഷേധിച്ചതായി റിപ്പോർട്ട് ചെയ്താൽ, ടണൽ കുഴപ്പമില്ല, ആ അക്കൗണ്ടിന് പാത ഉപയോഗിക്കാനാവില്ല. കൈമാറ്റം തുടരാൻ അനുമതികൾ വിപുലീകരിക്കുന്നതിന് പകരം ഉടമസ്ഥത ശരിയാക്കുക അല്ലെങ്കിൽ മറ്റൊരു ലക്ഷ്യസ്ഥാനം തിരഞ്ഞെടുക്കുക.

പരിമിതമായ SFTP കോൺഫിഗറേഷന് chroot ഫയൽസിസ്റ്റത്തിന്റെ റൂട്ടായി അവതരിപ്പിക്കാം. ആ കാഴ്ചയ്ക്കുള്ളിൽ ഒരു കേവല പാത chroot-നുള്ളിൽ കേവലമാണ്, അത് അഡ്മിനിസ്ട്രേറ്റർ ഹോസ്റ്റിൽ കാണുന്ന അതേ സ്ഥലമല്ല.

കോളന്റെ രണ്ട് വശങ്ങളും വ്യക്തമായി പേരിടുക

അപ്ലോഡ് പ്രാദേശിക അടിസ്ഥാന പേര് മറുവശത്ത് സ്വീകാര്യമാകുമെന്ന് അനുമാനിക്കുന്നതിന് പകരം റിമോട്ട് ഫയൽ പേര് പറയണം.

scp q3-invoice.csv [email protected]:/home/transfer/drop/q3-invoice.csv

ഡൗൺലോഡ് അതേ കാരണത്താൽ പ്രാദേശിക ലക്ഷ്യസ്ഥാനം പറയണം. രണ്ട് നാമസ്ഥലങ്ങളും സ്വതന്ത്രമാണ്, അവ ഒത്തുപോകുന്നു എന്ന് അനുമാനിക്കുന്ന സ്ക്രിപ്റ്റ് റിമോട്ട് ട്രീ മറ്റൊരു ക്രമീകരണം ഉപയോഗിക്കുന്ന ആദ്യ അവസരത്തിൽ തകരുന്നു.

scp [email protected]:/srv/archive/2026-q3.csv ./2026-q3.csv

പരിപാലിക്കുന്ന സ്ക്രിപ്റ്റിൽ ~otheruser ഒഴിവാക്കുക. മറ്റൊരു അക്കൗണ്ടിന്റെ ഹോം ഡയറക്ടറി വിപുലീകരിക്കുന്നത് റിമോട്ട്-ഷെൽ സവിശേഷതയായിരുന്നു, അതിനെ അനുകരിക്കുന്ന വിപുലീകരണം SFTP സെർവർ നടപ്പാക്കിയെന്ന് വരില്ല. അക്കൗണ്ടിന് യഥാർത്ഥത്തിൽ തുറക്കാനാകുന്ന കേവല പാത എഴുതുക, സ്പെയ്സുള്ള പ്രാദേശിക പാതകൾ സെർവറിലെ ഷെല്ലിനായി എഴുതിയ ഉദ്ധരണ പാളികൾ പകർത്തുന്നതിന് പകരം ഉദ്ധരണികളിൽ ഇടുക.

നിങ്ങളുടെ scp യഥാർത്ഥത്തിൽ ഏത് പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുന്നു എന്ന് അറിയുക

OpenSSH 9.0 മുതൽ ക്ലയന്റ് സ്വതവേ SFTP ഉപയോഗിക്കുന്നു, വിതരണങ്ങൾ ആ പെരുമാറ്റം സ്വന്തം ഷെഡ്യൂളിൽ സ്വീകരിക്കുകയോ പിന്നോട്ട് പോർട്ട് ചെയ്യുകയോ ചെയ്യുന്നു. പതിപ്പ് സ്ട്രിംഗ് ക്ലയന്റിന്റെ ഉദ്ദേശ്യം പറയുന്നു, പക്ഷേ വെണ്ടർ ബിൽഡ് upstream-ൽ നിന്ന് വ്യത്യാസപ്പെടാം, അതിനാൽ നിങ്ങൾ യഥാർത്ഥത്തിൽ പ്രവർത്തിപ്പിക്കുന്ന ക്ലയന്റ് പരിശോധിക്കുക: ssh -V.

രണ്ട് പ്രോട്ടോക്കോളുകളും പേരുകൾ വ്യത്യസ്തമായി പരിഹരിക്കുന്നു. പഴയ SCP റിമോട്ട് ഉപയോക്തൃ ഷെല്ലിനോട് പാത വിപുലീകരിക്കാൻ ആവശ്യപ്പെടുന്നു, അതിനാൽ വൈൽഡ്കാർഡുകളും ടിൽഡെകളും ആ ഷെൽ സ്വന്തം നിയമങ്ങൾ പ്രകാരം കൈകാര്യം ചെയ്യുന്നു. SFTP പകരം ഫയൽ-കൈമാറ്റ പ്രവർത്തനങ്ങൾ പുറപ്പെടുവിക്കുന്നു, അതിനാൽ വൈൽഡ്കാർഡ് ക്ലയന്റ് വിപുലീകരിക്കുന്നു അല്ലെങ്കിൽ വിപുലീകരിക്കുന്നില്ല. രണ്ടും SSH-നുള്ളിൽ ഒരേ യന്ത്രത്തിലേക്ക് പോകുന്നു, അതിനാൽ ഒരു ഹോസ്റ്റ് രണ്ട് ക്ലയന്റുകൾക്ക് കീഴിൽ വ്യത്യസ്തമായി പ്രവർത്തിക്കാം.

scp -v ആവശ്യപ്പെടുന്ന സബ്സിസ്റ്റം പ്രിന്റ് ചെയ്യുന്നു, sftp സബ്സിസ്റ്റം ലൈൻ ആധുനിക പാത ഉപയോഗത്തിലാണെന്ന് സ്ഥിരീകരിക്കുന്നു. scp -O പിന്തുണയുള്ളതും യഥാർത്ഥത്തിൽ ആവശ്യമുള്ളതുമായിടത്ത് പഴയ പ്രോട്ടോക്കോൾ നിർബന്ധിക്കുന്നു, അതിന്റെ സ്വന്തം ഉദ്ധരണ നിയമങ്ങളും കൂടെ തിരികെ കൊണ്ടുവരുന്നു. ഇത് VPN ഓപ്ഷനല്ല, സെർവറിൽ എന്തെങ്കിലും പ്രവർത്തനക്ഷമമാക്കാനുള്ള വഴിയല്ല, ഹോസ്റ്റ്-കീ പരിശോധന അയച്ചുവിടാനുള്ള കാരണവുമല്ല.

സ്ക്രിപ്റ്റ് അതിനെ ആശ്രയിക്കുന്നതിന് മുമ്പ് പാത പരിശോധിക്കുക

പാത പ്രശ്നം ഏറ്റവും മോശം സമയത്ത്, രാത്രിയിൽ ആരും നോക്കാത്ത ഒരു ഓട്ടോമേറ്റഡ് ജോലിയിൽ പ്രത്യക്ഷപ്പെടുന്നു. ആദ്യം ഒരു ചെറിയ ഫയലും ജോലി ഉപയോഗിക്കുന്ന കൃത്യമായ അക്കൗണ്ടും ഉപയോഗിച്ച് ലക്ഷ്യസ്ഥാനം തെളിയിക്കുക, ആ പരിശോധന കമാൻഡ് ജോലിയുടെ നിർവചനത്തിനൊപ്പം സൂക്ഷിക്കുക. പരിശോധനയ്ക്ക് മറ്റൊരു അക്കൗണ്ടോ മറ്റൊരു ഡയറക്ടറിയോ വേണ്ടിവന്നാൽ ജോലിക്കും വേണ്ടിവരും.

സെർവർ വശവും പരിശോധിക്കുക. grep -i subsystem /etc/ssh/sshd_config SFTP സബ്സിസ്റ്റം കോൺഫിഗർ ചെയ്തിട്ടുണ്ടോ എന്ന് കാണിക്കുന്നു, sftp -b /dev/null [email protected] ആ സബ്സിസ്റ്റം ഉത്തരം നൽകുമ്പോൾ മാത്രം വിജയകരമായി പുറത്തുപോകുന്നു. SSH ലോഗിനുകൾ സ്വീകരിക്കുന്നുവെങ്കിലും സബ്സിസ്റ്റം ഇല്ലാത്ത ഹോസ്റ്റ് ലോഗിൻ പരിശോധനയിൽ തികച്ചും ആരോഗ്യകരമായി തോന്നിയാലും എല്ലാ ആധുനിക കൈമാറ്റത്തിലും പരാജയപ്പെടുന്നു.

ക്ലയന്റ് പതിപ്പ്, ഉപയോഗത്തിലുള്ള പ്രോട്ടോക്കോൾ, കേവല റിമോട്ട് പാത എന്നിവ ജോലി കുറിപ്പുകളിൽ രേഖപ്പെടുത്തുക. അടുത്ത അപ്ഗ്രേഡ് ഒരു സ്വതവേയുള്ള മൂല്യം മാറ്റുമ്പോൾ, ആ കുറിപ്പാണ് അഞ്ച് മിനിറ്റത്തെ തിരുത്തും ഊഹങ്ങൾ നിറഞ്ഞ ഒരു ഉച്ചയും തമ്മിലുള്ള വ്യത്യാസം.