آموزش ساخت کلید SSH در لینوکس: راهنمای آسان گام‌به‌گام

مقدمه

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

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

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

نکات کلیدی

• کلیدهای SSH روش احراز هویتی امن‌تری نسبت به رمز عبور فراهم می‌کنند. احراز هویت با رمز عبور در برابر حملات جستجوی فراگیر (Brute-Force) آسیب‌پذیر است؛ در حالی که کلیدهای SSH از جفت‌کلیدهای رمزنگاری استفاده می‌کنند که امنیت دسترسی به سرور را به‌طور چشمگیری تقویت می‌کنند.
• احراز هویت SSH از جفت کلید عمومی-خصوصی استفاده می‌کند. کلید خصوصی روی ماشین کلاینت می‌ماند و باید محرمانه نگه داشته شود؛ در حالی که کلید عمومی روی سرور در فایل ~/.ssh/authorized_keys قرار می‌گیرد تا احراز هویت ممکن شود.
• کلیدهای SSH با ابزار ssh-keygen تولید می‌شوند. ابزار OpenSSH یعنی ssh-keygen یک جفت‌کلید می‌سازد که معمولاً در دایرکتوری ~/.ssh ذخیره می‌شود (مثلاً id_rsa و id_rsa.pub).
• می‌توان یک عبارت عبور (Passphrase) برای محافظت از کلید خصوصی اضافه کرد. رمزنگاری کلید خصوصی با passphrase یک لایه امنیتی اضافی فراهم می‌کند و از استفاده مهاجمان از کلید جلوگیری می‌نماید؛ حتی اگر به فایل دسترسی پیدا کنند.
• کلیدهای عمومی باید روی سرور کپی شوند تا احراز هویت کار کند. رایج‌ترین روش، استفاده از دستور ssh-copy-id است که کلید عمومی را به‌طور خودکار در فایل authorized_keys سرور نصب می‌کند. روش‌های جایگزین شامل ارسال کلید از طریق SSH یا افزودن دستی آن است.
• بعد از نصب کلید عمومی، کاربران می‌توانند بدون رمز عبور وارد شوند. وقتی سرور تأیید کند که کلاینت کلید خصوصی متناظر را در اختیار دارد، بدون درخواست رمز عبور حساب، اجازه ورود می‌دهد.
• احراز هویت با رمز عبور باید بعد از پیکربندی کلیدهای SSH غیرفعال شود. ویرایش /etc/ssh/sshd_config و تنظیم PasswordAuthentication no ریسک حملات brute-force به سرور را کاهش می‌دهد.
• ماژول‌های امنیتی سخت‌افزاری (HSM) می‌توانند کلیدهای SSH را بیشتر امن کنند. HSMها کلیدهای خصوصی را در سخت‌افزار مقاوم در برابر دستکاری ذخیره می‌کنند؛ که از سرقت یا افشای آن‌ها حتی در صورت به‌خطرافتادن خود سیستم جلوگیری می‌کند.

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

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

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

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

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

کلید عمومی را می‌توان بدون هیچ عاقبت منفی آزادانه به اشتراک گذاشت. حین احراز هویت، SSH از جفت‌کلید برای اثبات اینکه کلاینت کلید خصوصی را در اختیار دارد استفاده می‌کند (بدون ارسال کلید خصوصی روی شبکه). در عمل، کلاینت داده‌ها را با کلید خصوصی امضا می‌کند و سرور آن امضا را با کلید عمومی تأیید می‌کند.

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

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

گام ۱ — ساخت کلیدهای SSH

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

برای این کار، می‌توانیم از ابزار ویژه‌ای به نام ssh-keygen استفاده کنیم که همراه مجموعه استاندارد ابزارهای OpenSSH ارائه می‌شود. به‌طور پیش‌فرض، این ابزار یک جفت‌کلید RSA با ۳۰۷۲ بیت می‌سازد.

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

ssh-keygen

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

ابزار از شما می‌خواهد مکانی برای کلیدهایی که تولید خواهند شد انتخاب کنید. به‌طور پیش‌فرض، کلیدها در دایرکتوری ~/.ssh داخل دایرکتوری خانه کاربر ذخیره می‌شوند. کلید خصوصی id_rsa و کلید عمومی مرتبط id_rsa.pub نام خواهد داشت.

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

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

Output
/home/username/.ssh/id_rsa already exists.
Overwrite (y/n)?

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

Output
Created directory '/home/username/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

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

شاید تعجب کنید که چه مزیتی دارد اگر هنوز لازم باشد passphrase وارد کنید. برخی مزایا:

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

چون کلید خصوصی هرگز روی شبکه افشا نمی‌شود و از طریق مجوزهای فایل محافظت می‌شود، این فایل هرگز نباید برای کسی غیر از شما (و کاربر root) قابل دسترس باشد. passphrase به‌عنوان لایه محافظتی اضافی در صورتی که این شرایط به خطر بیفتند عمل می‌کند.

passphrase یک افزودنی اختیاری است. اگر وارد کنید، هر بار که از این کلید استفاده می‌کنید باید آن را ارائه دهید (مگر اینکه نرم‌افزار SSH agent اجرا کنید که کلید رمزگشایی‌شده را ذخیره می‌کند). استفاده از passphrase را توصیه می‌کنیم؛ اما اگر نمی‌خواهید passphrase تعیین کنید، می‌توانید ENTER را بزنید تا از این پرامپت عبور کنید.

Output
Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:CAjsV9M/tt5skazroTc1ZRGCBz+kGtYUIPhRvvZJYBs username@hostname
The key's randomart image is:
+---[RSA 3072]----+
|o   ..oo.++o ..  |
| o o +o.o.+...   |
|. . + oE.o.o  .  |
| . . oo.B+  .o   |
|  .   .=S.+ +    |
|      . o..*     |
|        .+= o    |
|        .=.+     |
|       .oo+      |
+----[SHA256]-----+

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

گام ۲ — کپی کلید عمومی SSH به سرورتان

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

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

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

کپی کلید عمومی با ssh-copy-id

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

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

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

سینتکس این است:

ssh-copy-id username@remote_host

ممکن است پیغامی مثل این ببینید:

Output
The authenticity of host '203.0.113.1 (203.0.113.1)' 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 را تایپ و برای ادامه ENTER را بزنید.

بعد، ابزار حساب محلی‌تان را برای کلید id_rsa.pub که قبلاً ساختیم جستجو می‌کند. وقتی کلید را پیدا کند، رمز عبور حساب کاربر ریموت را از شما می‌پرسد:

Output
/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
username@203.0.113.1's password:

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

خروجی‌ای شبیه این خواهید دید:

Output
Number of key(s) added: 1

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

در این نقطه، کلید id_rsa.pub شما به حساب ریموت آپلود شده. می‌توانید به بخش بعدی بروید.

کپی کلید عمومی با SSH

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

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

از نماد ریدایرکت >> برای اضافه کردن محتوا به‌جای بازنویسی آن استفاده می‌کنیم. این به ما اجازه می‌دهد کلیدها را بدون نابودی کلیدهای قبلاً اضافه‌شده، بیفزاییم.

دستور کامل به این شکل است:

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

ممکن است پیغامی مثل این ببینید:

Output
The authenticity of host '203.0.113.1 (203.0.113.1)' 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 را تایپ و برای ادامه ENTER را بزنید.

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

Output
username@203.0.113.1's password:

بعد از وارد کردن رمز عبور، محتوای کلید id_rsa.pub شما به انتهای فایل authorized_keys حساب کاربر ریموت کپی می‌شود. اگر موفق بود، به بخش بعدی بروید.

کپی دستی کلید عمومی

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

محتوای فایل id_rsa.pub شما باید به نوعی به فایل ~/.ssh/authorized_keys روی ماشین ریموت اضافه شود.

برای نمایش محتوای کلید id_rsa.pub، این را روی کامپیوتر محلی‌تان تایپ کنید:

cat ~/.ssh/id_rsa.pub

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

~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== username@hostname

با هر روشی که در دسترس دارید به هاست ریموت‌تان دسترسی پیدا کنید. این ممکن است یک کنسول مبتنی بر وبِ ارائه‌دهنده زیرساخت‌تان باشد.

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

وقتی به حساب‌تان روی سرور ریموت دسترسی داشتید، باید مطمئن شوید دایرکتوری ~/.ssh ساخته شده. این دستور دایرکتوری را در صورت لزوم می‌سازد یا اگر از قبل وجود دارد کاری نمی‌کند:

mkdir -p ~/.ssh

حالا می‌توانید فایل authorized_keys را در این دایرکتوری بسازید یا تغییر دهید. می‌توانید محتوای فایل id_rsa.pub خود را به انتهای فایل authorized_keys اضافه کنید؛ و در صورت لزوم آن را بسازید؛ با این دستور:

echo public_key_string >> ~/.ssh/authorized_keys

در دستور بالا، به‌جای public_key_string خروجیِ دستور cat ~/.ssh/id_rsa.pub را که روی سیستم محلی‌تان اجرا کردید قرار دهید. باید با ssh-rsa AAAA... یا مشابه شروع شود.

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

گام ۳ — احراز هویت به سرور با کلیدهای SSH

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

فرایند تقریباً یکسان است:

ssh username@remote_host

اگر اولین بار است به این هاست وصل می‌شوید (اگر آخرین روش بالا را استفاده کردید)، ممکن است چیزی شبیه این ببینید:

Output
The authenticity of host '203.0.113.1 (203.0.113.1)' 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 را تایپ و برای ادامه ENTER را بزنید.

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

اگر موفق بود، ادامه دهید تا بفهمید چطور سرور را قفل کنید.

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

اگر توانستید بدون رمز عبور با SSH به حساب‌تان وارد شوید، احراز هویت مبتنی بر کلید SSH را برای حساب‌تان با موفقیت پیکربندی کرده‌اید. اما احراز هویت مبتنی بر رمز عبور هنوز فعال است؛ یعنی سرورتان همچنان در معرض حملات brute-force است.

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

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

sudo nano /etc/ssh/sshd_config

داخل فایل، به دنبال دایرکتیوی به نام PasswordAuthentication بگردید. ممکن است کامنت شده باشد. با حذف هر # در ابتدای خط، آن را از کامنت دربیاورید و مقدار را روی no تنظیم کنید. این کار توانایی‌تان برای ورود از طریق SSH با رمز عبور حساب‌ها را غیرفعال می‌کند:

/etc/ssh/sshd_config
PasswordAuthentication no

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

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

sudo systemctl restart ssh

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

استفاده از ماژول‌های امنیتی سخت‌افزاری (HSM) برای ذخیره کلید SSH

ماژول‌های امنیتی سخت‌افزاری (HSM) با نگه‌داشتن کلیدهای خصوصی در سخت‌افزار مقاوم در برابر دستکاری، لایه اضافی امنیتی برای کلیدهای SSH فراهم می‌کنند. به‌جای ذخیره کلیدهای خصوصی در فایل، HSMها آن‌ها را امن نگه می‌دارند و از دسترسی غیرمجاز جلوگیری می‌کنند.

چطور از HSM برای احراز هویت SSH استفاده کنیم؟

۱. بررسی سازگاری HSM: مطمئن شوید HSM شما از احراز هویت SSH پشتیبانی می‌کند.

۲. استفاده از ماژول PKCS#11: بیشتر یکپارچه‌سازی‌های HSM به یک کتابخانه ارائه‌دهنده PKCS#11 سازگار متکی‌اند که توسط فروشنده تأمین می‌شود (یا توسط ابزاری مثل OpenSC). PKCS#11 یک استاندارد رمزنگاری است که APIای برای دسترسی به توکن‌های رمزنگاری مانند HSMها، کارت‌های هوشمند و کلیدهای امنیتی USB تعریف می‌کند.

۳. بارگذاری کلید پشتیبانی‌شده HSM در SSH agent خود: روی بسیاری از سیستم‌ها می‌توانید از ssh-agent بخواهید هویت‌ها را از یک ارائه‌دهنده PKCS#11 بارگذاری کند. مسیر دقیق ارائه‌دهنده بسته به سیستم‌عامل و فروشنده متفاوت است.

ssh-add -s /usr/lib/opensc-pkcs11.so

۴. استخراج کلید عمومی و نصب آن روی سرور: کلیدهای عمومیِ در معرض نمایش توسط agent را فهرست کنید و مورد مرتبط را به ~/.ssh/authorized_keys روی سرور اضافه کنید.

ssh-add -L

در صورت تمایل می‌توانید خروجی را به فایلی ریدایرکت کنید، سپس آن کلید عمومی را در authorized_keys کپی کنید:

ssh-add -L > ~/.ssh/id_hsm.pub

۵. پیکربندی SSH برای استفاده از HSM: این را به فایل پیکربندی SSH خود ~/.ssh/config اضافه کنید:

Host *
    IdentityAgent /run/user/1000/gnupg/S.gpg-agent.ssh

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

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

مزایای استفاده از HSM برای مدیریت کلید SSH

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

خطاهای رایج و عیب‌یابی احراز هویت کلید SSH

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

۱. مجوزهای نادرست فایل یا دایرکتوری

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

روی بیشتر سرورهای OpenSSH، این رفتار توسط تنظیم پیش‌فرض StrictModes کنترل می‌شود؛ که باعث می‌شود sshd کلیدها را نادیده بگیرد اگر دایرکتوری خانه حساب، دایرکتوری ~/.ssh یا فایل authorized_keys برای گروه یا کاربران دیگر قابل نوشتن باشد.

مجوزها و مالکیت را روی سرور ریموت بررسی کنید:

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

مجوزهای معمولِ توصیه‌شده:

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

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

chmod 600 ~/.ssh/id_rsa

همچنین باید مطمئن شوید دایرکتوری و فایل، متعلق به حساب کاربری‌ای هستند که با آن وارد می‌شوید:

sudo chown -R username:username ~/.ssh

همچنین مطمئن شوید دایرکتوری خانه‌تان برای گروه یا کاربران دیگر قابل نوشتن نیست:

chmod 755 ~

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

۲. کلید عمومی به‌درستی به authorized_keys اضافه نشده

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

برای تأیید کلید:

cat ~/.ssh/authorized_keys

یک ورودی کلید معتبر معمولاً با نوع کلید (الگوریتم) شروع می‌شود؛ به‌دنبالش یک بلاب بلند base64-کدگذاری‌شده و یک کامنت اختیاری می‌آید؛ مانند:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQ... user@hostname

کلیدهای مدرن هم ممکن است شبیه این باشند:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... user@hostname

اشتباهات رایج شامل:

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

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

ssh-copy-id username@remote_host

اگر چند کلید روی کلاینت دارید، اغلب امن‌تر است فایل کلید عمومی دقیقی را که می‌خواهید نصب کنید مشخص کنید:

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@remote_host

۳. استفاده از کلید خصوصی اشتباه

اگر چند کلید SSH دارید، کلاینت SSH ممکن است تلاش کند از کلید اشتباهی استفاده کند.

می‌توانید هنگام اتصال، کلید را صریحاً مشخص کنید:

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

اگر می‌خواهید مطمئن شوید SSH هویت‌های دیگری از agent شما ارائه نمی‌دهد، IdentitiesOnly=yes را اضافه کنید:

ssh -i ~/.ssh/id_rsa -o IdentitiesOnly=yes username@remote_host

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

ssh -v username@remote_host

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

اگر مرتباً از چند کلید استفاده می‌کنید، می‌توانید آن‌ها را در ~/.ssh/config پیکربندی کنید:

Host myserver
    HostName remote_host
    User username
    IdentityFile ~/.ssh/id_rsa

۴. سرویس SSH بعد از تغییرات پیکربندی ری‌استارت نشده

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

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

sudo sshd -t

روی اوبونتو و دبیان، سرویس OpenSSH معمولاً ssh نام دارد. روی برخی توزیع‌های دیگر (مثل CentOS/RHEL/Fedora)، معمولاً sshd نامیده می‌شود.

SSH را با یکی از این دستورات ری‌استارت کنید:

sudo systemctl restart ssh
sudo systemctl restart sshd

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

sudo systemctl reload ssh

اگر سرویس ری‌استارت نشد، لاگ‌ها را برای خطاها بررسی کنید:

sudo journalctl -u ssh
sudo journalctl -u sshd

۵. نام کاربری یا هاست اشتباه

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

مثلاً:

ssh root@remote_host

اگر کلید عمومی به حساب دیگری مثل ubuntu یا admin اضافه شده باشد، احراز هویت شکست می‌خورد.

تأیید کنید کدام حساب، کلید نصب‌شده دارد:

cat /home/username/.ssh/authorized_keys

سپس با همان نام کاربری وصل شوید.

۶. SSH agent با کلید خصوصی بارگذاری نشده

اگر از کلید محافظت‌شده با passphrase استفاده می‌کنید، ممکن است لازم باشد کلید را به SSH agent اضافه کنید.

ایجنت را راه بیندازید:

eval "$(ssh-agent -s)"

کلید خود را اضافه کنید:

ssh-add ~/.ssh/id_rsa

می‌توانید بارگذاری شدن کلید را با فهرست کردن هویت‌ها در ایجنت تأیید کنید:

ssh-add -l

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

۷. سرور همچنان اجازه احراز هویت رمز عبور می‌دهد

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

فایل پیکربندی SSH را باز کنید:

sudo nano /etc/ssh/sshd_config

مطمئن شوید این تنظیم موجود است:

PasswordAuthentication no

اگر می‌خواهید پرامپت‌های تعاملی شبیه رمز عبور را کاملاً غیرفعال کنید، می‌توانید مطمئن شوید احراز هویت کیبورد-تعاملی هم غیرفعال است:

KbdInteractiveAuthentication no

همچنین باید تأیید کنید که احراز هویت کلید عمومی فعال است:

PubkeyAuthentication yes

سپس SSH را ریلود یا ری‌استارت کنید:

sudo systemctl restart ssh

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

۸. محدودیت‌های فایروال یا شبکه

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

بررسی کنید آیا سرور SSH روی پورتی در حال شنود است (معمولاً ۲۲ مگر اینکه تغییرش داده باشید):

sudo ss -tlnp | grep ssh

اگر فایروال فعال است، مطمئن شوید SSH مجاز است:

sudo ufw allow ssh
sudo ufw reload

همچنین باید تأیید کنید که به آدرس IP و پورت درست وصل می‌شوید.

نکته دیباگ: استفاده از حالت پرحرف SSH

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

ssh -vvv username@remote_host

این دستور لاگ‌های تفصیلیِ فرایند احراز هویت را نشان می‌دهد؛ شامل:

• کدام کلیدها را کلاینت تلاش می‌کند استفاده کند
• آیا سرور آن‌ها را می‌پذیرد یا رد می‌کند
• مشکلات پیکربندی که ممکن است مانع ورودتان شوند

این لاگ‌ها اغلب دقیقاً نشان می‌دهند فرایند احراز هویت کجا شکست می‌خورد.

اگر از طریق کنسول یا نشست دیگری به سرور دسترسی دارید، لاگ‌های سمت سرور هم فوق‌العاده مفیدند. روی بسیاری از سیستم‌های دبیان/اوبونتو می‌توانید /var/log/auth.log را بررسی کنید و روی سیستم‌های مبتنی بر systemd می‌توانید لاگ‌های یونیت SSH را بازرسی کنید:

sudo tail -n 50 /var/log/auth.log
sudo journalctl -u ssh -n 50 --no-pager

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

۱. چطور در لینوکس کلید SSH بسازم؟

برای ساخت کلید SSH در لینوکس، از دستور ssh-keygen در ترمینال‌تان استفاده کنید. به‌طور پیش‌فرض، این یک جفت‌کلید RSA می‌سازد:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

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

۲. ssh-keygen در لینوکس چیست؟

ssh-keygen یک ابزار خط فرمان برای تولید، مدیریت و تبدیل کلیدهای SSH است. به شما اجازه می‌دهد اعتبارنامه‌های احراز هویت امن برای دسترسی ریموت بسازید. می‌توانید درباره ssh-keygen و نحوه کارش بیشتر در راهنمای «ساخت کلیدهای SSH با OpenSSH» در پارمین کلود یاد بگیرید.

۳. چطور کلید SSH-2 RSA در لینوکس تولید کنم؟

SSH-2 پروتکل استاندارد فعلی برای احراز هویت SSH است. برای تولید کلید SSH-2 RSA، این را اجرا کنید:

ssh-keygen -t rsa -b 4096

جزئیات بیشتر درباره افزودن کلیدهای SSH را در مستندات رسمی «نحوه افزودن کلیدهای SSH» در پارمین کلود ببینید.

۴. چطور کلید SSH معتبر بسازم؟

یک کلید SSH معتبر باید این معیارها را داشته باشد:

• از نوع کلید قوی استفاده کنید؛ مانند RSA (۴۰۹۶ بیت) یا Ed25519.
• مطمئن شوید کلید خصوصی امن ذخیره و محافظت می‌شود.
• از passphrase برای امنیت اضافی استفاده کنید.
• از الگوریتم‌های ضعیف مثل DSA بپرهیزید.

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

۵. چطور از ترمینال کلید SSH تولید کنم؟

کافی است اجرا کنید:

ssh-keygen

این یک جفت‌کلید عمومی و خصوصی تولید می‌کند؛ که معمولاً در ~/.ssh/ ذخیره می‌شوند.

۶. چطور کلید خصوصی تولید کنم؟

دستور ssh-keygen به‌طور خودکار یک کلید خصوصی تولید می‌کند. کلید خصوصی معمولاً در این مسیر ذخیره می‌شود:

~/.ssh/id_rsa

یا برای استانداردهای جدیدتر:

~/.ssh/id_ed25519

این فایل را امن نگه دارید و آن را به اشتراک نگذارید.

۷. تفاوت کلید عمومی و خصوصی SSH چیست؟

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

۸. چطور احراز هویت رمز عبور را روی سرور لینوکسی غیرفعال کنم؟

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

sudo nano /etc/ssh/sshd_config

این خط را پیدا کنید:

PasswordAuthentication yes

به این تغییر دهید:

PasswordAuthentication no

سپس SSH را ری‌استارت کنید:

sudo systemctl restart ssh

برای دستورالعمل‌های بیشتر، به «ساخت کلیدهای SSH با OpenSSH» در پارمین کلود مراجعه کنید.

نتیجه‌گیری

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