اصول SSH: کار با سرورها، کلاینت‌ها و کلیدهای SSH

مقدمه

SSH یک پروتکل امن است که به‌عنوان روش اصلی برای اتصال و مدیریت سرورهای ریموت لینوکسی استفاده می‌شود. این پروتکل دسترسی رمزنگاری‌شده برای اجرای دستورات، انتقال فایل و فوروارد کردن ترافیک شبکه فراهم می‌کند و ابزاری بنیادی برای مدیریت سیستم و روندهای توسعه است.

این راهنما هم مبانی و هم جزئیات عملیِ لازم برای کار مؤثر با SSH را پوشش می‌دهد. علاوه بر روش‌های اتصال پایه، نحوه کار احراز هویت SSH، نحوه برقراری اعتماد با کلیدها و پیکربندی امن SSH در هر دو سمت سرور و کلاینت را توضیح می‌دهد. همچنین راهنمایی درباره تونل‌سازی ترافیک، مدیریت نشست‌ها و تشخیص مشکلات رایج اتصال شامل می‌شود.

این مقاله به‌عنوان منبعی به سبک مرجع نوشته شده. می‌توانید از ابتدا تا انتها بخوانیدش تا درک کاملی از SSH بسازید، یا مستقیماً به بخش‌هایی بپرید که نیاز فوری‌تان را برطرف می‌کنند.

اپلیکیشن‌های فرانت‌اند خود را از گیت‌هاب روی زیرساخت ابری پارمین کلود دیپلوی کنید و مقیاس‌پذیری و مدیریت زیرساخت را به پارمین کلود بسپارید.

نکات کلیدی

• SSH ابزار پیش‌فرض برای دسترسی امن ریموت به سرورهای لینوکسی است. اجرای دستور رمزنگاری‌شده، انتقال فایل و تونل‌سازی شبکه روی شبکه‌های غیرقابل اعتماد را ممکن می‌کند.
• SSH به معماری کلاینت-سرور با مسئولیت‌های صریح متکی است. دیمن SSH اتصالات ورودی را روی سرور مدیریت می‌کند؛ در حالی که کلاینت، احراز هویت و رفتار نشست را کنترل می‌نماید.
• کلیدهای SSH امنیت قوی‌تری از رمز عبور فراهم می‌کنند و باید استاندارد باشند. احراز هویت مبتنی بر کلید از اسرار مشترک اجتناب و از حملات brute-force و استفاده مجدد از اعتبارنامه جلوگیری می‌کند.
• اعتماد SSH از قبل برقرار می‌شود، نه حین ورود. سرورها به کلیدهای عمومیِ قرارگرفته در authorized_keys اعتماد می‌کنند و کلاینت‌ها با در اختیار داشتن کلید خصوصی متناظر، هویت‌شان را اثبات می‌کنند.
• احراز هویت کاربر و تأیید هاست، مسائل امنیتی متفاوتی را حل می‌کنند. کلیدهای SSH کاربران را احراز هویت می‌کنند؛ در حالی که کلیدهای هاست، کلاینت‌ها را از اتصال به سرورهای جعل‌شده محافظت می‌کنند.
• محافظت از کلید خصوصی برای امنیت SSH حیاتی است. کلیدهای خصوصی باید محلی بمانند، با مجوزها و passphraseهای اختیاری امن شوند و هرگز به سرورها کپی نشوند.
• یک پایه امن SSH به‌طور چشمگیری سطح افشا را کاهش می‌دهد. غیرفعال کردن ورود با رمز عبور، بلاک کردن دسترسی مستقیم root، محدود کردن تلاش‌ها و اجازه صریح به کاربران باید روش استاندارد باشد.
• پیکربندی سمت کلاینت SSH، ایمنی و کاربردپذیری را بهبود می‌بخشد. فایل ~/.ssh/config اتصالات را ساده، رفتار سازگار را الزامی و خطای انسانی را کاهش می‌دهد.
• تونل‌سازی SSH آن را فراتر از شل‌های ریموت گسترش می‌دهد. تونل‌های محلی، ریموت و داینامیک امکان دسترسی رمزنگاری‌شده به سرویس‌ها و شبکه‌هایی را می‌دهند که در غیر این صورت غیرقابل دسترس بودند.
• بیشتر مشکلات SSH قابل پیش‌بینی و قابل تشخیص‌اند. مسائل مجوز، عدم تطابق احراز هویت، در دسترس بودن سرویس و خطاهای تأیید هاست، عامل اکثریت خرابی‌ها هستند.

نحوه استفاده از این راهنما

از هر کدام از بخش‌های بعدی که به آنچه سعی در دستیابی به آن دارید قابل استفاده‌اند بهره ببرید. بیشتر بخش‌ها به هیچ بخش دیگری متکی نیستند؛ پس می‌توانید مثال‌های زیر را مستقل استفاده کنید.

• از منوی فهرست مطالب در سمت چپ این صفحه (در عرض‌های زیاد صفحه) یا تابع جستجوی مرورگرتان برای پیدا کردن بخش‌های مورد نیاز استفاده کنید.
• مثال‌های خط فرمان داده‌شده را کپی و پیست کنید و مقادیر هایلایت‌شده را با مقادیر خودتان جایگزین کنید.

نمای کلی SSH

رایج‌ترین راه اتصال به یک سرور ریموت لینوکسی، از طریق SSH است. SSH مخفف Secure Shell (شل امن) است و روشی امن و مطمئن برای اجرای دستورات، اعمال تغییرات و پیکربندی سرویس‌ها به‌صورت ریموت فراهم می‌کند. وقتی از طریق SSH وصل می‌شوید، با حسابی وارد می‌شوید که روی سرور ریموت وجود دارد.

SSH چگونه کار می‌کند

وقتی از طریق SSH وصل می‌شوید، وارد یک نشست شل (Shell Session) می‌شوید؛ رابطی مبتنی بر متن که می‌توانید با سرورتان تعامل کنید. در طول نشست SSH شما، هر دستوری که در ترمینال محلی‌تان تایپ می‌کنید، از طریق یک تونل رمزنگاری‌شده SSH ارسال و روی سرورتان اجرا می‌شود.

اتصال SSH با مدل کلاینت-سرور پیاده‌سازی می‌شود. یعنی برای برقراری اتصال SSH، ماشین ریموت باید نرم‌افزاری به نام دیمن SSH را اجرا کند. این نرم‌افزار به اتصالات روی یک پورت شبکه خاص گوش می‌دهد، درخواست‌های اتصال را احراز هویت می‌کند و اگر کاربر اعتبارنامه‌های درست را ارائه کند، محیط مناسب را ایجاد می‌کند.

کامپیوتر کاربر باید یک کلاینت SSH داشته باشد. این نرم‌افزاری است که می‌داند چگونه با پروتکل SSH ارتباط برقرار کند و می‌توان به آن اطلاعاتی درباره هاست ریموتِ هدف اتصال، نام کاربری برای استفاده و اعتبارنامه‌هایی که باید برای احراز هویت ارسال شوند داد. کلاینت همچنین می‌تواند جزئیات خاصی درباره نوع اتصالی که می‌خواهد برقرار کند مشخص نماید.

SSH چگونه کاربران را احراز هویت می‌کند

کلاینت‌ها معمولاً یا با رمز عبور (کم‌امنیت‌تر و توصیه‌نشده) یا با کلیدهای SSH احراز هویت می‌شوند؛ که بسیار امن‌اند.

ورودهای رمز عبور رمزنگاری‌شده‌اند و برای کاربران جدید قابل فهم‌اند. اما بات‌های خودکار و کاربران مخرب اغلب مکرراً تلاش می‌کنند به حساب‌هایی که ورود مبتنی بر رمز عبور را مجاز می‌دارند احراز هویت شوند؛ که می‌تواند به به‌خطرافتادن امنیت منجر شود. به این دلیل، همیشه راه‌اندازی احراز هویت مبتنی بر کلید SSH را برای بیشتر پیکربندی‌ها توصیه می‌کنیم.

کلیدهای SSH مجموعه‌ای متناظر از کلیدهای رمزنگاری‌اند که می‌توانند برای احراز هویت استفاده شوند. هر مجموعه شامل یک کلید عمومی و یک کلید خصوصی است. کلید عمومی را می‌توان بدون نگرانی آزادانه به اشتراک گذاشت؛ در حالی که کلید خصوصی باید بیدارانه محافظت شود و هرگز برای کسی افشا نشود.

برای احراز هویت با کلیدهای SSH، کاربر باید یک جفت‌کلید SSH روی کامپیوتر محلی‌اش داشته باشد. روی سرور ریموت، کلید عمومی باید به فایلی در دایرکتوری خانه کاربر در ~/.ssh/authorized_keys کپی شود. این فایل فهرستی از کلیدهای عمومی—یکی در هر خط—است که برای ورود به این حساب authorize شده‌اند.

وقتی کلاینتی به هاست وصل و تلاش می‌کند از احراز هویت کلید SSH استفاده کند، سرور فایل authorized_keys را برای کلید عمومی متناظر بررسی می‌کند. سپس سرور داده‌های احراز هویت را به کلاینت می‌فرستد؛ که با کلید خصوصی مرتبط، یک امضای دیجیتال می‌سازد. سرور این امضا را با کلید عمومی تأیید می‌کند. اگر تأیید موفق باشد، سرور تصدیق می‌کند که کلاینت کلید خصوصی درست را در اختیار دارد و اتصال را مجاز می‌کند.

این فرایند احراز هویت بر رابطه اعتمادی بنا شده که قبل از هر تلاش ورودی برقرار شده. سرور کلید خصوصی کاربر را یاد نمی‌گیرد یا ذخیره نمی‌کند. در عوض، به حضور یک کلید عمومی تأییدشده و توانایی کلاینت در اثبات مالکیت کلید خصوصی متناظر متکی است.

SSH چگونه اعتماد بین کلاینت و سرور برقرار می‌کند

احراز هویت کلید SSH از رمزنگاری نامتقارن برای برقراری اعتماد بدون به اشتراک‌گذاری اعتبارنامه استفاده می‌کند. اعتماد وقتی ایجاد می‌شود که مدیر سرور، کلید عمومی‌ای را در فایل ~/.ssh/authorized_keys برای حساب کاربری قرار دهد.

با افزودن کلید عمومی به این فایل، سرور صریحاً طوری پیکربندی می‌شود که به هر کلاینتی که بتواند مالکیت کلید خصوصی متناظر را نشان دهد اعتماد کند. این تصمیمی اداری است که از قبل گرفته شده و حین ورود مذاکره نمی‌شود.

حین احراز هویت، سرور چالش رمزنگاری‌ای صادر می‌کند که فقط کلاینتی که کلید خصوصی را دارد می‌تواند درست جوابش بدهد. کلید خصوصی هرگز سیستم کلاینت را ترک نمی‌کند و هرگز به سرور یا روی شبکه منتقل نمی‌شود.

چون سرور فقط کلیدهای عمومی را ذخیره می‌کند، به‌خطرافتادن سرور، اعتبارنامه‌های خصوصی را افشا نمی‌کند. دسترسی را هم می‌توان هر زمان با حذف کلید عمومی از فایل authorized_keys لغو کرد.

اعتماد احراز هویت کاربر در مقابل تأیید هاست

SSH از دو سازوکار اعتماد جداگانه استفاده می‌کند که اهداف متفاوتی دارند.

• احراز هویت کاربر تأیید می‌کند که کلاینت مجاز به ورود به حسابی روی سرور است. این فرایند به کلیدهای SSH و فایل authorized_keys متکی است.
• تأیید هاست (Host Verification) تأیید می‌کند که کلاینت به سرور موردنظر وصل می‌شود. این کار از طریق کلیدهای هاست سرور انجام می‌شود؛ که روی کلاینت در فایل ~/.ssh/known_hosts ذخیره می‌شوند.

این سازوکارها مستقل کار می‌کنند. احراز هویت کلید SSH تأیید می‌کند چه کسی وارد می‌شود؛ در حالی که تأیید هاست از اتصال به سرور غیرمنتظره یا جعل‌شده محافظت می‌کند.

حالا که می‌دانید SSH چگونه کار می‌کند، می‌توانیم بحث درباره چند مثال برای نمایش روش‌های مختلف کار با SSH را شروع کنیم.

تولید و کار با کلیدهای SSH

این بخش پوشش می‌دهد چطور روی ماشین کلاینت کلیدهای SSH تولید و کلید عمومی به سرورهایی که باید استفاده شوند توزیع شود. اگر قبلاً کلیدهایی تولید نکرده‌اید، این بخش خوبی برای شروع است؛ به‌دلیل امنیت ارتقایافته‌ای که برای اتصالات آینده فراهم می‌کند.

تولید یک جفت‌کلید SSH

تولید یک جفت‌کلید عمومی و خصوصی جدید SSH روی کامپیوتر محلی‌تان، اولین قدم برای احراز هویت با سرور ریموت بدون رمز عبور است. تا وقتی دلیل خوبی برای نداشتن وجود ندارد، همیشه باید با کلیدهای SSH احراز هویت کنید.

تعدادی الگوریتم رمزنگاری را می‌توان برای تولید کلیدهای SSH استفاده کرد؛ از جمله Ed25519، RSA و ECDSA. کلیدهای Ed25519 عموماً به‌دلیل امنیت قوی، اندازه کلید کوچک و کارایی خوب ترجیح داده می‌شوند. کلیدهای RSA هنوز به‌طور گسترده پشتیبانی می‌شوند؛ اما باید با طول کلید حداقل ۳۰۷۲ یا ۴۰۹۶ بیت ساخته شوند.

برای تولید یک جفت‌کلید RSA روی کامپیوتر محلی‌تان، تایپ کنید:

ssh-keygen

Generating public/private rsa key pair.
Enter file in which to save the key (/home/demo/.ssh/id_rsa):

این پرامپت به شما اجازه می‌دهد مکان ذخیره کلید خصوصی RSA را انتخاب کنید. برای رها کردن این مقدار به‌عنوان پیش‌فرض ENTER را بزنید؛ که آن‌ها را در دایرکتوری مخفی .ssh در دایرکتوری خانه کاربر ذخیره می‌کند. رها کردن مکان پیش‌فرض انتخاب‌شده، به کلاینت SSH اجازه می‌دهد کلیدها را خودکار پیدا کند.

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

پرامپت بعدی به شما اجازه می‌دهد یک passphrase با طول دلخواه برای امن کردن کلید خصوصی وارد کنید. به‌عنوان اقدام امنیتی اضافی، باید هر passphraseای را که اینجا تعیین می‌کنید هر بار که از کلید خصوصی استفاده می‌کنید وارد کنید. اگر passphrase نمی‌خواهید راحت باشید برای خالی گذاشتن ENTER را بزنید. البته در نظر داشته باشید که این اجازه می‌دهد هر کسی که کنترل کلید خصوصی‌تان را به دست بگیرد به سرورهایتان وارد شود.

اگر انتخاب کنید passphrase وارد کنید، هیچ چیزی هنگام تایپ نمایش داده نمی‌شود. این احتیاطی امنیتی است. خروجی زیر تولید کلید RSA را منعکس می‌کند:

Output
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
8c:e9:7c:fa:bf:c4:e5:9c:c9:b8:60:1f:fe:1c:d3:8a root@here
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|                 |
|       +         |
|      o S   .    |
|     o   . * +   |
|      o + = O .  |
|       + = = +   |
|      ....Eo+    |
+-----------------+

این فرایند یک جفت‌کلید SSH RSA در دایرکتوری مخفی .ssh داخل دایرکتوری خانه کاربر تولید کرد. این فایل‌ها عبارت‌اند از:

• ~/.ssh/id_rsa: کلید خصوصی. این فایل را به اشتراک نگذارید!
• ~/.ssh/id_rsa.pub: کلید عمومی مرتبط. این را می‌توان بدون عاقبت آزادانه به اشتراک گذاشت.

نکته: می‌توانید به راهنمای «ساخت کلیدهای SSH با OpenSSH در macOS یا Windows Subsystem» در پارمین کلود مراجعه کنید.

تولید جفت‌کلید SSH با تعداد بیت بیشتر

هنگام تولید کلیدها بدون مشخص کردن الگوریتم، نسخه‌های مدرن OpenSSH به‌طور پیش‌فرض Ed25519 را انتخاب می‌کنند. کلیدهای RSA اگر صریحاً انتخاب شوند به ۲۰۴۸ بیت پیش‌فرض می‌شوند؛ البته ۳۰۷۲ یا ۴۰۹۶ بیت توصیه می‌شود. این عموماً برای امنیت کافی در نظر گرفته می‌شود؛ اما می‌توانید تعداد بیت بیشتری برای کلید امن‌ترِ مشخص کنید.

برای این کار، آرگومان -b را همراه تعداد بیت موردنظر بگنجانید. بیشتر سرورها کلیدهایی با طول حداقل ۴۰۹۶ بیت را پشتیبانی می‌کنند. اندازه‌های کلید بزرگ‌تر عموماً بازده امنیتی کاهنده‌ای دارند و ممکن است توسط همه پیاده‌سازی‌ها پشتیبانی نشوند:

ssh-keygen -b 4096

اگر قبلاً کلید متفاوتی ساخته باشید، از شما پرسیده می‌شود که مایل به بازنویسی کلید قبلی هستید یا نه:

Overwrite (y/n)?

اگر «yes» را انتخاب کنید، کلید قبلی‌تان بازنویسی می‌شود و دیگر نمی‌توانید با آن کلید به سرورها وارد شوید. به همین دلیل، حتماً با احتیاط کلیدها را بازنویسی کنید.

حذف یا تغییر passphrase روی کلید خصوصی

اگر برای کلید خصوصی‌تان passphrase تولید کرده و مایل به تغییر یا حذف آن هستید، می‌توانید به‌راحتی این کار را انجام دهید.

نکته: برای تغییر یا حذف passphrase، باید passphrase اصلی را بدانید. اگر passphrase کلید را گم کرده‌اید، راهی وجود ندارد و باید یک جفت‌کلید جدید تولید کنید.

برای تغییر یا حذف passphrase، ساده تایپ کنید:

ssh-keygen -p

Enter file in which the key is (/root/.ssh/id_rsa):

می‌توانید مکان کلیدی را که می‌خواهید تغییر دهید تایپ کنید یا برای پذیرش مقدار پیش‌فرض ENTER را بزنید:

Enter old passphrase:

passphrase قدیمی‌ای را که می‌خواهید تغییر دهید وارد کنید. سپس از شما یک passphrase جدید پرسیده می‌شود:

Enter new passphrase (empty for no passphrase):
Enter same passphrase again:

اینجا، passphrase جدیدتان را وارد کنید یا برای حذف passphrase، ENTER را بزنید.

نمایش اثر انگشت کلید SSH

هر جفت‌کلید SSH یک «اثر انگشت» رمزنگاری مشترک دارد که می‌توان از آن برای شناسایی یکتای کلیدها استفاده کرد. این در موقعیت‌های مختلفی مفید است.

برای فهمیدن اثر انگشت یک کلید SSH، تایپ کنید:

ssh-keygen -l

Enter file in which the key is (/root/.ssh/id_rsa):

اگر این مکان درست کلید است می‌توانید ENTER را بزنید؛ در غیر این صورت مکان اصلاح‌شده را وارد کنید. رشته‌ای به شما داده می‌شود که شامل طول-بیت کلید، اثر انگشت، حساب و هاستی که برایش ساخته شده و الگوریتم استفاده‌شده است:

Output
4096 8e:c4:82:47:87:c2:26:4b:68:ff:96:1a:39:62:9e:4e  demo@test (RSA)

کپی کلید عمومی SSH به سرور با SSH-Copy-ID

برای کپی کلید عمومی‌تان به سرور—که به شما اجازه می‌دهد بدون رمز عبور احراز هویت کنید—رویکردهای متعددی را می‌توان گرفت.

اگر در حال حاضر دسترسی SSH مبتنی بر رمز عبور به سرورتان پیکربندی شده و ابزار ssh-copy-id نصب دارید، این فرایندی ساده است. ابزار ssh-copy-id در پکیج‌های OpenSSH بسیاری از توزیع‌های لینوکس گنجانده شده؛ پس به احتمال زیاد به‌طور پیش‌فرض نصب است.

اگر این گزینه را دارید، می‌توانید کلید عمومی‌تان را با تایپ این به‌راحتی منتقل کنید:

ssh-copy-id username@remote_host

این از شما رمز عبور حساب کاربری روی سیستم ریموت را می‌پرسد:

The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
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: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
demo@111.111.11.111's password:

بعد از تایپ رمز عبور، محتوای کلید ~/.ssh/id_rsa.pub شما به انتهای فایل ~/.ssh/authorized_keys حساب کاربری اضافه می‌شود:

Output
Number of key(s) added: 1

Now try logging into the machine, with:  "ssh 'demo@111.111.11.111'"
and check to make sure that only the key(s) you wanted were added.

حالا می‌توانید بدون رمز عبور به آن حساب وارد شوید:

ssh username@remote_host

کپی کلید عمومی به سرور بدون SSH-Copy-ID

اگر ابزار ssh-copy-id در دسترس ندارید اما همچنان دسترسی SSH مبتنی بر رمز عبور به سرور ریموت دارید، می‌توانید محتوای کلید عمومی‌تان را به روش دیگری کپی کنید.

می‌توانید محتوای کلید را خروجی و به دستور ssh پایپ کنید. در طرف ریموت، می‌توانید مطمئن شوید دایرکتوری ~/.ssh وجود دارد و سپس محتوای پایپ‌شده را به فایل ~/.ssh/authorized_keys اضافه کنید:

cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

از شما خواسته می‌شود رمز عبور حساب ریموت را ارائه دهید:

The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes
demo@111.111.11.111's password:

بعد از وارد کردن رمز عبور، کلیدتان کپی می‌شود؛ که اجازه ورود بدون رمز عبور می‌دهد:

ssh username@remote_IP_host

کپی دستی کلید عمومی به سرور

اگر دسترسی SSH مبتنی بر رمز عبور در دسترس ندارید، باید کلید عمومی‌تان را دستی به سرور ریموت اضافه کنید.

روی ماشین محلی، می‌توانید محتوای فایل کلید عمومی‌تان را با تایپ این پیدا کنید:

cat ~/.ssh/id_rsa.pub

Output
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test

می‌توانید این مقدار را کپی و دستی در مکان مناسب روی سرور ریموت پیست کنید. باید از طریق روش‌های دیگر به سرور ریموت وارد شوید (مثل کنسول وب پارمین کلود).

روی سرور ریموت، دایرکتوری ~/.ssh را بسازید اگر از قبل وجود ندارد:

mkdir -p ~/.ssh

بعد، می‌توانید فایل ~/.ssh/authorized_keys را با تایپ این بسازید یا به آن اضافه کنید:

echo public_key_string >> ~/.ssh/authorized_keys

حالا باید بتوانید بدون رمز عبور به سرور ریموت وارد شوید.

دستورالعمل‌های اتصال پایه

بخش زیر برخی مبانی درباره نحوه اتصال به سرور با SSH را پوشش می‌دهد.

اتصال به سرور ریموت

برای اتصال به یک سرور ریموت و باز کردن نشست شل آن‌جا، می‌توانید از دستور ssh استفاده کنید.

ساده‌ترین شکل فرض می‌کند که نام کاربری‌تان روی ماشین محلی همان نامی است که روی سرور ریموت است. اگر این درست است، می‌توانید با این وصل شوید:

ssh remote_host

اگر نام کاربری‌تان روی سرور ریموت متفاوت است، باید نام کاربر ریموت را مثل این پاس کنید:

ssh username@remote_host

اولین باری که به هاست جدیدی وصل می‌شوید، پیغامی شبیه این می‌بینید:

The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes

yes را تایپ کنید تا اصالت هاست ریموت را بپذیرید.

اگر از احراز هویت رمز عبور استفاده می‌کنید، اینجا از شما رمز عبور حساب ریموت پرسیده می‌شود. اگر از کلیدهای SSH استفاده می‌کنید، اگر passphrase تعیین شده باشد از شما passphrase کلید خصوصی‌تان پرسیده می‌شود؛ در غیر این صورت خودکار وارد می‌شوید.

اجرای یک دستور منفرد روی سرور ریموت

برای اجرای یک دستور منفرد روی سرور ریموت به‌جای ایجاد نشست شل، می‌توانید دستور را بعد از اطلاعات اتصال اضافه کنید؛ مثل این:

ssh username@remote_host command_to_run

این به هاست ریموت وصل، با اعتبارنامه‌های‌تان احراز هویت و دستوری را که مشخص کردید اجرا می‌کند. اتصال بعد از آن بلافاصله بسته می‌شود.

ورود به سرور با پورت متفاوت

به‌طور پیش‌فرض دیمن SSH روی سرور روی پورت ۲۲ اجرا می‌شود. کلاینت SSH شما هنگام تلاش برای اتصال فرض می‌کند این‌طور است. اگر سرور SSH شما روی پورت غیراستانداردی گوش می‌دهد، باید هنگام اتصال با کلاینت‌تان شماره پورت جدید را مشخص کنید.

این کار را با مشخص کردن شماره پورت با گزینه -p می‌توانید انجام دهید:

ssh -p port_num username@remote_host

برای اجتناب از انجام این کار در هر بار ورود به سرور ریموت‌تان، می‌توانید فایل پیکربندی‌ای در دایرکتوری ~/.ssh داخل دایرکتوری خانه کامپیوتر محلی‌تان بسازید یا ویرایش کنید.

فایل را با تایپ این الان ویرایش یا بسازید:

nano ~/.ssh/config

اینجا می‌توانید گزینه‌های پیکربندی مخصوص-هاست تعیین کنید. برای مشخص کردن پورت جدیدتان، از قالبی مثل این استفاده کنید:

~/.ssh/config
Host remote_alias
    HostName remote_host
    Port port_num

این اجازه می‌دهد بدون مشخص کردن شماره پورت خاص روی خط فرمان وارد شوید.

افزودن کلیدهای SSH به یک SSH Agent برای اجتناب از تایپ passphrase

اگر روی کلید خصوصی SSH خود passphrase دارید، هر بار که از آن برای اتصال به هاست ریموت استفاده می‌کنید، از شما خواسته می‌شود passphrase را وارد کنید.

برای اجتناب از تکرار این کار، می‌توانید یک SSH Agent اجرا کنید. این ابزار کوچک، کلید خصوصی شما را بعد از اینکه اولین بار passphrase را وارد کردید ذخیره می‌کند. برای مدت نشست ترمینال‌تان در دسترس خواهد بود؛ که اجازه می‌دهد در آینده بدون وارد کردن مجدد passphrase وصل شوید.

این اگر نیاز به فوروارد کردن اعتبارنامه‌های SSH دارید هم مهم است.

برای راه‌اندازی SSH Agent، این را در نشست ترمینال محلی‌تان تایپ کنید:

eval "$(ssh-agent -s)"

Output
Agent pid 10891

این برنامه ایجنت را راه می‌اندازد و در پس‌زمینه قرارش می‌دهد. حالا باید کلید خصوصی‌تان را به ایجنت اضافه کنید تا بتواند کلیدتان را مدیریت کند:

ssh-add

Enter passphrase for /home/demo/.ssh/id_rsa:
Identity added: /home/demo/.ssh/id_rsa (/home/demo/.ssh/id_rsa)

باید passphraseتان را (اگر تعیین شده) وارد کنید. بعد، فایل هویت‌تان به ایجنت اضافه می‌شود؛ که اجازه می‌دهد از کلیدتان برای ورود بدون نیاز به وارد کردن مجدد passphrase استفاده کنید.

فوروارد کردن اعتبارنامه‌های SSH برای استفاده روی سرور

اگر مایلید بدون رمز عبور از داخل یک سرور به سرور دیگری وصل شوید، باید اطلاعات کلید SSH خود را فوروارد کنید. این اجازه می‌دهد از طریق سروری که به آن وصل هستید، با اعتبارنامه‌های روی کامپیوتر محلی‌تان به سرور دیگری احراز هویت کنید.

برای شروع، باید SSH agentتان راه‌اندازی و کلید SSHتان به ایجنت اضافه شده باشد. بعد از این کار، باید با گزینه -A به سرور اولتان وصل شوید. این اعتبارنامه‌های‌تان را برای این نشست به سرور فوروارد می‌کند:

ssh -A username@remote_host

نکته: فوروارد ایجنت فقط باید روی سرورهای مورد اعتماد استفاده شود. یک سرور به‌خطرافتاده می‌تواند به‌طور بالقوه از اعتبارنامه‌های فورواردشده استفاده کند.

از این‌جا، می‌توانید به هر هاست دیگری که کلید SSH شما authorize شده به آن دسترسی دارد SSH بزنید. طوری وصل می‌شوید که انگار کلید خصوصی SSH شما روی همین سرور قرار دارد.

پایه پیکربندی پیش‌فرض امن SSH

قبل از اعمال سفارشی‌سازی‌های پیشرفته روی SSH، مهم است بدانید چه چیزی یک پیکربندی پیش‌فرض امن را می‌سازد. یک پایه امن، سطح افشا در برابر حملات رایج را کاهش می‌دهد و در عین حال توانایی مدیریت قابل اطمینان سیستم را حفظ می‌کند.

پیکربندی پیش‌فرض SSH ارائه‌شده توسط بیشتر توزیع‌های لینوکس، سازگاری را بر امنیت ترجیح می‌دهد. این به کاربران جدید اجازه اتصال آسان می‌دهد؛ اما روش‌های احراز هویت و الگوهای دسترسی‌ای که معمولاً سوءاستفاده می‌شوند را هم فعال می‌کند. برقراری یک پایه امن تضمین می‌کند فقط کاربران و روش‌های احراز هویتِ صریحاً مجاز، اجازه عبور داشته باشند.

در یک نگاه کلی، یک پایه امن SSH برای بیشتر سرورها باید:

• احراز هویت مبتنی بر کلید SSH را ترجیح دهد و ورودهای رمز عبور را حذف کند.
• محدود کند چه کسانی می‌توانند وارد شوند (مثلاً با محدود کردن دسترسی root و استفاده از AllowUsers / AllowGroups).
• تلاش‌های مکرر احراز هویت را محدود کند تا حملات brute-force کاهش یابند.
• ری‌استارت یا ریلود سرویس SSH را بعد از تغییرات پیکربندی الزامی کند.

بقیه این آموزش هر یک از این موارد را با جزئیات در بخش‌های پیکربندی سمت سرور مرور می‌کند. از این فهرست به‌عنوان چک‌لیست سریع استفاده و هنگام اعمال پایه روی سرور جدید به آن بخش‌ها مراجعه کنید.

احراز هویت مبتنی بر رمز عبور یکی از رایج‌ترین اهداف حملات خودکار است. حتی رمزهای عبور قوی در برابر تلاش‌های مکرر حدس زدن آسیب‌پذیرند و ممکن است بین سیستم‌ها استفاده مجدد شوند.

وقتی احراز هویت کلید SSH پیکربندی و تأیید شد، احراز هویت رمز عبور دیگر مزایای معناداری فراهم نمی‌کند. غیرفعال کردنش تضمین می‌کند همه دسترسی‌های SSH نیازمند در اختیار داشتن یک کلید خصوصی معتبر باشند.

برای غیرفعال کردن احراز هویت رمز عبور، فایل پیکربندی دیمن SSH را روی سرور با دسترسی root یا sudo باز کنید:

sudo nano /etc/ssh/sshd_config

دایرکتیو PasswordAuthentication را پیدا کنید. اگر کامنت شده، از کامنت دربیاورید و مقدار را روی no تنظیم کنید:

/etc/ssh/sshd_config
PasswordAuthentication no

این تغییر تضمین می‌کند کاربران فقط بتوانند با کلیدهای SSH تأییدشده احراز هویت شوند.

تضمین فعال بودن احراز هویت کلید عمومی

احراز هویت کلید عمومی به کلاینت‌ها اجازه می‌دهد هویت‌شان را با کلیدهای رمزنگاری اثبات کنند، نه اسرار مشترک. این روش به‌طور چشمگیری در برابر حملات شنود و حدس‌زدن مقاوم‌تر است.

هرچند احراز هویت کلید عمومی به‌طور پیش‌فرض روی بیشتر سیستم‌ها فعال است، تعریف صریحش به اجتناب از رفتار غیرمنتظره کمک می‌کند اگر فایل‌های پیکربندی بعداً تغییر کنند.

در همان فایل پیکربندی، تأیید کنید این دایرکتیو موجود است:

/etc/ssh/sshd_config
PubkeyAuthentication yes

این تضمین می‌کند احراز هویت مبتنی بر کلید SSH بعد از غیرفعال کردن ورودهای رمز عبور همچنان در دسترس بماند.

غیرفعال کردن ورود مستقیم Root

اجازه دادن دسترسی مستقیم SSH به حساب root، ریسک را افزایش و پاسخگویی را کاهش می‌دهد. در عوض، دسترسی مدیریتی باید از طریق حساب‌های کاربری غیرممتاز با دسترسی sudo انجام شود.

برای غیرفعال کردن ورود مستقیم root، دایرکتیو PermitRootLogin را پیدا و روی no تنظیم کنید:

/etc/ssh/sshd_config
PermitRootLogin no

این مدیران را مجبور می‌کند به‌عنوان کاربران منفرد احراز هویت شوند؛ که ردهای ممیزی شفاف‌تری می‌سازد و تأثیر به‌خطرافتادن اعتبارنامه را کاهش می‌دهد.

محدود کردن تلاش‌های احراز هویت و زمان ورود

به‌طور پیش‌فرض، SSH چندین تلاش احراز هویت را مجاز می‌دارد و بازه سخاوتمندانه‌ای برای تکمیل ورود فراهم می‌کند. این کاربردپذیری را بهبود می‌دهد اما به مهاجمان فرصت‌های بیشتری برای حدس زدن اعتبارنامه یا تست کلیدها می‌دهد.

محدود کردن تعداد تلاش‌های احراز هویت، اثربخشی تلاش‌های مکرر ورود را کاهش می‌دهد. کاهش دوره بخشش ورود (Login Grace Period) محدود می‌کند اتصالات احراز-نشده چقدر می‌توانند باز بمانند.

این دایرکتیوها را اضافه یا تنظیم کنید:

/etc/ssh/sshd_config
MaxAuthTries 3
LoginGraceTime 30

این تنظیمات تعداد تلاش‌های ناموفق به ازای اتصال را محدود و زمان مجاز برای احراز هویت را کوتاه می‌کنند.

کنترل صریح اینکه کدام کاربران می‌توانند وصل شوند

روی بسیاری از سیستم‌ها، هر حساب کاربری محلی به‌طور پیش‌فرض می‌تواند روی SSH تلاش اتصال کند. این رفتار در بیشتر محیط‌ها غیرضروری است و سطح افشا را افزایش می‌دهد.

تعریف صریح اینکه کدام کاربران یا گروه‌ها مجاز به اتصال‌اند تضمین می‌کند فقط حساب‌های موردنظر بتوانند از SSH استفاده کنند؛ حتی اگر کاربران سیستم اضافی وجود داشته باشند.

این کار را با دایرکتیو AllowUsers یا AllowGroups می‌توانید انجام دهید. مثلاً:

/etc/ssh/sshd_config
AllowUsers demo admin

به‌عنوان جایگزین، دسترسی را می‌توان با دایرکتیو AllowGroups از طریق گروه‌ها کنترل کرد. هر دو رویکرد تعداد حساب‌هایی که می‌توانند تلاش احراز هویت SSH کنند را کاهش می‌دهند.

اعمال امن تغییرات

بعد از اعمال تغییرات روی فایل پیکربندی SSH، سرویس SSH را برای اعمالشان ری‌استارت کنید.

روی سیستم‌های مبتنی بر اوبونتو و دبیان:

sudo systemctl restart ssh

روی سیستم‌های مبتنی بر CentOS و فدورا:

sudo systemctl restart sshd

قبل از بستن نشست فعلی‌تان، یک پنجره ترمینال جدید باز کنید و تأیید کنید که همچنان می‌توانید با کلیدهای SSH وارد شوید. باز نگه‌داشتن یک نشست فعال حین تست، به جلوگیری از قفل شدن تصادفی کمک می‌کند.

برقراری یک پایه قوی

این تنظیمات نقطه شروع امنی برای بیشتر دیپلوی‌های SSH می‌سازند. هاردنینگ اضافی می‌تواند بر اساس الزامات خاص اعمال شود؛ اما یک پایه خوش‌تعریف تضمین می‌کند مسیرهای دسترسی غیرضروری زود بسته شوند.

با پیکربندی SSH برای استفاده از احراز هویت مبتنی بر کلید، محدود کردن دسترسی ممتاز و محدود کردن رفتار احراز هویت، سطح حمله را کاهش و در عین حال دسترسی مدیریتی قابل اطمینان را حفظ می‌کنید.

گزینه‌های پیکربندی سمت سرور

این بخش شامل برخی گزینه‌های رایج پیکربندی سمت سرور است که می‌توانند نحوه پاسخ سرورتان و انواع اتصالات مجاز را شکل دهند.

غیرفعال کردن احراز هویت رمز عبور

اگر کلیدهای SSH پیکربندی، تست و درست کار کرده‌اند، احتمالاً خوب است احراز هویت رمز عبور را غیرفعال کنید. این جلوی ورود هر کاربری با SSH با رمز عبور را می‌گیرد.

برای این کار، به سرور ریموت‌تان وصل و فایل /etc/ssh/sshd_config را با دسترسی root یا sudo باز کنید:

sudo nano /etc/ssh/sshd_config

داخل فایل، دایرکتیو PasswordAuthentication را جستجو کنید. اگر کامنت شده، از کامنت دربیاورید. برای غیرفعال کردن ورودهای رمز عبور، روی no تنظیمش کنید:

/etc/ssh/sshd_config
PasswordAuthentication no

بعد از اعمال تغییر، فایل را ذخیره و ببندید. برای پیاده‌سازی تغییرات، باید سرویس SSH را ری‌استارت کنید.

روی اوبونتو/دبیان:

sudo systemctl restart ssh

روی CentOS/فدورا:

sudo systemctl restart sshd

حالا، همه حساب‌های سیستم قادر به ورود با SSH با رمز عبور نخواهند بود.

تغییر پورتی که دیمن SSH رویش اجرا می‌شود

برخی مدیران پیشنهاد می‌کنند پورت پیش‌فرضی را که SSH رویش اجرا می‌شود تغییر دهید. این می‌تواند به کاهش تعداد تلاش‌های احراز هویتی که سرورتان از بات‌های خودکار متحمل می‌شود کمک کند.

برای تغییر پورت دیمن SSH، باید به سرور ریموت‌تان وارد شوید. فایل sshd_config را روی سیستم ریموت با دسترسی‌های root باز کنید؛ یا با ورود با آن کاربر یا با استفاده از sudo:

sudo nano /etc/ssh/sshd_config

وقتی داخل شدید، می‌توانید با پیدا کردن مشخصه Port 22 و تغییرش به پورتی که می‌خواهید استفاده کنید، پورت SSH را تغییر دهید. مثلاً برای تغییر پورت به 4444، این را در فایل‌تان بگذارید:

/etc/ssh/sshd_config
#Port 22
Port 4444

وقتی تمام شد، فایل را ذخیره و ببندید. برای پیاده‌سازی تغییرات، باید دیمن SSH را ری‌استارت کنید.

روی اوبونتو/دبیان:

sudo systemctl restart ssh

روی CentOS/فدورا:

sudo systemctl restart sshd

نکته: تغییر پورت SSH می‌تواند نویز اسکن خودکار را کاهش دهد؛ اما نباید به‌عنوان اقدام امنیتی اصلی به آن تکیه کرد. کنترل‌های احراز هویت درست و قوانین فایروال بسیار مهم‌ترند.

بعد از ری‌استارت دیمن، باید با مشخص کردن شماره پورت احراز هویت کنید (که در بخش قبلی نمایش داده شد).

محدود کردن کاربرانی که می‌توانند از طریق SSH وصل شوند

برای محدود کردن صریح حساب‌های کاربری‌ای که قادر به ورود از طریق SSH هستند، می‌توانید چند رویکرد متفاوت بگیرید؛ که هر کدام شامل ویرایش فایل پیکربندی دیمن SSH است.

روی سرور ریموت‌تان، این فایل را با دسترسی root یا sudo باز کنید:

sudo nano /etc/ssh/sshd_config

اولین روش مشخص کردن حساب‌های مجاز به ورود، استفاده از دایرکتیو AllowUsers است. اگر وجود ندارد، در هر جایی بسازید. بعد از دایرکتیو، حساب‌های کاربری‌ای را که باید مجاز به ورود باشند فهرست کنید:

/etc/ssh/sshd_config
AllowUsers user1 user2

فایل را ذخیره و ببندید. برای پیاده‌سازی تغییرات‌تان، دیمن را ری‌استارت کنید.

روی اوبونتو/دبیان:

sudo systemctl restart ssh

روی CentOS/فدورا:

sudo systemctl restart sshd

اگر با مدیریت گروه راحت‌تر هستید، می‌توانید به‌جای آن از دایرکتیو AllowGroups استفاده کنید. اگر این‌طور است، فقط گروهی را که باید دسترسی SSH داشته باشد اضافه کنید:

/etc/ssh/sshd_config
AllowGroups sshmembers

فایل را ذخیره و ببندید.

حالا، می‌توانید با تایپ این، گروه سیستمی (بدون دایرکتوری خانه) منطبق با گروهی که مشخص کردید بسازید:

sudo groupadd -r sshmembers

مطمئن شوید هر حساب کاربری‌ای را که لازم دارید به این گروه اضافه کنید:

sudo usermod -a -G sshmembers user1
sudo usermod -a -G sshmembers user2

حالا برای پیاده‌سازی تغییرات‌تان، دیمن SSH را ری‌استارت کنید.

روی اوبونتو/دبیان:

sudo systemctl restart ssh

روی CentOS/فدورا:

sudo systemctl restart sshd

غیرفعال کردن ورود Root

اغلب توصیه می‌شود بعد از راه‌اندازی حساب کاربری SSH‌ای که دسترسی sudo دارد، ورود root از طریق SSH را کاملاً غیرفعال کنید.

برای این کار، فایل پیکربندی دیمن SSH را با root یا sudo روی سرور ریموت‌تان باز کنید:

sudo nano /etc/ssh/sshd_config

داخل، دایرکتیوی به نام PermitRootLogin را جستجو کنید. اگر کامنت است، از کامنت دربیاورید. مقدار را به «no» تغییر دهید:

/etc/ssh/sshd_config
PermitRootLogin no

فایل را ذخیره و ببندید. برای پیاده‌سازی تغییرات‌تان، دیمن SSH را ری‌استارت کنید.

روی اوبونتو/دبیان:

sudo systemctl restart ssh

روی CentOS/فدورا:

sudo systemctl restart sshd

اجازه دسترسی Root برای دستورات خاص

مواردی هست که ممکن است بخواهید دسترسی root را عموماً غیرفعال کنید اما برای اجرای درست برخی اپلیکیشن‌ها فعالش کنید. مثالی از این می‌تواند روتین بکاپ باشد.

هشدار: دستورات اجباری اجراشده به‌عنوان root باید به‌ندرت استفاده و بادقت ممیزی شوند. تا جای ممکن، استفاده از کاربر غیرممتاز اختصاصی با دسترسی‌های sudo محدود به دستور موردنیاز را ترجیح دهید.

این کار از طریق فایل authorized_keys کاربر root قابل انجام است؛ که شامل کلیدهای SSH‌ای است که authorize شده‌اند از این حساب استفاده کنند.

کلیدِ از کامپیوتر محلی‌تان را که می‌خواهید برای این فرایند استفاده کنید (توصیه می‌کنیم برای هر فرایند خودکار، کلید جدیدی بسازید) به فایل authorized_keys کاربر root روی سرور اضافه کنید. اینجا با دستور ssh-copy-id نمایش می‌دهیم؛ اما می‌توانید از هر کدام از روش‌های کپی کلید که در بخش‌های دیگر بحث می‌کنیم استفاده کنید:

ssh-copy-id root@remote_host

حالا به سرور ریموت وارد شوید. باید ورودی فایل authorized_keys را تنظیم کنیم؛ پس آن را با دسترسی root یا sudo باز کنید:

sudo nano /root/.ssh/authorized_keys

در ابتدای خطِ با کلیدی که آپلود کردید، یک command= اضافه کنید که دستوری را که این کلید برایش معتبر است تعریف می‌کند. این باید شامل مسیر کامل فایل اجرایی به‌همراه هر آرگومانی باشد:

/root/.ssh/authorized_keys
command="/path/to/command arg1 arg2" ssh-rsa ...

وقتی تمام شد، فایل را ذخیره و ببندید.

حالا فایل sshd_config را با دسترسی‌های root یا sudo باز کنید:

sudo nano /etc/ssh/sshd_config

دایرکتیو PermitRootLogin را پیدا و مقدار را به forced-commands-only تغییر دهید. این فقط اجازه می‌دهد ورودهای کلید SSH از root وقتی استفاده شوند که دستوری برای کلید مشخص شده باشد:

/etc/ssh/sshd_config
PermitRootLogin forced-commands-only

فایل را ذخیره و ببندید. برای پیاده‌سازی تغییرات‌تان، دیمن SSH را ری‌استارت کنید.

روی اوبونتو/دبیان:

sudo systemctl restart ssh

روی CentOS/فدورا:

sudo systemctl restart sshd

فوروارد کردن نمایش اپلیکیشن‌های X به کلاینت

دیمن SSH را می‌توان طوری پیکربندی کرد که نمایش اپلیکیشن‌های X روی سرور را خودکار به ماشین کلاینت فوروارد کند. برای کار کردن درست این، کلاینت باید X server نصب و در حال اجرا داشته باشد و سرور ممکن است برای کارکرد درست فورواردینگ X11 به پکیج xauth نیاز داشته باشد.

برای فعال کردن این قابلیت، به سرور ریموت‌تان وارد و فایل sshd_config را به‌عنوان root یا با دسترسی sudo ویرایش کنید:

sudo nano /etc/ssh/sshd_config

دایرکتیو X11Forwarding را جستجو کنید. اگر کامنت شده، از کامنت دربیاورید. در صورت لزوم بسازید و مقدار را روی «yes» تنظیم کنید:

/etc/ssh/sshd_config
X11Forwarding yes

فایل را ذخیره و ببندید. برای پیاده‌سازی این تغییرات، دیمن SSH را ری‌استارت کنید.

روی اوبونتو/دبیان:

sudo systemctl restart ssh

روی CentOS/فدورا:

sudo systemctl restart sshd

برای اتصال به سرور و فوروارد کردن نمایش یک اپلیکیشن، باید از کلاینت هنگام اتصال گزینه -X را پاس کنید:

ssh -X username@remote_host

اپلیکیشن‌های گرافیکی که روی سرور از طریق این نشست شروع شوند باید روی کامپیوتر محلی نمایش داده شوند. کارایی ممکن است کمی کند باشد؛ اما در مواقع ضروری بسیار مفید است.

گزینه‌های پیکربندی سمت کلاینت

در بخش بعد، روی برخی تنظیماتی که می‌توانید در سمت کلاینت اتصال بدهید تمرکز می‌کنیم.

تعریف اطلاعات اتصال مخصوص-سرور

روی کامپیوتر محلی‌تان، می‌توانید پیکربندی‌های منفردی برای برخی یا همه سرورهایی که به آن‌ها وصل می‌شوید تعریف کنید. این‌ها را می‌توان در فایل ~/.ssh/config ذخیره کرد؛ که هر بار فراخوانی، توسط کلاینت SSH شما خوانده می‌شود.

این فایل را در ویرایشگر متن روی کامپیوتر محلی‌تان بسازید یا باز کنید:

nano ~/.ssh/config

داخل، می‌توانید گزینه‌های پیکربندی منفرد را با معرفی هر کدام با کلیدواژه Host و به‌دنبالش یک نام مستعار (Alias) تعریف کنید. زیر آن و با تورفتگی، می‌توانید هر کدام از دایرکتیوهای موجود در صفحه راهنمای ssh_config را تعریف کنید:

man ssh_config

یک پیکربندی نمونه:

~/.ssh/config
Host testhost
    HostName your_domain
    Port 4444
    User demo

سپس می‌توانید با تایپ ساده این، به your_domain روی پورت ۴۴۴۴ با نام کاربری demo وصل شوید:

ssh testhost

همچنین می‌توانید از وایلدکارت برای تطبیق بیش از یک هاست استفاده کنید. در نظر داشته باشید که تطابق‌های بعدی می‌توانند قبلی‌ها را بازنویسی کنند. به همین دلیل، باید خاص‌ترین تطابق‌های‌تان را در بالا بگذارید. مثلاً می‌توانید همه اتصالات را به‌طور پیش‌فرض فوروارد X را مجاز ندانید؛ با یک بازنویسی برای your_domain با داشتن این در فایل‌تان:

~/.ssh/config
Host *
    ForwardX11 no

Host testhost
    HostName your_domain
    ForwardX11 yes
    Port 4444
    User demo

وقتی تمام شد، فایل را ذخیره و ببندید.

زنده نگه‌داشتن اتصالات برای اجتناب از تایم‌اوت

اگر قبل از اینکه آماده باشید از نشست‌های SSH قطع می‌شوید، ممکن است اتصال‌تان تایم‌اوت شود.

می‌توانید کلاینت‌تان را طوری پیکربندی کنید که هر از گاهی یک بسته به سرور بفرستد تا از این وضعیت اجتناب شود:

روی کامپیوتر محلی‌تان، می‌توانید این را برای هر اتصال با ویرایش فایل ~/.ssh/config پیکربندی کنید:

nano ~/.ssh/config

اگر بخشی که با همه هاست‌ها مطابقت یابد از قبل وجود ندارد، در بالای فایل یکی اضافه کنید. ServerAliveInterval را روی «120» تنظیم کنید تا هر دو دقیقه یک بسته به سرور فرستاده شود:

~/.ssh/config
Host *
    ServerAliveInterval 120

وقتی تمام شد، فایل را ذخیره و ببندید.

غیرفعال کردن بررسی هاست

به‌طور پیش‌فرض، هر بار به سرور جدیدی وصل می‌شوید، اثر انگشت کلید هاست دیمن SSH ریموت به شما نشان داده می‌شود:

The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes

این طوری پیکربندی شده که بتوانید اصالت هاستی را که سعی در اتصال به آن دارید تأیید کنید و مواردی را که کاربر مخربی ممکن است سعی کند خودش را به‌عنوان هاست ریموت جا بزند شناسایی نمایید.

در شرایط خاصی، ممکن است بخواهید این قابلیت را غیرفعال کنید.

نکته: این می‌تواند ریسک امنیتی بزرگی باشد؛ پس اگر سیستم‌تان را این‌طور راه می‌اندازید مطمئن شوید می‌دانید چه می‌کنید.

برای اعمال تغییر، فایل ~/.ssh/config روی کامپیوتر محلی‌تان را باز کنید:

nano ~/.ssh/config

اگر بخش هاست-همگانی از قبل وجود ندارد، در بالای فایل اضافه کنید. دایرکتیو StrictHostKeyChecking را روی no تنظیم کنید تا هاست‌های جدید خودکار به فایل known_hosts اضافه شوند. UserKnownHostsFile را روی /dev/null تنظیم کنید تا روی هاست‌های جدید یا تغییرکرده هشدار داده نشود:

~/.ssh/config
Host *
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null

می‌توانید بررسی را مورد-به-مورد با معکوس کردن این گزینه‌ها برای هاست‌های دیگر فعال کنید. پیش‌فرض StrictHostKeyChecking مقدار ask است:

~/.ssh/config
Host *
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null

Host testhost
    HostName your_domain
    StrictHostKeyChecking ask
    UserKnownHostsFile /home/demo/.ssh/known_hosts

مولتی‌پلکس کردن SSH روی یک اتصال TCP منفرد

مواقعی هست که برقراری اتصال TCP جدید می‌تواند بیشتر از آنچه دوست دارید طول بکشد. اگر چندین اتصال به همان ماشین می‌سازید، می‌توانید از مولتی‌پلکسینگ بهره ببرید.

مولتی‌پلکسینگ SSH از همان اتصال TCP برای چندین نشست SSH استفاده مجدد می‌کند. این بخشی از کارِ لازم برای برقراری نشست جدید را حذف و ممکن است کارها را سریع‌تر می‌کند. محدود کردن تعداد اتصالات ممکن است به دلایل دیگر هم مفید باشد.

برای راه‌اندازی مولتی‌پلکسینگ، می‌توانید اتصالات را دستی راه بیندازید یا کلاینت‌تان را طوری پیکربندی کنید که هنگام موجود بودن، خودکار از مولتی‌پلکسینگ استفاده کند. اینجا گزینه دوم را نمایش می‌دهیم.

برای پیکربندی مولتی‌پلکسینگ، فایل پیکربندی کلاینت SSH را روی ماشین محلی ویرایش کنید:

nano ~/.ssh/config

اگر هنوز تعریف هاست وایلدکارت در بالای فایل ندارید، الان یکی اضافه کنید (به‌صورت Host *). مقادیر ControlMaster، ControlPath و ControlPersist را برای برقراری پیکربندی مولتی‌پلکسینگ تنظیم می‌کنیم.

ControlMaster باید روی auto تنظیم شود تا در صورت امکان، خودکار مولتی‌پلکسینگ مجاز باشد. ControlPath مسیر سوکت کنترل را برقرار می‌کند. اولین نشست این سوکت را می‌سازد و نشست‌های بعدی می‌توانند آن را پیدا کنند؛ چون با نام کاربری، هاست و پورت برچسب‌گذاری شده.

تنظیم گزینه ControlPersist روی ۱ اجازه می‌دهد اتصال اصلیِ master در پس‌زمینه قرار بگیرد. عدد ۱ مشخص می‌کند اتصال TCP باید یک ثانیه بعد از بسته شدن آخرین نشست SSH خودکار خاتمه یابد:

~/.ssh/config
Host *
    ControlMaster auto
    ControlPath ~/.ssh/multiplex/%r@%h:%p
    ControlPersist 1

وقتی تمام شد، فایل را ذخیره و ببندید. حالا باید دایرکتوری‌ای را که در مسیر کنترل مشخص کردیم واقعاً بسازیم:

mkdir ~/.ssh/multiplex

حالا، هر نشستی که با همان ماشین برقرار شود تلاش می‌کند از سوکت موجود و اتصال TCP استفاده کند. وقتی آخرین نشست خارج شود، اتصال بعد از یک ثانیه پایین کشیده می‌شود.

اگر به هر دلیلی لازم شد موقتاً از پیکربندی مولتی‌پلکسینگ عبور کنید، می‌توانید با پاس دادن فلگ -S با مقدار none این کار را بکنید:

ssh -S none username@remote_host

راه‌اندازی تونل‌های SSH

تونل‌سازی ترافیک دیگر از طریق یک تونل امن SSH، راهی عالی برای دور زدن تنظیمات محدودکننده فایروال است. همچنین راهی عالی برای رمزنگاری ترافیک شبکه‌ای که در غیر این صورت بدون رمزنگاری است.

پیکربندی تونل‌سازی محلی به سرور

اتصالات SSH را می‌توان برای تونل‌سازی ترافیک از پورت‌های هاست محلی به پورت‌های هاست ریموت استفاده کرد.

یک اتصال محلی، راهی برای دسترسی به یک مکان شبکه از کامپیوتر محلی‌تان از طریق هاست ریموت‌تان است. اول، یک اتصال SSH به هاست ریموت‌تان برقرار می‌شود. روی سرور ریموت، اتصالی به آدرس شبکه خارجی (یا داخلی) ارائه‌شده توسط کاربر ساخته می‌شود و ترافیک به این مکان، به کامپیوتر محلی شما روی پورت مشخصی تونل می‌شود.

این اغلب برای تونل‌زدن به محیط شبکه‌ای کمتر محدود با دور زدن فایروال استفاده می‌شود. کاربرد رایج دیگر، دسترسی به رابط وب «فقط-localhost» از مکان ریموت است.

برای برقراری تونل محلی به سرور ریموت‌تان، باید هنگام اتصال از پارامتر -L استفاده و سه قطعه اطلاعات اضافی ارائه دهید:

• پورت محلی که می‌خواهید به اتصال تونل‌شده دسترسی داشته باشید.
• هاستی که می‌خواهید هاست ریموت‌تان به آن وصل شود.
• پورتی که می‌خواهید هاست ریموت‌تان روی آن وصل شود.

این‌ها به‌ترتیب بالا (جدا شده با دونقطه)، به‌عنوان آرگومان فلگ -L داده می‌شوند. همچنین از فلگ -f استفاده می‌کنیم که باعث می‌شود SSH قبل از اجرا به پس‌زمینه برود و فلگ -N که روی طرف ریموت، شل باز یا برنامه‌ای اجرا نمی‌کند.

مثلاً برای اتصال به your_domain روی پورت ۸۰ روی هاست ریموت‌تان، با در دسترس قرار دادن اتصال روی ماشین محلی‌تان روی پورت ۸۸۸۸، می‌توانستید تایپ کنید:

ssh -f -N -L 8888:your_domain:80 username@remote_host

حالا اگر مرورگر محلی‌تان را به 127.0.0.1:8888 اشاره کنید، باید هر محتوایی که در your_domain روی پورت ۸۰ است را ببینید.

راهنمای عمومی‌تر سینتکس:

ssh -L your_port:site_or_IP_to_access:site_port username@host

چون اتصال در پس‌زمینه است، باید PID آن را برای کشتنش پیدا کنید. این کار را با جستجوی پورتی که فوروارد کردید می‌توانید انجام دهید:

ps aux | grep 8888

Output
1001      5965  0.0  0.0  48168  1136 ?        Ss   12:28   0:00 ssh -f -N -L 8888:your_domain:80 username@remote_host
1001      6113  0.0  0.0  13648   952 pts/2    S+   12:37   0:00 grep --colour=auto 8888

سپس می‌توانید پروسه را با هدف‌گیری PID—که عدد در ستون دوم خطِ منطبق با دستور SSH شماست—بکشید:

kill 5965

گزینه دیگر، شروع اتصال بدون فلگ -f است. این اتصال را در پیش‌زمینه نگه می‌دارد و مانع استفاده از پنجره ترمینال برای مدت فوروarding می‌شود. مزیتش این است که می‌توانید تونل را با تایپ CTRL-C راحت بکشید.

پیکربندی تونل‌سازی ریموت به سرور

در تونل ریموت، اتصالی به هاست ریموت برقرار می‌شود. حین ساخت تونل، پورت ریموتی مشخص می‌شود. این پورت روی هاست ریموت، سپس به ترکیب هاست و پورتی که از کامپیوتر محلی به آن وصل شده، تونل می‌شود. این اجازه می‌دهد کامپیوتر ریموت به هاستی از طریق کامپیوتر محلی شما دسترسی داشته باشد.

این می‌تواند مفید باشد اگر لازم است دسترسی به شبکه داخلی‌ای را که برای اتصالات خارجی قفل شده مجاز کنید. اگر فایروال اتصالات خروج از شبکه را مجاز بداند، این اجازه می‌دهد به ماشین ریموتی خارج شوید و ترافیک آن ماشین را به مکانی روی شبکه داخلی تونل کنید.

برای برقراری تونل ریموت به سرور ریموت‌تان، باید هنگام اتصال از پارامتر -R استفاده و سه قطعه اطلاعات اضافی ارائه دهید:

• پورتی که هاست ریموت می‌تواند به اتصال تونل‌شده دسترسی داشته باشد.
• هاستی که می‌خواهید کامپیوتر محلی‌تان به آن وصل شود.
• پورتی که می‌خواهید کامپیوتر محلی‌تان به آن وصل شود.

این‌ها به‌ترتیب بالا (جدا شده با دونقطه)، به‌عنوان آرگومان فلگ -R داده می‌شوند. همچنین از فلگ -f (پس‌زمینه) و فلگ -N (بدون شل) استفاده می‌کنیم.

مثلاً برای اتصال به your_domain روی پورت ۸۰ روی کامپیوتر محلی‌مان، با در دسترس قرار دادن اتصال روی هاست ریموتمان روی پورت ۸۸۸۸، می‌توانستید تایپ کنید:

ssh -f -N -R 8888:your_domain:80 username@remote_host

حالا روی هاست ریموت، باز کردن مرورگر وب به 127.0.0.1:8888 اجازه می‌دهد هر محتوایی که در your_domain روی پورت ۸۰ است را ببینید.

راهنمای عمومی‌تر سینتکس:

ssh -R remote_port:site_or_IP_to_access:site_port username@host

چون اتصال در پس‌زمینه است، باید PID آن را برای کشتنش پیدا کنید. این کار را با جستجوی پورتی که فوروارد کردید می‌توانید انجام دهید:

ps aux | grep 8888

Output
1001      5965  0.0  0.0  48168  1136 ?        Ss   12:28   0:00 ssh -f -N -R 8888:your_domain:80 username@remote_host
1001      6113  0.0  0.0  13648   952 pts/2    S+   12:37   0:00 grep --colour=auto 8888

سپس می‌توانید پروسه را با هدف‌گیری PID بکشید:

kill 5965

گزینه دیگر، شروع اتصال بدون فلگ -f است. این اتصال را در پیش‌زمینه نگه می‌دارد و مزیتش این است که می‌توانید تونل را با تایپ CTRL-C راحت بکشید.

پیکربندی تونل‌سازی داینامیک به سرور ریموت

تونل داینامیک شبیه تونل محلی است در اینکه اجازه می‌دهد کامپیوتر محلی از طریق هاست ریموت به منابع دیگر وصل شود. تونل داینامیک این کار را با ساده‌ترین شکل—مشخص کردن یک پورت محلی منفرد—انجام می‌دهد. اپلیکیشن‌هایی که می‌خواهند از این پورت برای تونل‌سازی بهره ببرند باید بتوانند با پروتکل SOCKS ارتباط برقرار کنند تا بسته‌ها در طرف دیگر تونل به‌درستی ریدایرکت شوند.

ترافیکی که به این پورت محلی پاس داده می‌شود به هاست ریموت فرستاده خواهد شد. از آن‌جا، پروتکل SOCKS برای برقراری اتصال به مکان نهایی موردنظر تفسیر می‌شود. این راه‌اندازی اجازه می‌دهد اپلیکیشنِ SOCKS-توانمند به هر تعداد مکان از طریق سرور ریموت وصل شود؛ بدون تونل‌های استاتیک متعدد.

برای برقراری اتصال، فلگ -D را همراه پورت محلی‌ای که می‌خواهیم به تونل دسترسی داشته باشیم پاس می‌دهیم. همچنین از فلگ -f (پس‌زمینه) و فلگ -N (بدون شل) استفاده می‌کنیم.

مثلاً برای برقراری تونل روی پورت ۷۷۷۷، می‌توانید تایپ کنید:

ssh -f -N -D 7777 username@remote_host

از این‌جا، می‌توانید اشاره کردن اپلیکیشن SOCKS-آگاه‌تان (مثل مرورگر وب) به پورتی که انتخاب کردید را شروع کنید. اپلیکیشن اطلاعات‌اش را به سوکتی مرتبط با پورت می‌فرستد.

روش هدایت ترافیک به پورت SOCKS بسته به اپلیکیشن متفاوت است. مثلاً در فایرفاکس، مکان عمومی Preferences > Advanced > Settings > Manual proxy configurations است. در کروم، می‌توانید اپلیکیشن را با فلگ --proxy-server= تنظیم‌شده شروع کنید. می‌خواهید از اینترفیس localhost و پورتی که فوروارد کردید استفاده کنید.

چون اتصال در پس‌زمینه است، باید PID آن را برای کشتنش پیدا کنید. این کار را با جستجوی پورتی که فوروارد کردید می‌توانید انجام دهید:

ps aux | grep 8888

Output
1001       5965  0.0  0.0  48168  1136 ?        Ss   12:28   0:00  ssh -f -N -D 7777 username@remote_host
1001      6113  0.0  0.0  13648   952 pts/2    S+   12:37   0:00  grep --colour=auto 8888

سپس می‌توانید پروسه را با هدف‌گیری PID بکشید:

kill 5965

گزینه دیگر، شروع اتصال بدون فلگ -f است. این اتصال را در پیش‌زمینه نگه می‌دارد و مانع استفاده از ترمینال برای مدت فوروarding می‌شود. مزیتش این است که می‌توانید تونل را با تایپ CTRL-C راحت بکشید.

---

استفاده از کدهای فرار (Escape Codes) SSH برای کنترل اتصالات

حتی بعد از برقراری نشست SSH، امکان کنترل اتصال از داخل ترمینال وجود دارد. این کار را می‌توان با چیزی به نام کدهای فرار (Escape Codes) SSH انجام داد؛ که به ما اجازه می‌دهد از داخل یک نشست، با نرم‌افزار SSH محلی‌مان تعامل کنیم.

اجبار به قطع اتصال از سمت کلاینت (نحوه خروج از نشست گیرکرده یا فریزشده)

یکی از مفیدترین قابلیت‌های OpenSSH که عمدتاً unnoticed می‌ماند، توانایی کنترل برخی جنبه‌های نشست از داخل است.

این دستورات با کاراکتر کنترلی ~ داخل نشست SSH اجرا می‌شوند. دستورات کنترلی فقط وقتی تفسیر می‌شوند که اولین چیزی باشند که بعد از یک خط جدید (Newline) تایپ می‌شود؛ پس همیشه قبل از استفاده از یکی، یک یا دو بار ENTER را فشار دهید.

یکی از مفیدترین کنترل‌ها، توانایی شروع قطع اتصال از کلاینت است. اتصالات SSH معمولاً توسط سرور بسته می‌شوند؛ اما این می‌تواند مشکل‌ساز باشد اگر سرور دچار مشکل باشد یا اتصال قطع شده باشد. با استفاده از قطع اتصال سمت کلاینت، اتصال می‌تواند به‌شکل تمیز از سمت کلاینت بسته شود.

برای بستن اتصال از کلاینت، از کاراکتر کنترلی (~) به‌همراه یک نقطه استفاده کنید. اگر اتصال‌تان مشکل دارد، احتمالاً در چیزی شبیه یک نشست ترمینالِ گیرکرده هستید. دستورات را با وجود نبود بازخورد تایپ کنید تا قطع اتصال سمت کلاینت انجام شود:

[ENTER]
~.

اتصال باید بلافاصله بسته شود و به نشست شل محلی‌تان برگردانید.

قرار دادن نشست SSH در پس‌زمینه

یکی از مفیدترین قابلیت‌های OpenSSH که عمدتاً نادیده گرفته می‌شود، توانایی کنترل برخی جنبه‌های نشست از داخل اتصال است.

این دستورات را می‌توان با شروع از کاراکتر کنترلی ~ از داخل اتصال SSH اجرا کرد. دستورات کنترلی فقط وقتی تفسیر می‌شوند که اولین چیزی باشند که بعد از یک خط جدید تایپ می‌شود؛ پس همیشه قبل از استفاده از یکی، یک یا دو بار ENTER را فشار دهید.

یک قابلیتی که این کار فراهم می‌کند، قرار دادن نشست SSH در پس‌زمینه است. برای این کار، باید کاراکتر کنترلی (~) را ارائه و سپس میان‌بر کیبورد معمولِ پس‌زمینه‌کردن یک کار را (CTRL-z) اجرا کنیم:

[ENTER]
~[CTRL-z]

این اتصال را در پس‌زمینه قرار می‌دهد و به نشست شل محلی‌تان برمی‌گردانید. برای بازگشت به نشست SSH‌تان، می‌توانید از سازوکارهای معمول کنترل کار (Job Control) استفاده کنید.

می‌توانید جدیدترین کار پس‌زمینه‌تان را با تایپ این فوراً دوباره فعال کنید:

fg

اگر چند کار پس‌زمینه دارید، می‌توانید کارهای موجود را با تایپ این ببینید:

jobs

Output
[1]+  Stopped                 ssh username@some_host
[2]   Stopped                 ssh username@another_host

سپس می‌توانید هر کدام از کارها را با استفاده از اندیس در ستون اول به‌همراه علامت درصد، به پیش‌زمینه بیاورید:

fg %2

تغییر گزینه‌های فوروارد پورت روی اتصال SSH موجود

یکی از مفیدترین قابلیت‌های OpenSSH که عمدتاً نادیده گرفته می‌شود، توانایی کنترل برخی جنبه‌های نشست از داخل اتصال است.

این دستورات را می‌توان با شروع از کاراکتر کنترلی ~ از داخل اتصال SSH اجرا کرد. دستورات کنترلی فقط وقتی تفسیر می‌شوند که اولین چیزی باشند که بعد از یک خط جدید تایپ می‌شود؛ پس همیشه قبل از استفاده از یکی، یک یا دو بار ENTER را فشار دهید.

چیزی که این کار اجازه می‌دهد این است که کاربر بتواند پیکربندی فوروارد پورت را بعد از برقراری اتصال تغییر دهد. این اجازه می‌دهد قوانین فوروارد پورت را در لحظه (On-the-Fly) بسازید یا پایین بکشید.

این قابلیت‌ها بخشی از رابط خط فرمان SSH هستند؛ که می‌توان در طول نشست با استفاده از کاراکتر کنترلی (~) و «C» به آن‌ها دسترسی پیدا کرد:

[ENTER]
~C
ssh>

یک پرامپت فرمان SSH به شما داده می‌شود؛ که مجموعه بسیار محدودی از دستورات معتبر دارد. برای دیدن گزینه‌های موجود، می‌توانید از این پرامپت -h را تایپ کنید. اگر چیزی برگردانده نشد، ممکن است لازم باشد میزان تفصیل خروجی SSHتان را با چند بار استفاده از ~v افزایش دهید:

[ENTER]
~v
~v
~v
~C
-h

Commands:
      -L[bind_address:]port:host:hostport    Request local forward
      -R[bind_address:]port:host:hostport    Request remote forward
      -D[bind_address:]port                  Request dynamic forward
      -KL[bind_address:]port                 Cancel local forward
      -KR[bind_address:]port                 Cancel remote forward
      -KD[bind_address:]port                 Cancel dynamic forward

همان‌طور که می‌بینید، می‌توانید به‌راحتی هر کدام از گزینه‌های فورواردینگ را با استفاده از گزینه‌های مناسب پیاده‌سازی کنید (برای اطلاعات بیشتر، بخش فورواردینگ را ببینید). همچنین می‌توانید یک تونل را با دستور «کشتنِ» مرتبط که با «K» قبل از حرف نوع فوروارد مشخص می‌شود، نابود کنید. مثلاً برای کشتن یک فوروارد محلی (-L)، می‌توانید از دستور -KL استفاده کنید. فقط باید پورت را برای این کار ارائه دهید.

پس، برای راه‌اندازی یک فوروارد پورت محلی، می‌توانید تایپ کنید:

[ENTER]
~C
-L 8888:127.0.0.1:80

پورت ۸۸۸۸ روی کامپیوتر محلی‌تان حالا قادر خواهد بود با وب‌سرورِ هاستی که به آن وصل می‌شوید ارتباط برقرار کند. وقتی کارتان تمام شد، می‌توانید آن فوروارد را با تایپ این پایین بکشید:

[ENTER]
~C
-KL 8888

عیب‌یابی خطاهای رایج SSH

حتی با یک راه‌اندازی درست SSH، مشکلات اتصال می‌توانند به‌دلیل تغییرات پیکربندی، مشکلات مجوز یا شرایط شبکه رخ دهند. درک نحوه تفسیر پیام‌های خطای رایج SSH، شناسایی منشأ مشکل و اعمال رفع مناسب را ساده‌تر می‌کند.

بیشتر خرابی‌های SSH در تعداد کمی دسته جای می‌گیرند. این‌ها معمولاً به احراز هویت، مجوزهای فایل، در دسترس بودن سرویس یا تأیید هاست مربوط‌اند. بخش‌های زیر رایج‌ترین خطاها را توصیف، توضیح می‌دهند چرا رخ می‌دهند و مراحل رفع‌شان را ترسیم می‌کنند.

Permission Denied (publickey)

این یکی از رایج‌ترین خطاهای SSH است که هنگام استفاده از احراز هویت مبتنی بر کلید رخ می‌دهد. نشان می‌دهد که سرور هیچ‌کدام از روش‌های احراز هویتی که کلاینت ارائه کرد را نپذیرفته.

این خطا معمولاً به یکی یا چند دلیل از این دلایل رخ می‌دهد:

• کلید عمومی در فایل authorized_keys سرور موجود نیست.
• کلاینت سعی دارد به‌عنوان کاربر اشتباهی احراز هویت شود.
• مجوزهای فایل یا دایرکتوری مانع خواندن فایل‌های کلید توسط SSH می‌شوند.
• سرور طوری پیکربندی نشده که احراز هویت کلید عمومی را مجاز بداند.

برای شروع عیب‌یابی، تأیید کنید که کلید عمومی روی سرور وجود دارد:

ls ~/.ssh/authorized_keys

بعد، مجوزهای فایل‌ها و دایرکتوری‌های مربوطه را تأیید کنید:

ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys

مجوزهای درست باید این‌ها باشند:

• دایرکتوری .ssh باید روی 700 تنظیم شود.
• فایل authorized_keys باید روی 600 تنظیم شود.

می‌توانید مجوزها را با این اصلاح کنید:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

همچنین مطمئن شوید که به‌عنوان کاربر درست وصل می‌شوید:

ssh user@remote_host

اگر سرور همچنان اتصال را رد کند، تأیید کنید که احراز هویت کلید عمومی در /etc/ssh/sshd_config فعال است.

Connection Refused

خطای «connection refused» نشان می‌دهد که کلاینت SSH توانست به سرور برسد؛ اما هیچ سرویسی اتصال را روی پورت مشخص‌شده نپذیرفت.

این معمولاً یعنی یکی از این‌ها:

• سرویس SSH در حال اجرا نیست.
• SSH روی پورت متفاوتی گوش می‌دهد.
• فایروال دسترسی به پورت SSH را بلاک کرده.

بررسی اینکه آیا سرویس SSH روی سرور در حال اجراست، از طریق روش دسترسی دیگری وارد و اجرا کنید:

sudo systemctl status ssh

یا روی برخی سیستم‌ها:

sudo systemctl status sshd

برای تأیید اینکه SSH روی کدام پورت‌ها گوش می‌دهد:

sudo ss -tlnp | grep ssh

اگر SSH طوری پیکربندی شده که از پورت غیرپیش‌فرض استفاده کند، مطمئن شوید کلاینت‌تان پورت درست را مشخص می‌کند:

ssh -p port_number user@remote_host

همچنین تأیید کنید که هر گونه قوانین فایروال، اتصالات ورودی روی پورت SSH را مجاز می‌دارند.

Host Key Verification Failed

این خطا وقتی رخ می‌دهد که کلید هاست سرور دیگر با کلید ذخیره‌شده روی کلاینت مطابقت نداشته باشد. SSH این را به‌عنوان ریسک امنیتی بالقوه در نظر می‌گیرد و از اتصال امتناع می‌کند.

علل رایج شامل:

• سرور بازسازی یا نصب مجدد شده.
• کلیدهای هاست SSH بازتولید شده‌اند.
• آدرس IP حالا به سرور متفاوتی اشاره می‌کند.

برای رفع این مشکل، ورودی کلید هاست قدیمی را از فایل known_hosts کلاینت حذف کنید:

ssh-keygen -R remote_host

بعد از حذف ورودی، دوباره به سرور وصل شوید. SSH از شما می‌خواهد کلید هاست جدید را تأیید و بپذیرید.

همیشه اثر انگشت جدید را قبل از پذیرش، از طریق یک کانال مورد اعتماد تأیید کنید.

Too Many Authentication Failures

این خطا وقتی رخ می‌دهد که کلاینت SSH چندین روش یا کلید احراز هویت را امتحان کند و از تعداد تلاش‌های مجاز سرور عبور کند.

این معمولاً وقتی اتفاق می‌افتد که یک SSH agent با کلیدهای زیاد بارگذاری شده باشد و کلاینت همه را به‌صورت ترتیبی ارائه کند.

برای مشخص کردن صریح اینکه از کدام کلید استفاده شود، با این وصل شوید:

ssh -i ~/.ssh/id_rsa user@remote_host

همچنین می‌توانید کلاینت‌تان را طوری پیکربندی کنید که فقط کلید مشخص‌شده را ارائه دهد؛ با افزودن این به فایل ~/.ssh/config:

~/.ssh/config
Host remote_host
    IdentityFile ~/.ssh/id_rsa
    IdentitiesOnly yes

این از تلاش SSH برای کلیدهای نامرتبط جلوگیری و خرابی‌های احراز هویت را کاهش می‌دهد.

استفاده از خروجی پرحرف برای تشخیص مشکلات

وقتی خطای SSH بلافاصله روشن نیست، فعال کردن خروجی پرحرف (Verbose)، بینش تفصیلی درباره فرایند اتصال فراهم می‌کند.

برای فعال کردن حالت پرحرف، از گزینه -v استفاده کنید:

ssh -v user@remote_host

برای جزئیات بیشتر، می‌توانید میزان پرحرفی را افزایش دهید:

ssh -vvv user@remote_host

خروجی پرحرف نشان می‌دهد:

• کدام روش‌های احراز هویت امتحان می‌شوند
• کدام کلیدها ارائه و پذیرفته یا رد می‌شوند
• فرایند اتصال کجا شکست می‌خورد

این اطلاعات اغلب برای تشخیص مشکلات پیچیده یا نامشخص SSH ضروری است.

رویکرد عمومی عیب‌یابی

هنگام عیب‌یابی مشکلات SSH، پیروی از یک فرایند ثابت مفید است:

1. اتصال شبکه و دسترسی پورت را تأیید کنید.
2. کاربر و روش احراز هویت درست را بررسی کنید.
3. مالکیت و مجوزهای فایل را چک کنید.
4. خروجی کلاینت SSH را با حالت پرحرف مرور کنید.
5. در صورت وجود، لاگ‌های سمت سرور را بازرسی کنید.

با رفع روشمند مسائل، بیشتر مشکلات SSH بدون نیاز به تغییرات پیکربندی قابل توجه قابل حل‌اند.

سوالات متداول

۱. SSH برای چیست؟

SSH برای اتصال امن و مدیریت سیستم‌های ریموت روی شبکه استفاده می‌شود. به کاربران اجازه می‌دهد به سرورهای ریموت وارد شوند، دستورات را اجرا کنند، فایل‌ها را منتقل و ترافیک شبکه را از طریق اتصالات رمزنگاری‌شده فوروارد کنند.

SSH معمولاً برای مدیریت سرور، دیپلوی اپلیکیشن، عیب‌یابی ریموت و انتقال امن فایل با ابزارهایی مانند scp و sftp استفاده می‌شود.

۲. تفاوت SSH با Telnet چیست؟

SSH و Telnet هر دو دسترسی خط فرمان ریموت فراهم می‌کنند؛ اما در نحوه مدیریت داده به‌طور چشمگیری متفاوت‌اند.

Telnet همه داده‌ها—از جمله نام‌های کاربری و رمزهای عبور—را به‌صورت متن ساده (Plain Text) منتقل می‌کند. این آن را در برابر شنود و سرقت اعتبارنامه آسیب‌پذیر می‌کند.

SSH همه ترافیک بین کلاینت و سرور را رمزنگاری می‌کند. این شامل داده‌های احراز هویت و خروجی دستورات است؛ که اتصال را از شنود و دستکاری محافظت می‌کند. به همین دلیل، SSH تا حد زیادی Telnet را در سیستم‌های مدرن جایگزین کرده است.

۳. آیا کلیدهای SSH از رمزهای عبور امن‌ترند؟

بله، کلیدهای SSH وقتی درست استفاده شوند از رمزهای عبور امن‌ترند.

کلیدهای SSH به رمزنگاری نامتقارن متکی‌اند، نه اسرار مشترک. کلید خصوصی هرگز سیستم کلاینت را ترک نمی‌کند و احراز هویت با اثبات در اختیار داشتن آن کلید انجام می‌شود.

رمزهای عبور را می‌توان حدس زد، استفاده مجدد کرد یا شنود کرد. کلیدهای SSH در برابر حملات brute-force مقاوم‌اند و نمی‌توان آن‌ها را از کلید عمومیِ ذخیره‌شده روی سرور استخراج کرد.

۴. کلیدهای SSH کجا ذخیره می‌شوند؟

روی سیستم کلاینت، کلیدهای SSH معمولاً در دایرکتوری ~/.ssh داخل دایرکتوری خانه کاربر ذخیره می‌شوند.

فایل‌های رایج شامل:

• id_rsa، id_ed25519: کلیدهای خصوصی
• id_rsa.pub، id_ed25519.pub: کلیدهای عمومی

روی سرور، کلیدهای عمومی در فایل ~/.ssh/authorized_keys کاربر ذخیره می‌شوند. کلیدهای خصوصی هرگز نباید روی سرورها ذخیره شوند.

۵. فایل authorized_keys چیست؟

فایل authorized_keys یک فایل سمت سرور است که تعیین می‌کند کدام کلیدهای عمومی SSH مجاز به احراز هویت به یک حساب کاربری هستند.

هر خط در این فایل شامل یک کلید عمومی منفرد است. وقتی کلاینتی تلاش می‌کند احراز هویت کند، سرور این فایل را بررسی می‌کند تا تعیین کند کلید ارائه‌شده authorize شده یا نه.

حذف یک کلید از این فایل، دسترسی آن کلید را فوراً لغو می‌کند.

۶. چطور سرویس SSH را ری‌استارت کنم؟

بعد از اعمال تغییرات روی پیکربندی SSH، سرویس SSH باید برای اعمال تغییرات ری‌استارت شود.

روی سیستم‌های مبتنی بر اوبونتو و دبیان:

sudo systemctl restart ssh

روی سیستم‌های مبتنی بر CentOS و فدورا:

sudo systemctl restart sshd

توصیه می‌شود حین ری‌استارت سرویس، یک نشست SSH موجود باز نگه داشته شود تا از قفل شدن تصادفی جلوگیری شود.

۷. آیا می‌توانم روی ویندوز از SSH استفاده کنم؟

بله، SSH روی ویندوز پشتیبانی می‌شود.

نسخه‌های مدرن ویندوز شامل کلاینت و سرور OpenSSH به‌طور پیش‌فرض هستند. می‌توانید از PowerShell یا Command Prompt با همان دستورات موجود روی لینوکس و macOS از SSH استفاده کنید.

کلاینت‌های شخص ثالثی مانند PuTTY هم رایج‌اند؛ اما دیگر روی سیستم‌های ویندوزی اخیر ضروری نیستند.

۸. SSH از چه پورتی استفاده می‌کند؟

به‌طور پیش‌فرض، SSH روی پورت TCP شماره ۲۲ گوش می‌دهد.

مگر اینکه خلافش پیکربندی شود، کلاینت‌های SSH به‌طور خودکار تلاش می‌کنند به پورت ۲۲ وصل شوند. اگر سرور طوری پیکربندی شده که از پورت متفاوتی استفاده کند، کلاینت باید آن پورت را صریحاً مشخص کند.

۹. آیا تغییر پورت SSH امن است؟

تغییر پورت SSH عموماً امن است و می‌تواند حجم تلاش‌های اتصال خودکار را کاهش دهد.

اما تغییر پورت به‌تنهایی امنیت قوی فراهم نمی‌کند. باید به‌عنوان اقدامی مکمل در کنار کنترل‌های احراز هویت درست—مانند کلیدهای SSH و دسترسی محدود—استفاده شود.

قوانین فایروال هم باید برای اجازه عبور ترافیک روی پورت جدید به‌روزرسانی شوند.

۱۰. چطور ورود با رمز عبور در SSH را غیرفعال کنم؟

ورود رمز عبور را می‌توان با تغییر پیکربندی دیمن SSH غیرفعال کرد.

فایل پیکربندی را با دسترسی root یا sudo باز کنید:

sudo nano /etc/ssh/sshd_config

این دایرکتیو را تنظیم کنید:

/etc/ssh/sshd_config
PasswordAuthentication no

بعد از اعمال تغییر، سرویس SSH را ری‌استارت کنید. قبل از غیرفعال کردن ورودهای رمز عبور، مطمئن شوید احراز هویت کلید SSH کار می‌کند تا از دست رفتن دسترسی جلوگیری شود.

نتیجه‌گیری

SSH ابزاری بنیادی برای دسترسی امن و مدیریت سیستم‌های ریموت است. استفاده مؤثر از آن، بیش از دانستن نحوه اتصال لازم دارد. همچنین شامل درک احراز هویت، رابطه‌های اعتماد، انتخاب‌های پیکربندی و سناریوهای خرابی رایج است.

این مقاله مبانی SSH، احراز هویت مبتنی بر کلید، پیکربندی‌های پیش‌فرض امن، الگوهای استفاده پیشرفته و عیب‌یابی عملی را پوشش داد. این موضوعات در کنار هم، پایه‌ای محکم برای استفاده امن و بااطمینان از SSH در وظایف روزمره مدیریتی و توسعه فراهم می‌کنند.

با برقراری این مفاهیم، SSH سازوکاری قابل اطمینان و انعطاف‌پذیر برای مدیریت سیستم‌ها و دسترسی امن به منابع ریموت می‌شود.