ورود به سرور با کلید SSH به‌جای رمز عبور (آموزش کامل و رفع خطاها)

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

کلیدِ SSH چطور کار می‌کند؟

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

عبارتِ عبورِ کلید را بگذارید. اگر لپ‌تاپتان گم شود، بدونِ آن هر کسی می‌تواند به سرورهایتان وارد شود. با عاملِ کلید (که پایین‌تر می‌آید) لازم نیست هر بار آن را تایپ کنید.

گام ۱: ساختِ کلید

روی لینوکس، مک یا PowerShellِ ویندوز:

ssh-keygen -t ed25519 -C "laptop-hamoon"

مقدارِ -C فقط یک برچسبِ توضیحی است و کمک می‌کند بعداً بدانید کدام کلید مالِ کدام دستگاه است. سه پرسش می‌پرسد: محلِ ذخیره (پیش‌فرض خوب است)، عبارتِ عبور، و تکرارِ آن.

خروجی دو فایل است: ~/.ssh/id_ed25519 کلیدِ خصوصی و ~/.ssh/id_ed25519.pub کلیدِ عمومی.

چرا Ed25519 و نه RSA؟

کوتاه‌تر است، سریع‌تر است و امنیتِ بهتری در همان اندازه می‌دهد. اگر با سرورِ بسیار قدیمی کار می‌کنید که پشتیبانی نمی‌کند، از ssh-keygen -t rsa -b 4096 استفاده کنید.

گام ۲: انتقالِ کلیدِ عمومی به سرور

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

ssh-copy-id hamoon@SERVER_IP

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

cat ~/.ssh/id_ed25519.pub | ssh hamoon@SERVER_IP 
  "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

گام ۳: سطحِ دسترسیِ فایل‌ها

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

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

گام ۴: آزمایش، پیش از بستنِ رمز

یک پنجرهٔ ترمینالِ فعال را باز نگه دارید و در پنجرهٔ دوم ورود با کلید را بیازمایید:

ssh -o PreferredAuthentications=publickey hamoon@SERVER_IP

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

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

گام ۵: بستنِ ورود با رمز

در فایل /etc/ssh/sshd_config:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no
ChallengeResponseAuthentication no

پیکربندی را پیش از راه‌اندازیِ مجدد بسنجید تا با یک غلطِ تایپی سرویس بالا نیاید:

sshd -t && systemctl reload ssh

گام ۶: عاملِ کلید، تا هر بار عبارتِ عبور نخواهد

روی لینوکس و مک:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

روی ویندوز، سرویسِ داخلیِ عاملِ SSH را روشن کنید و کلید را به آن بسپارید. اگر با PuTTY کار می‌کنید، ابزارِ Pageant همین نقش را دارد: کلیدِ .ppk را یک بار باز می‌کنید و تا پایانِ نشستِ ویندوز در حافظه می‌ماند.

مدیریتِ چند سرور

وقتی چند سرور دارید، فایلِ ~/.ssh/config کارتان را ساده می‌کند:

Host hamoon-web
    HostName 185.10.20.30
    Port 22000
    User hamoon
    IdentityFile ~/.ssh/id_ed25519

Host hamoon-db
    HostName 185.10.20.31
    User hamoon
    IdentityFile ~/.ssh/id_ed25519

از این پس فقط ssh hamoon-web کافی است — پورت و کاربر و کلید خودکار اعمال می‌شوند.

رفعِ خطاهای رایج

Permission denied (publickey)

به ترتیب بررسی کنید: کلیدِ عمومی در authorized_keys همان کاربر باشد (نه کاربرِ دیگر)، سطحِ دسترسیِ فایل‌ها درست باشد، و کلیدِ خصوصیِ متناظر روی دستگاهِ شما موجود باشد. برای دیدنِ جزئیات:

ssh -vvv hamoon@SERVER_IP

Agent admitted failure to sign

عاملِ کلید کلیدِ درست را ندارد. با ssh-add -l فهرست را ببینید و در صورت نبود، کلید را دوباره اضافه کنید.

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED

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

ssh-keygen -R SERVER_IP

کلید برای انتقالِ فایل و کارهای خودکار

همان کلید برای انتقالِ فایل هم کار می‌کند:

# کپیِ یک فایل به سرور
scp -i ~/.ssh/id_ed25519 backup.tar.gz hamoon@SERVER_IP:/home/hamoon/

# همگام‌سازی یک پوشه
rsync -az -e "ssh -i ~/.ssh/id_ed25519" ./dist/ hamoon@SERVER_IP:/var/www/html/

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

from="1.2.3.4",no-port-forwarding,no-agent-forwarding,no-pty,command="/usr/local/bin/backup-only.sh" ssh-ed25519 AAAA... backup-job

با command، حتی اگر کلید لو برود، فقط همان یک اسکریپت اجرا می‌شود و دسترسیِ پوسته داده نمی‌شود.

چند کاربر روی یک سرور

اگر کسِ دیگری هم به سرور دسترسی دارد، هرگز کلیدِ مشترک نسازید. برای هر نفر کاربرِ جدا و کلیدِ جدا بسازید:

• ردِ پای هر کار در لاگ به نامِ همان شخص ثبت می‌شود.
• قطعِ دسترسیِ یک نفر به حذفِ یک خط از authorized_keysِ او خلاصه می‌شود، نه تغییرِ کلیدِ همه.
• می‌توانید سطحِ دسترسیِ متفاوت بدهید؛ همه لازم نیست sudo داشته باشند.

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

for u in /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys; do
  [ -f "$u" ] && echo "== $u" && ssh-keygen -lf "$u"
done

سه تنظیمِ تکمیلی که ارزشش را دارد

1. محدود کردنِ کاربرانِ مجاز: در sshd_config با AllowUsers hamoon deploy فقط همین دو کاربر می‌توانند وارد شوند.
2. کوتاه کردنِ مهلتِ ورود: LoginGraceTime 20 اتصال‌های نیم‌کارهٔ رباتی را سریع‌تر می‌بندد.
3. کاهشِ تلاش‌های مجاز: MaxAuthTries 3 همراه با Fail2ban، فشارِ اسکنِ خودکار را به‌شکلِ محسوسی کم می‌کند.

نسخهٔ پشتیبانِ کلید

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