वर्षानुवर्षे स्क्रिप्टमध्ये चालणारा 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 लॉगिन स्वीकारणारा पण उपप्रणाली नसलेला होस्ट लॉगिन चाचणीत पूर्णपणे निरोगी दिसला तरी प्रत्येक आधुनिक हस्तांतरणात अयशस्वी होतो.

क्लायंट आवृत्ती, वापरातील प्रोटोकॉल आणि पूर्ण रिमोट पाथ कामाच्या नोंदींमध्ये नोंदवा. पुढील अपग्रेडने डीफॉल्ट बदलल्यावर, ती नोंद पाच मिनिटांची दुरुस्ती आणि अंदाजांनी भरलेली दुपार यातील फरक आहे.

संबंधित लेख