scp د SFTP له لارې: هغه لرې لارې لیکل چې واقعاً حل کېږي

د 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 ننوتنې مني خو فرعي سیسټم نه لري، په هر عصري انتقال کې ناکامېږي، په داسې حال کې چې د ننوتنې په ازموینه کې بشپړ روغ ښکاري.

د کلاینټ نسخه، کارول شوی پروتوکول او مطلقه لرې لاره د کار په یادښتونو کې ولیکئ. کله چې بله لوړونه یو ډیفالټ بدل کړي، هغه یادښت د پنځه دقیقو سمون او د اټکلونو ډکې ماسپښین ترمنځ توپیر دی.