محتوای آموزشی وبلاگ نت‌آرام
قبلاً با دستور
scp فایل را به سرور مجازی ایران می‌فرستادید، اما پس از به‌روزرسانی برنامه، انتقال با پیام subsystem request failed on channel 0 یا خطای مشابه متوقف می‌شود. در عین حال ممکن است ورود SSH معمولی هنوز کار کند. این دو نتیجه با هم تناقض ندارند: اتصال و ورود موفق فقط ثابت می‌کند به حساب رسیده‌اید، نه اینکه روش انتقال فایل روی سرور آماده است.از OpenSSH نسخه ۹٫۰، برنامه
scp به‌طور پیش‌فرض برای انتقال از پروتکل SFTP استفاده می‌کند. اگر مقصد SFTP نداشته باشد، مسیر برنامه آن اشتباه باشد یا تنظیم حساب مانع اجرای subsystem شود، انتقال می‌تواند شکست بخورد. خطاهای کلید میزبان، رمز، مسیر مقصد و مجوز فایل علت‌های دیگری‌اند و با همین تغییر برطرف نمی‌شوند. در این راهنما قدم‌به‌قدم نوع خطا را جدا می‌کنیم.۱. نسخه و محل اجرای دستور را مشخص کنید
دستورهای این بخش را روی رایانه‌ای که انتقال را از آن شروع می‌کنید اجرا کنید؛ در ویندوز می‌توانید PowerShell و در لینوکس یا macOS ترمینال را باز کنید:
کد / دستورssh -V
scp -v ./sample.txt deploy@example.com:/home/deploy/
در فرمان دوم به جای نام کاربری، میزبان، مسیر و نام فایل، مقدارهای واقعی خودتان را قرار دهید. فایل نمونه‌ای کوچک و غیرمحرمانه انتخاب کنید و دقت کنید روی مقصد فایلی با همان نام وجود نداشته باشد؛
scp می‌تواند فایل مقصد هم‌نام را بازنویسی کند. خروجی -v جزئیات مراحل را نشان می‌دهد و ممکن است نام داخلی سرور و حساب شما را داشته باشد؛ پیش از ارسال برای دیگران اطلاعات حساس را حذف کنید.اگر خطا پیش از احراز هویت و مربوط به fingerprint یا الگوریتم کلید است، ابتدا آن مشکل را طبق راهنمای خطای کلید میزبان SSH رفع کنید. اگر پیام
Permission denied برای ورود می‌بینید، کلید، نام کاربر و روش ورود را بررسی کنید. اگر ورود موفق و سپس درخواست SFTP رد می‌شود، مراحل بعدی مناسب‌ترند. نسخه کلاینت مهم است؛ نسخه سرور یا دستور دیگری با نام مشابه لزوماً همان رفتار را ندارد.۲. SFTP را جداگانه آزمایش کنید
روی همان رایانه اجرا کنید:
کد / دستورsftp -v deploy@example.com
اگر به اعلان
sftp> رسیدید، دستور pwd مسیر فعلی را نشان می‌دهد و با exit خارج می‌شوید. موفقیت اتصال اولیه ثابت نمی‌کند پوشه مقصد قابل نوشتن است؛ در صورت نیاز با یک فایل آزمایشی غیرمهم و نام جدید، انتقال را در مسیر مجاز امتحان کنید. اگر پیام خطای subsystem بعد از ورود دیده می‌شود، زمان، نام حساب و متن خطا را یادداشت کنید. در اتصال به سرور دارای پورت غیرپیش‌فرض، برای scp از -P بزرگ و برای sftp نیز از -P بزرگ استفاده می‌شود؛ پورت صحیح را از مدیر سرویس بگیرید.اگر SFTP وارد می‌شود ولی
No such file یا Permission denied در مقصد دارید، مسیر داخل محیط SFTP و مجوز همان پوشه را بررسی کنید. برای حساب محصورشده در chroot، مسیری که کاربر می‌بیند لزوماً با مسیر کامل سیستم‌عامل یکی نیست؛ راهنمای مالکیت پوشه SFTP این حالت را توضیح می‌دهد. فعال‌کردن پروتکل قدیمی، مشکل نام فایل یا مجوز نادرست را درمان نمی‌کند.۳. اگر مقصد OpenSSH لینوکسی در اختیار شماست
از یک نشست SSH یا کنسول مدیریتی جداگانه به مقصد وارد شوید و نشست فعلی را تا تأیید اتصال جدید باز نگه دارید. ابتدا تنظیم‌های فعال و لاگ را بخوانید:
کد / دستورsudo sshd -T | grep -i '^subsystem'
sudo journalctl -u ssh --since '30 minutes ago' --no-pager
sudo journalctl -u sshd --since '30 minutes ago' --no-pager
بسته به توزیع نام سرویس ممکن است
ssh یا sshd باشد؛ نبود لاگ برای یکی به معنی نبود مشکل نیست. برای تنظیم‌های وابسته به Match، روش ارزیابی با sshd -T -C را در راهنمای نسخه خود بررسی و اطلاعات اتصال واقعی را وارد کنید. به خطای نبود فایل sftp-server، رد درخواست یا تنظیم ForceCommand همان حساب توجه کنید. اگر حساب عمداً فقط برای کاری خاص محدود شده است، سیاست دسترسی را با مسئول آن هماهنگ کنید.در فایل اصلی یا فایل‌های include، تعریف subsystem معمولاً شبیه یکی از دو شکل زیر است:
کد / دستورSubsystem sftp internal-sftp
یا مسیر اجرایی مخصوص توزیع به جای
internal-sftp قرار می‌گیرد. مسیرهای نسخه‌های مختلف یکسان نیستند. اگر فایل اجرایی معرفی‌شده وجود ندارد، بسته و مسیر نصب رسمی توزیع را بررسی کنید؛ فایل دلخواه اینترنتی را جایگزین نکنید. وجود چند تعریف ناسازگار ممکن است باعث خطای اعتبارسنجی شود. قبل از ویرایش، نسخه پشتیبان تنظیم را خارج از مسیر include و با مجوز محدود نگه دارید و فقط تعریف مناسب همان محیط را اصلاح کنید.۴. تنظیم SSH را بدون قفل‌کردن دسترسی اعمال کنید
پس از ویرایش، در کنسول یا نشست مدیر اجرا کنید:
کد / دستورsudo sshd -t
sudo systemctl reload ssh
اولی فقط صحت تنظیم را بررسی می‌کند؛ اگر خروجی خطا داد، تا رفع آن reload نکنید. نام سرویس در بعضی توزیع‌ها
sshd است و ممکن است روش reload متفاوت باشد. قبل از بستن نشست قبلی، از اتصال دیگری با همان حساب و همان مسیر شبکه، SSH و SFTP را امتحان کنید. اگر نتیجه بد بود، فایل تغییرکرده را از نسخه سالم برگردانید، sshd -t را دوباره اجرا و تنها پس از موفقیت سرویس مناسب را reload کنید. اگر با Match، chroot یا تنظیم خاص چند حساب سروکار دارید، با حساب‌های تحت تأثیر نیز آزمایش کنید.۵. برای مقصد قدیمی، راه موقت چیست؟
بعضی تجهیزات یا سرورهای قدیمی فقط پروتکل SCP قدیمی دارند و امکان نصب SFTP در آن‌ها در اختیار شما نیست. در کلاینت OpenSSH سازگار، می‌توانید فقط برای همان انتقال آزمونی از حرف O بزرگ استفاده کنید:
کد / دستورscp -O ./sample.txt deploy@example.com:/home/deploy/
این گزینه پروتکل قدیمی را انتخاب می‌کند؛ SFTP را روی سرور فعال نمی‌کند و برای همه خطاها راه‌حل نیست. پروتکل قدیمی برای بعضی مسیرها از shell مقصد استفاده می‌کند و رفتار نقل‌قول و کاراکترهای خاص متفاوت است. مقصد را بشناسید، از نام فایل ساده و غیرمحرمانه برای آزمایش استفاده کنید و این حالت را به تمام میزبان‌ها تعمیم ندهید. در بعضی محیط‌ها مقصد حتی SCP قدیمی را هم نمی‌پذیرد. در صورت امکان، راه پایدارتر به‌روزرسانی مقصد یا فعال‌کردن SFTP با تنظیم درست است. راهنمای رسمی OpenSSH برای scp تفاوت این گزینه را توضیح می‌دهد.
۶. انتقال واقعی را تأیید کنید
پس از رفع خطا، فایل آزمایشی را با نام جدید منتقل کنید و روی هر دو طرف اندازه و در صورت امکان SHA-256 آن را مقایسه کنید. دستور
sha256sum sample.txt در لینوکس و Get-FileHash -Algorithm SHA256 در PowerShell ویندوز برای فایل محلی قابل استفاده‌اند؛ مسیر سمت مقصد را در همان سرور مشخص کنید. موفقیت ورود یا نمایش نوار پیشرفت به‌تنهایی برابر با یکسان‌بودن فایل نیست. اگر انتقال خودکار دارید، همان حساب، کلید و مسیر job را نیز جداگانه آزمایش کنید و بعد فایل آزمایشی مشخص خودتان را حذف کنید.برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام