محتوای آموزشی وبلاگ نت‌آرام
کاربر SFTP نام کاربری و رمز یا کلید درست را می‌دهد، اما اتصال بلافاصله قطع می‌شود. در گزارش سرور عبارتی مانند
bad ownership or modes for chroot directory می‌بینید. معنی آن این است که یکی از پوشه‌های مسیر chroot مالک یا مجوزی دارد که OpenSSH برای امن بودن آن نمی‌پذیرد.پوشه chroot مثل محدوده‌ای است که کاربر پس از ورود داخل آن قرار می‌گیرد. OpenSSH انتظار دارد همه اجزای مسیر تا ریشه این محدوده متعلق به root باشند و گروه و دیگران اجازه نوشتن روی آن‌ها نداشته باشند. اما کاربر برای آپلود می‌تواند یک زیرپوشه جداگانه و قابل نوشتن داخل همین محدوده داشته باشد. در این راهنما ابتدا مسیر واقعی را پیدا می‌کنیم و سپس فقط پوشه‌های لازم را اصلاح می‌کنیم.
پیش از شروع، یک نشست مدیریتی SSH را باز نگه دارید و مطمئن شوید کنسول ارائه‌دهنده در دسترس است. به کاربر دارای sudo نیاز دارید.
sftpuser، آدرس سرور و مسیر /srv/sftp/sftpuser نمونه‌اند. دستورات مالکیت را فقط پس از اطمینان از مسیر واقعی و مالک اطلاعات اجرا کنید؛ تغییر اشتباه می‌تواند دسترسی سایت‌ها یا کاربران دیگر را مختل کند.۱. ابتدا خطای سمت سرور را ببینید
در یک نشست مدیریتی روی سرور، درست بعد از تلاش ناموفق SFTP این دستور را اجرا کنید:
کد / دستورsudo journalctl -u ssh -u sshd --since '15 minutes ago' --no-pager
در Ubuntu نام سرویس معمولاً
ssh و در AlmaLinux معمولاً sshd است؛ نام واقعی سیستم شما ممکن است متفاوت باشد. در برخی نصب‌ها گزارش در فایل‌هایی مثل /var/log/auth.log یا /var/log/secure هم ذخیره می‌شود. نام کاربر، زمان و مسیر کنار bad ownership or modes را بخوانید.اگر به جای آن پیام
Permission denied (publickey) دارید، ابتدا کلید و روش احراز هویت را بررسی کنید. اگر اتصال شبکه اصلاً برقرار نمی‌شود، ممکن است مشکل پورت یا فایروال باشد. پس از هر تغییر، خطای جدید را دوباره بخوانید؛ هر قطع اتصالی به مالکیت chroot مربوط نیست.۲. مسیر مؤثر برای همین کاربر را پیدا کنید
نام حساب و پوشه خانگی ثبت‌شده آن را ببینید:
کد / دستورgetent passwd sftpuser
خروجی، حساب و مسیر home را نشان می‌دهد. اگر چیزی برنگشت، نام کاربر اشتباه است یا منبع هویت سیستم آن را پیدا نکرده است. سپس تنظیم نهایی SSH را برای یک اتصال نمونه بخوانید:
کد / دستورsudo /usr/sbin/sshd -T -C user=sftpuser,host=client.example,addr=192.0.2.10 | grep -E '^(chrootdirectory|forcecommand|subsystem|allowtcpforwarding) '
user را با حساب واقعی و addr و host را با اطلاعات سمت مشتری اتصال در صورت وجود قواعد Match متناسب کنید؛ آدرس نمونه واقعی نیست. دستور، تنظیم مؤثر و قواعد Match مناسب همان اتصال فرضی را نمایش می‌دهد و سرویس را restart نمی‌کند. اگر sshd در مسیر دیگری نصب است، با command -v sshd مسیرش را پیدا کنید.خط
chrootdirectory را با گزارش خطا و فایل‌های تنظیم SSH تطبیق دهید. در پیکربندی ممکن است از %u برای نام کاربر یا %h برای home استفاده شده باشد. به عنوان نمونه، اگر مسیر مؤثر برای این کاربر /srv/sftp/sftpuser باشد، اجزای /، /srv، /srv/sftp و پوشه نهایی همگی در بررسی OpenSSH اهمیت دارند.۳. مالک و مجوز همه اجزای مسیر را ببینید
کد / دستورsudo namei -l /srv/sftp/sftpuser
کد / دستورsudo ls -ld / /srv /srv/sftp /srv/sftp/sftpuser
در هر خط، مالک باید
root باشد و بیت نوشتن گروه یا دیگران فعال نباشد. مثلاً drwxr-xr-x root root برای یک پوشه اختصاصی معمولاً این شرط را دارد، اما drwxrwxr-x به گروه اجازه نوشتن می‌دهد و می‌تواند باعث رد شدن مسیر شود. ممکن است یک پوشه میانی مشکل داشته باشد؛ فقط به پوشه آخر نگاه نکنید.اگر پوشه‌ای مثل
/srv توسط چند سرویس استفاده می‌شود، پیش از تغییر مالک یا مجوز آن اثر تغییر را با مدیر سیستم بررسی کنید. هرگز برای رفع این خطا chown -R یا chmod -R را روی کل /srv، /home یا ریشه سرور اجرا نکنید. همچنین chmod 777 مشکل امنیتی ایجاد می‌کند و با شرط chroot سازگار نیست.۴. اصلاح پوشه ریشه chroot در یک مثال اختصاصی
فرض کنید بررسی کرده‌اید تمام پوشه‌های بالادستی سالم‌اند و فقط
کد / دستور/srv/sftp/sftpuser به اشتباه متعلق به همان کاربر شده است. همچنین تأیید کرده‌اید این پوشه به همین محیط SFTP اختصاص دارد. در آن صورت برای همان پوشه:sudo chown root:root /srv/sftp/sftpuser
کد / دستورsudo chmod 0755 /srv/sftp/sftpuser
دستور اول فقط مالک و گروه پوشه نام‌برده را تغییر می‌دهد و دومی آن را برای root قابل نوشتن و برای دیگران قابل خواندن و عبور می‌کند. این مثال دسترسی خواندن نام‌ها را به دیگران می‌دهد؛ اگر سیاست شما محدودتر است، حالت مناسب و دسترسی عبور کاربر را با مدیر سامانه طراحی کنید. دوباره
namei -l را اجرا کنید و مطمئن شوید هیچ جزء مسیر توسط گروه یا دیگران قابل نوشتن نیست.اگر پوشه میانی مشترک مشکل دارد، بدون شناخت سایر سرویس‌ها همان دو دستور را روی آن اجرا نکنید. نخست وابستگی‌ها و مسیر مناسب جداگانه را مشخص کنید.
۵. پوشه قابل آپلود جداگانه بسازید
کاربر نباید برای آپلود مجبور باشد ریشه chroot را در اختیار بگیرد. داخل آن یک زیرپوشه اختصاصی برای فایل‌های خودش بسازید. این مثال فقط زمانی قابل اجراست که پوشه
کد / دستورupload هنوز وجود ندارد و برای همین کاربر در نظر گرفته شده است:sudo mkdir -m 0700 /srv/sftp/sftpuser/upload
کد / دستورsudo chown sftpuser /srv/sftp/sftpuser/upload
کد / دستورsudo ls -ld /srv/sftp/sftpuser /srv/sftp/sftpuser/upload
باید ببینید پوشه ریشه متعلق به root و پوشه
upload متعلق به کاربر است. اگر upload از قبل وجود دارد، قبل از هر تغییر، مالک و محتوای آن را شناسایی کنید؛ تغییر مالک پوشه شخص دیگر می‌تواند اطلاعات را در اختیار حساب اشتباه بگذارد. اگر چند کاربر قرار است مشترکاً بنویسند، مجوز گروه و ACL را بر اساس طرح دسترسی همان سرویس تعیین کنید.برای یک بررسی محلی ساده، پس از جایگزینی نام کاربر:
کد / دستورsudo -u sftpuser test -w /srv/sftp/sftpuser/upload && echo 'upload directory is writable'
دیدن پیام یعنی آن آزمون محلی موفق بوده است؛ به‌تنهایی ورود SFTP، محدودیت chroot یا سیاست امنیتی را ثابت نمی‌کند.
۶. اگر ورود انجام می‌شود ولی کاربر پوشه را نمی‌بیند
بعد از ورود به chroot، ریشه‌ای که کاربر می‌بیند با ریشه سرور فرق دارد. مسیر میزبان
/srv/sftp/sftpuser/upload معمولاً در نشست محصور به شکل /upload دیده می‌شود. OpenSSH بعد از ورود به chroot تلاش می‌کند به home ثبت‌شده برای کاربر برود؛ اگر آن مسیر داخل محیط محصور وجود نداشته باشد، بسته به وضعیت ممکن است اخطار یا خطای تغییر پوشه ببینید. مسیر home، تنظیم internal-sftp و نیاز برنامه را با هم تطبیق دهید؛ تغییر home یک حساب موجود ممکن است سایر کاربردهای آن را تحت تأثیر بگذارد.اگر روی AlmaLinux از SELinux استفاده می‌کنید، وضعیت آن را ببینید:
کد / دستورgetenforce
و برچسب پوشه‌های موردنظر را بررسی کنید:
کد / دستورls -Zd /srv/sftp/sftpuser /srv/sftp/sftpuser/upload
اگر مجوز عادی درست است ولی سیاست SELinux دسترسی را رد می‌کند، گزارش و تنظیم برچسب مناسب همان توزیع و مسیر را بررسی کنید. خاموش کردن SELinux راه‌حل اولیه نیست؛ برای مسیر سفارشی ممکن است تعیین سیاست یا برچسب پایدار لازم باشد.
۷. اتصال و آپلود را واقعاً آزمایش کنید
پس از اصلاح مالکیت، معمولاً نیازی به راه‌اندازی مجدد SSH برای تغییر مجوز پوشه نیست. از رایانه مشتری با پورت واقعی و نام درست وارد شوید:
کد / دستورsftp -P 22 sftpuser@server.example
اگر اولین اتصال است، اثرانگشت کلید میزبان را از راهی مستقل با ارائه‌دهنده یا مدیر سرور تطبیق دهید. داخل محیط SFTP، مسیر جاری و پوشه‌ها را ببینید:
کد / دستورpwd
ls
cd /upload
یک فایل آزمایشی غیرمحرمانه با نام تازه در رایانه خود انتخاب کنید و با دستور
put آن را در همین پوشه بفرستید؛ سپس با ls وجود آن را ببینید و یک بار دانلود و باز کنید. اگر آپلود خطای مجوز داد، مالک upload، دسترسی عبور پوشه‌ها و در صورت نیاز SELinux را دوباره بررسی کنید.اگر ناچار به تغییر فایل تنظیم SSH شدید، قبل از اعمال حتماً دستور زیر باید بدون خطای پیکربندی برگردد:
کد / دستورsudo /usr/sbin/sshd -t
پس از آن، نام صحیح سرویس و روش reload توزیع را مشخص کنید و یک اتصال مدیریتی تازه را در کنار نشست باز امتحان کنید.
sshd -t صحت دسترسی واقعی کاربر را تضمین نمی‌کند. خاموش کردن StrictModes نیز بررسی اجباری مالکیت ChrootDirectory را دور نمی‌زند.این روش روی سرور مجازی ایران و سرور اختصاصی ایران با OpenSSH کاربرد دارد. شرط رسمی مالکیت مسیر و رفتار chroot در مستند sshd_config آمده است.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام