پروتکل Secure Shell (SSH) یکی از ابزارهای ضروری برای مدیران سیستم لینوکس است. این ابزار به شما این امکان را می‌دهد که از راحتی دفتر کار خود یا حتی از راحتی خانه‌تان، سرورهای لینوکس را مدیریت کنید. به هر حال، این روش بسیار بهتر از این است که مجبور شوید کاپشن خود را بپوشید و از موانع امنیتی عبور کنید تا وارد اتاق سرور سرد شوید. کلمه secure در Secure Shell به این معنی است که همه چیزی که تایپ می‌کنید یا انتقال می‌دهید، رمزنگاری می‌شود. این موضوع احتمال اینکه کسی داده‌های حساس را با اتصال به شبکه شما از طریق sniffer به دست آورد، از بین می‌برد.
در این مرحله از حرفه لینوکسی خود، باید بدانید چگونه از Secure Shell یا SSH برای ورود به سیستم از راه دور و انتقال فایل‌های از راه دور استفاده کنید. آنچه ممکن است ندانید این است که پیکربندی پیش‌فرض SSH در واقع نسبتاً ناامن است. در این فصل، ما به بررسی روش‌هایی برای تقویت پیکربندی پیش‌فرض خواهیم پرداخت. به بررسی نحوه استفاده از الگوریتم‌های رمزنگاری قوی‌تر از پیش‌فرض، نحوه راه‌اندازی احراز هویت بدون پسورد، و نحوه راه‌اندازی زندان برای کاربران Secure File Transfer Protocol (SFTP) خواهیم پرداخت. به عنوان یک امتیاز اضافی، به بررسی نحوه اسکن سرورهای SSH برای شناسایی پیکربندی‌های آسیب‌پذیر و نحوه اشتراک‌گذاری یک دایرکتوری از راه دور از طریق Secure Shell Filesystem (SSHFS) خواهیم پرداخت.
در این فصل، ما به بررسی موضوعات زیر خواهیم پرداخت:
- اطمینان از غیرفعال بودن پروتکل SSH نسخه 1
- ایجاد و مدیریت کلیدها برای ورود به سیستم بدون نیاز به رمز عبور
- غیرفعال کردن ورود کاربر روت
- غیرفعال کردن ورود با نام کاربری و رمز عبور
- پیکربندی Secure Shell با الگوریتم‌های رمزنگاری قوی
- تنظیم سیاست‌های رمزنگاری سراسری در RHEL 8/CentOS 8
- حالت FIPS در CentOS 8/Red Hat 8
- پیکربندی لاگینگ دقیق‌تر
- کنترل دسترسی با لیست سفید و TCP Wrappers
- پیکربندی خروج‌های خودکار و بنرهای امنیتی
- تنظیمات امنیتی مختلف دیگر
- پیکربندی تنظیمات متفاوت برای میزبان‌های مختلف
- پیکربندی تنظیمات مختلف برای کاربران و گروه‌های مختلف
- اسکن یک سرور SSH
- راه‌اندازی محیط chroot برای کاربران SFTP
- راه‌اندازی دایرکتوری‌های مشترک با SSHFS
- اتصال از راه دور از دسکتاپ‌های ویندوزی
پس اگر آماده هستید، بیایید شروع کنیم.
اطمینان از غیرفعال بودن پروتکل SSH نسخه 1
پروتکل نسخه 1 SSH، که پروتکل اصلی SSH است، دارای نقص‌های جدی است و نباید هرگز استفاده شود. این پروتکل هنوز در بیشتر توزیع‌های لینوکس موجود است، اما خوشبختانه به طور پیش‌فرض غیرفعال است. با این حال، فرض کنید فایل /etc/ssh/sshd_config خود را باز کرده و این خط را مشاهده کنید:
Protocol 1
یا ممکن است اینطور ببینید:
Protocol 1, 2
در صورتی که چنین چیزی را مشاهده کردید، با یک مشکل مواجه هستید.
صفحه راهنمای man برای فایل sshd_config در اوبونتو می‌گوید که نسخه پروتکل 1 هنوز برای استفاده با دستگاه‌های قدیمی در دسترس است. با این حال، اگر هنوز دستگاه‌هایی با چنین نسخه‌هایی دارید، باید به طور جدی به فکر ارتقاء آن‌ها باشید. همانطور که توزیع‌های لینوکس به‌روزرسانی می‌شوند، شما خواهید دید که پروتکل SSH نسخه 1 به تدریج به طور کامل حذف می‌شود، همانطور که در نسخه 7.4 از Red Hat و CentOS این اتفاق افتاده است.
ایجاد و مدیریت کلیدها برای ورود بدون پسورد
SSH یک مجموعه عالی از ابزارها است که برای برقراری ارتباط با سرورهای از راه دور استفاده می‌شود. شما می‌توانید از مولفه SSH برای وارد شدن به خط فرمان یک دستگاه از راه دور استفاده کنید و همچنین می‌توانید از scp یا sftp برای انتقال امن فایل‌ها استفاده کنید. روش پیش‌فرض برای استفاده از هرکدام از این مولفه‌ها، استفاده از نام کاربری و رمز عبور حساب کاربری لینوکس عادی یک فرد است. بنابراین، ورود به دستگاه از راه دور از ترمینال دستگاه OpenSUSE من چیزی شبیه به این خواهد بود:
donnie@linux-0ro8:~> ssh donnie@192.168.0.8
donnie@192.168.0.8's password:
اگرچه درست است که نام کاربری و رمز عبور به صورت رمزنگاری شده در شبکه منتقل می‌شود و این کار باعث می‌شود که برای مهاجمان نفوذ به آن سخت‌تر شود، اما هنوز هم این روش امن‌ترین راه برای انجام این کار نیست. مشکل اینجاست که مهاجمان به ابزارهای خودکاری دسترسی دارند که می‌توانند حملات brute-force رمز عبور را علیه یک سرور SSH انجام دهند. Botnetها، مانند Hail Mary Cloud، اسکن‌های مداومی در سراسر اینترنت انجام می‌دهند تا سرورهایی با SSH فعال را پیدا کنند.
اگر یک botnet متوجه شود که سرورها اجازه دسترسی به SSH را از طریق نام کاربری و رمز عبور می‌دهند، حمله brute-force رمز عبور را آغاز می‌کند. متاسفانه، چنین حملاتی چندین بار موفقیت‌آمیز بوده‌اند، به ویژه زمانی که اپراتورهای سرور اجازه می‌دهند که کاربر root از طریق SSH وارد شود.
این مقاله قدیمی اطلاعات بیشتری در مورد botnet Hail Mary Cloud فراهم می‌کند: لینک مقاله.
در بخش بعدی، به دو روش برای کمک به جلوگیری از این نوع حملات خواهیم پرداخت:
- فعال کردن ورود SSH از طریق تبادل کلیدهای عمومی
- غیرفعال کردن ورود کاربر root از طریق SSH
حالا بیایید چند کلید ایجاد کنیم.
ایجاد مجموعه کلید SSH برای یک کاربر
هر کاربر این امکان را دارد که مجموعه‌ای از کلیدهای خصوصی و عمومی خود را ایجاد کند. فرقی ندارد که دستگاه مشتری کاربر از لینوکس، macOS، Cygwin در ویندوز، یا Bash Shell برای ویندوز استفاده می‌کند. در تمام این موارد، روند انجام کار دقیقاً یکسان است.
ایجاد کلیدهای SSH برای کاربران
انواع مختلفی از کلیدها وجود دارند که می‌توانید ایجاد کنید، و معمولاً کلیدهای RSA با طول 2048 بیت به عنوان پیش‌فرض استفاده می‌شوند. تا مدت زمان نه چندان طولانی، کلیدهای RSA با طول 2048 بیت به اندازه کافی قوی برای آینده پیش‌بینی شده در نظر گرفته می‌شدند. اما اکنون، جدیدترین راهنمایی‌های مؤسسه ملی استانداردها و فناوری ایالات متحده (NIST) توصیه می‌کند که از کلید RSA با حداقل 3072 بیت یا از کلید الگوریتم امضای دیجیتال منحنی بیضوی (ECDSA) با حداقل 384 بیت استفاده کنید. (گاهی اوقات این کلیدهای ECDSA به عنوان P-384 نیز شناخته می‌شوند). دلیل این توصیه این است که آن‌ها می‌خواهند ما را برای محاسبات کوانتومی آماده کنند، که آن‌قدر قدرتمند خواهد بود که هر الگوریتم رمزنگاری ضعیف‌تر را منسوخ می‌کند. البته، محاسبات کوانتومی هنوز عملیاتی نشده است و تا به حال به نظر می‌رسد که همیشه چیزی است که ده سال دیگر در آینده خواهد آمد، فارغ از اینکه در کدام سال هستیم. اما حتی اگر فرض کنیم که مسئله محاسبات کوانتومی را نادیده بگیریم، باید اذعان کنیم که کامپیوترهای غیرکوانتومی فعلی ما همچنان قدرتمندتر و قدرتمندتر می‌شوند. بنابراین، هنوز هم ایده بدی نیست که شروع به استفاده از استانداردهای رمزنگاری قوی‌تر کنیم.
برای مشاهده لیست الگوریتم‌های رمزنگاری توصیه شده توسط NIST و طول‌های کلید پیشنهادی، می‌توانید به این لینک مراجعه کنید.
برای این چند دمو، بیایید به یک کلاینت Ubuntu 18.04 تغییر وضعیت دهیم. برای ایجاد یک جفت کلید RSA با طول 3072 بیت، کافی است دستور زیر را وارد کنید:
donnie@ubuntu1804-1:~$ ssh-keygen -t rsa -b 3072
در اینجا، از گزینه -t برای مشخص کردن اینکه می‌خواهیم یک کلید RSA ایجاد کنیم و از گزینه -b برای تعیین طول بیت استفاده می‌کنیم. زمانی که از شما خواسته شد تا محل و نام کلیدها را وارد کنید، من فقط Enter را می‌زنم تا مقادیر پیش‌فرض انتخاب شوند. شما می‌توانید کلید خصوصی را بدون عبارت عبور رها کنید، اما این روش توصیه نمی‌شود.
توجه داشته باشید که اگر نامی متفاوت برای فایل‌های کلید خود انتخاب کنید، باید مسیر کامل فایل‌ها را وارد کنید تا همه چیز به درستی کار کند. برای مثال، در حالت من، مسیر کلیدهای donnie_rsa را باید به صورت /home/donnie/.ssh/donnie_rsa مشخص کنم.
شما کلیدهای جدید خود را در دایرکتوری .ssh مشاهده خواهید کرد:
donnie@ubuntu1804-1:~$ ls -l .ssh
total 8
-rw------- 1 donnie donnie 2546 Aug 28 15:23 id_rsa
-rw-r--r-- 1 donnie donnie 573 Aug 28 15:23 id_rsa.pub
donnie@ubuntu1804-1:~$
در اینجا:
id_rsaکلید خصوصی شما است.id_rsa.pubکلید عمومی شما است.
همانطور که مشاهده می‌کنید، id_rsa دارای دسترسی‌های محدود (-rw-------) است، به این معنا که فقط شما (کاربر donnie) می‌توانید آن را بخوانید و بنویسید، که امنیت مناسبی را فراهم می‌کند. کلید عمومی (id_rsa.pub) به صورت خواندنی برای دیگران قرار دارد تا بتوان آن را به راحتی در سرورهای دیگر برای احراز هویت SSH استفاده کرد.
توجه داشته باشید که اگر کلیدهای پیش‌فرض 2048 بیتی را ایجاد کرده باشید، نام‌ها مشابه خواهند بود.
- کلید id_rsa کلید خصوصی شما است و فقط شما می‌توانید آن را بخوانید و بنویسید.
- کلید id_rsa.pub کلید عمومی شما است که باید برای همه قابل خواندن باشد.
برای کلیدهای ECDSA، طول پیش‌فرض 256 بیت است. اگر تصمیم بگیرید از ECDSA به جای RSA استفاده کنید، برای ایجاد یک کلید قوی 384 بیتی دستور زیر را وارد کنید:
donnie@ubuntu1804-1:~$ ssh-keygen -t ecdsa -b 384
در هر صورت، وقتی به دایرکتوری .ssh نگاه کنید، خواهید دید که نام کلیدهای ECDSA با کلیدهای RSA متفاوت هستند:
donnie@ubuntu1804-1:~$ ls -l .ssh
total 8
-rw------- 1 donnie donnie 379 May 27 17:43 id_ecdsa
-rw-r--r-- 1 donnie donnie 225 May 27 17:43 id_ecdsa.pub
donnie@ubuntu1804-1:~$
زیبایی الگوریتم‌های منحنی بیضوی (elliptic curve) این است که طول‌های کلید به ظاهر کوتاه‌شان، به اندازه کلیدهای بلند RSA امن هستند. حتی بزرگترین کلیدهای ECDSA نیز به قدرت محاسباتی کمتری نسبت به کلیدهای RSA نیاز دارند. طول کلید حداکثری که می‌توانید با ECDSA استفاده کنید، 521 بیت است. (بله، درست خواندید. 521 بیت، نه 524 بیت.)
پس ممکن است بپرسید، چرا فقط از کلیدهای 521 بیتی استفاده نکنیم؟ دلیل اصلی این است که کلیدهای 521 بیتی توسط NIST توصیه نمی‌شوند. دلیل این امر نگرانی از حملات padding است که می‌تواند به مهاجمان اجازه دهد رمزنگاری شما را بشکنند و داده‌های شما را سرقت کنند.
اگر نگاهی به صفحه راهنمای man برای ssh-keygen بیندازید، متوجه خواهید شد که می‌توانید یک کلید از نوع Ed25519 ایجاد کنید، که گاهی اوقات به آن curve25519 نیز گفته می‌شود. این نوع در لیست الگوریتم‌های توصیه‌شده توسط NIST قرار ندارد، اما چند دلیل وجود دارد که چرا برخی افراد ترجیح می‌دهند از آن استفاده کنند.
اولین دلیل این است که RSA و DSA می‌توانند هنگام ایجاد امضاها داده‌های کلید خصوصی را فاش کنند، اگر تولیدکننده عدد تصادفی سیستم‌عامل دچار مشکل باشد. Ed25519 نیازی به تولید عدد تصادفی هنگام ایجاد امضاها ندارد، بنابراین در برابر این مشکل مقاوم است. علاوه بر این، Ed25519 به گونه‌ای کدنویسی شده است که نسبت به حملات side-channel بسیار کمتر آسیب‌پذیر است. (حملات side-channel زمانی اتفاق می‌افتد که فردی تلاش می‌کند ضعف‌های موجود در سیستم‌عامل پایه را به جای الگوریتم رمزنگاری مورد سوءاستفاده قرار دهد.)
دلیل دوم که برخی افراد Ed25519 را ترجیح می‌دهند دقیقاً به این دلیل است که در لیست NIST قرار ندارد. این افراد کسانی هستند که به طور درست یا نادرست، به توصیه‌های نهادهای دولتی اعتماد ندارند.
چند سال پیش، در اوایل این قرن، یک رسوایی در مورد Dual Elliptic Curve Deterministic Random Bit Generator (Dual_EC_DRBG) وجود داشت. این یک تولیدکننده عدد تصادفی بود که قرار بود برای استفاده در رمزنگاری منحنی بیضوی (elliptic curve cryptography) طراحی شود. مشکل این بود که در ابتدا، برخی از محققان مستقل متوجه شدند که این تولیدکننده قابلیت‌هایی برای ایجاد درب‌های پشتی (back doors) داشت، که هر کسی که از این قابلیت آگاه باشد، می‌توانست آن‌ها را وارد کند. و جالب اینجاست که تنها افرادی که باید از این قابلیت مطلع می‌بودند، کسانی بودند که در آژانس امنیت ملی ایالات متحده (NSA) کار می‌کردند. به درخواست NSA، NIST Dual_EC_DRBG را در لیست الگوریتم‌های توصیه‌شده خود قرار داد، و این وضعیت تا آوریل ۲۰۱۴ ادامه داشت تا اینکه در نهایت آن را حذف کردند.
برای کسب جزئیات بیشتر در این مورد می‌توانید به لینک‌های زیر مراجعه کنید:
برای خواندن جزئیات بیشتر در مورد Ed25519، می‌توانید به لینک زیر مراجعه کنید:
برای Ed25519 تنها یک اندازه کلید وجود دارد که ۲۵۶ بیت است. بنابراین، برای ایجاد یک کلید curve25519 کافی است از دستور زیر استفاده کنید:
donnie@ubuntu1804-1:~$ ssh-keygen -t ed25519
در اینجا کلیدهایی که ایجاد کرده‌ام را مشاهده می‌کنید:
donnie@ubuntu1804-1:~$ ls -l .ssh
total 8
-rw------- 1 donnie donnie 464 May 27 20:11 id_ed25519
-rw-r--r-- 1 donnie donnie 101 May 27 20:11 id_ed25519.pub
donnie@ubuntu1804-1:~$
با این حال، Ed25519 برخی معایب بالقوه دارد:
۱. عدم پشتیبانی توسط کلاینت‌های قدیمی SSH: اگرچه این مشکل وقتی همه اعضای تیم از سیستم‌عامل‌های جدید و کلاینت‌های SSH به‌روز استفاده می‌کنند، نباید مسئله‌ساز باشد.
۲. فقط یک طول کلید ثابت: این کلید معادل الگوریتم‌های رمزنگاری منحنی بیضوی ۲۵۶ بیتی یا RSA ۳۰۰۰ بیتی است. بنابراین ممکن است به اندازه برخی الگوریتم‌های دیگر که پوشش داده‌ایم، از نظر آینده‌نگری مناسب نباشد.
۳. عدم سازگاری با الزامات NIST: اگر سازمان شما باید مطابق با توصیه‌های NIST عمل کند، نمی‌توانید از این کلید استفاده کنید.
در نهایت، نوع دیگری از کلید که هنوز توسط ssh-keygen قابل ایجاد است، کلید DSA قدیمی است. اما توصیه نمی‌شود که از این نوع استفاده کنید. الگوریتم DSA قدیمی، شکننده و از نظر استانداردهای مدرن بسیار ناامن است. بنابراین، وقتی به DSA رسیدید، فقط بگویید خیر.
انتقال کلید عمومی به سرور راه دور به سرور این امکان را می‌دهد که هم من و هم دستگاه کلاینت من را شناسایی کند. قبل از اینکه بتوانم کلید عمومی خود را به سرور راه دور منتقل کنم، ابتدا باید کلید خصوصی را به keyring جلسه خود اضافه کنم. این کار نیازمند دو دستور است. (یک دستور ssh-agent را اجرا می‌کند و دستور دیگر کلید خصوصی را به keyring اضافه می‌کند):
donnie@ubuntu1804-1:~$ exec /usr/bin/ssh-agent $SHELL
donnie@ubuntu1804-1:~$ ssh-add
Enter passphrase for /home/donnie/.ssh/id_rsa:
Identity added: /home/donnie/.ssh/id_rsa (/home/donnie/.ssh/id_rsa)
Identity added: /home/donnie/.ssh/id_ecdsa (/home/donnie/.ssh/id_ecdsa)
Identity added: /home/donnie/.ssh/id_ed25519 (donnie@ubuntu1804-1)
donnie@ubuntu1804-1:~$
در نهایت، می‌توانم کلیدهای عمومی خود را به سرور CentOS که در آدرس 192.168.0.8 قرار دارد منتقل کنم:
donnie@ubuntu1804-1:~$ ssh-copy-id donnie@192.168.0.8
The authenticity of host '192.168.0.8 (192.168.0.8)' can't be established.
ECDSA key fingerprint is
SHA256:jUVyJDJl2AHJgyrqLudOWx4YUtbUxD88tv5oKeFtfXk.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to
filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 3 key(s) remain to be installed -- if you are
prompted now it is to install the new keys
donnie@192.168.0.8's password:
Number of key(s) added: 3
Now try logging into the machine, with: "ssh 'donnie@192.168.0.8'"
and check to make sure that only the key(s) you wanted were added.
donnie@ubuntu1804-1:~$
با این کار، کلیدهای عمومی شما به سرور مقصد اضافه شده‌اند و می‌توانید به‌طور امن وارد سرور شوید. معمولاً شما فقط یک جفت کلید از نوعی که انتخاب کرده‌اید، می‌سازید. همانطور که در اینجا می‌بینید، من سه جفت کلید ساخته‌ام، یک جفت از هر نوع. تمام سه کلید خصوصی به session keyring من اضافه شده‌اند و تمام سه کلید عمومی به سرور راه دور منتقل شده‌اند. دفعه بعد که وارد سیستم شوم، از key exchange استفاده می‌کنم و نیازی به وارد کردن رمز عبور نخواهم داشت:
donnie@ubuntu1804-1:~$ ssh donnie@192.168.0.8
Last login: Wed Aug 28 13:43:50 2019 from 192.168.0.225
[donnie@localhost ~]$
همانطور که قبلاً گفتم، معمولاً شما فقط یک جفت کلید برای هر دستگاه می‌سازید. با این حال، استثنائاتی برای این قانون وجود دارد. برخی از مدیران ترجیح می‌دهند برای هر سروری که مدیریت می‌کنند، از یک جفت کلید مختلف استفاده کنند، به جای اینکه از همان جفت کلید برای تمام سرورها استفاده کنند. یک روش راحت برای این کار این است که کلیدها را با نام فایل‌هایی که با نام میزبان سرورهای مربوطه مطابقت دارند، بسازید. سپس می‌توانید از گزینه -i برای مشخص کردن جفت کلیدی که می‌خواهید استفاده کنید، استفاده کنید.
در این مثال، من فقط یک سرور دارم، اما کلیدهای مختلفی برای آن دارم. فرض کنید که من ترجیح می‌دهم از کلیدهای Ed25519 استفاده کنم:
donnie@ubuntu1804-1:~$ ssh -i ~/.ssh/id_ed25519 donnie@192.168.0.8
Last login: Wed Aug 28 15:58:26 2019 from 192.168.0.3
[donnie@localhost ~]$
حالا شاید بپرسید که اگر من بدون وارد کردن رمز عبور وارد می‌شوم، چطور این امن است؟ جواب این است که وقتی پنجره ترمینال دستگاه کلاینت خود را که برای وارد شدن استفاده کرده‌ام ببندم، کلید خصوصی از session keyring من حذف می‌شود. وقتی ترمینال جدیدی باز می‌کنم و می‌خواهم به سرور راه دور وارد شوم، این پیام را می‌بینم:
donnie@ubuntu1804-1:~$ ssh donnie@192.168.0.8
Enter passphrase for key '/home/donnie/.ssh/id_rsa':
Last login: Wed Aug 28 16:00:33 2019 from 192.168.0.3
[donnie@localhost ~]$
پس هر بار که وارد این سرور می‌شوم، باید رمز عبور کلید خصوصی خود را وارد کنم (مگر اینکه آن را دوباره به session keyring اضافه کنم با دو دستوری که قبلاً نشان دادم)…
