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 შესვლებს იღებს, მაგრამ ქვესისტემა არ აქვს, ყოველ თანამედროვე გადაცემაზე ვარდება, თუმცა შესვლის ტესტში სრულიად ჯანმრთელად გამოიყურება.

ჩაწერეთ კლიენტის ვერსია, გამოყენებული პროტოკოლი და აბსოლუტური დისტანციური ბილიკი სამუშაოს შენიშვნებში. როცა შემდეგი განახლება ნაგულისხმევს შეცვლის, ეს შენიშვნა სხვაობაა ხუთწუთიან გასწორებასა და ვარაუდებით სავსე შუადღეს შორის.