مدیریت کلیدهای SSH در گیت‌هاب: چرا یک کلید قدیمی کل حساب را باز می‌کند؟

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

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

چرا SSH هنوز روش پیشنهادی اتصال به GitHub است

GitHub دو روش اصلی برای احراز هویت ارائه می‌دهد: HTTPS با توکن و SSH با کلید. هر دو روش امن هستند، اما SSH چند مزیت عملی دارد. اول، نیاز به وارد کردن توکن در هر عملیات را حذف می‌کند. دوم، با ssh-agent می‌توان چند کلید را هم‌زمان مدیریت کرد. سوم، در محیط‌های خودکار مثل سرورهای CI، SSH راحت‌تر پیکربندی می‌شود.

در سال‌های اخیر، GitHub روش‌های دیگری مثل توکن‌های دقیق‌تر (fine-grained tokens) هم اضافه کرده، اما SSH همچنان انتخاب پیش‌فرض بسیاری از توسعه‌دهندگان حرفه‌ای است. اگر تازه شروع کرده‌اید، مطالعه‌ی آموزش Git از صفر پیش از پیکربندی SSH مفید است، چون درک مدل احراز هویت گیت به درک نقش SSH کمک می‌کند.

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

آناتومی کلید؛ عمومی، خصوصی و نقش هرکدام

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

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

کلید خصوصی: فایلی که با id_rsa، id_ed25519 یا نام‌های مشابه در پوشه‌ی ~/.ssh قرار دارد. باید با رمز محافظت شود و هرگز به اشتراک گذاشته نشود.
کلید عمومی: فایلی با پسوند .pub. قابل اشتراک است و در GitHub یا سرورها ذخیره می‌شود.
گذرواژه کلید (Passphrase): رمزی که کلید خصوصی را رمزنگاری می‌کند. اضافه کردن آن توصیه‌ی جدی است.
اثر انگشت (Fingerprint): شناسه‌ی کوتاه کلید که برای تشخیص سریع آن استفاده می‌شود.

انواع کلید و انتخاب نوع مناسب

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

الگوریتم	طول توصیه‌شده	مزیت	محدودیت
Ed25519	۲۵۶ بیت	امنیت بالا، سرعت بالا، طول کم	پشتیبانی در سیستم‌های قدیمی ممکن است ناقص باشد
ECDSA	۲۵۶ یا ۵۲۱ بیت	پشتیبانی گسترده	نگرانی‌های مربوط به منحنی‌های NIST
RSA	حداقل ۴۰۹۶ بیت	پشتیبانی تقریباً جهانی	طول زیاد، سرعت کمتر
DSA	-	منسوخ	استفاده نمی‌شود

انتخاب پیشنهادی امروز، Ed25519 است. این الگوریتم هم از نظر امنیتی محکم است و هم از نظر کارایی سریع. اگر با سیستم‌های قدیمی سر و کار دارید که Ed25519 را پشتیبانی نمی‌کنند، RSA با طول ۴۰۹۶ بیت گزینه‌ی قابل اعتمادی است. استفاده از DSA و RSA با طول کمتر از ۲۰۴۸ توصیه نمی‌شود.

نکته‌ی مهم دیگر، استفاده از فرمت کلید جدید (RFC 4716 یا OpenSSH format) به‌جای فرمت قدیمی PEM است. GitHub از فرمت‌های جدید به‌خوبی پشتیبانی می‌کند و این فرمت‌ها اطلاعات بیشتری درباره‌ی الگوریتم و پارامترها ذخیره می‌کنند.

ساخت کلید اصولی با ssh-keygen

ساخت کلید با دستور ssh-keygen انجام می‌شود. یک الگوی توصیه‌شده:

ssh-keygen -t ed25519 -C "email@example.com" -f ~/.ssh/github_ed25519

پارامترها:

-t ed25519: انتخاب الگوریتم.
-C: کامنت که معمولاً ایمیل است و به شناسایی کلید کمک می‌کند.
-f: مسیر و نام فایل کلید.

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

پس از ساخت، دو فایل تولید می‌شود: github_ed25519 (کلید خصوصی) و github_ed25519.pub (کلید عمومی). مجوزهای فایل کلید خصوصی باید ۶۰۰ باشد:

chmod 600 ~/.ssh/github_ed25519

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

افزودن کلید به حساب GitHub

پس از ساخت کلید، محتوای کلید عمومی را کپی کنید:

cat ~/.ssh/github_ed25519.pub

سپس در GitHub به مسیر Settings → SSH and GPG keys → New SSH key بروید و محتوای کلید عمومی را در آنجا وارد کنید. برای کلید در سطح سازمان، مسیر Organization Settings → SSH Certificate Authorities متفاوت است.

پس از افزودن، اتصال را تست کنید:

ssh -T git@github.com

اگر پیام Hi username! You''ve successfully authenticated را دیدید، اتصال برقرار است. اگر خطا گرفتید، بررسی کنید که کلید خصوصی در مسیر درست باشد و پیکربندی SSH از آن استفاده کند.

برای اطمینان از اینکه کلید عمومی درست به GitHub اضافه شده، می‌توانید اثر انگشت را با دستور ssh-keygen -lf ~/.ssh/github_ed25519.pub بگیرید و با آنچه در GitHub نمایش داده می‌شود مقایسه کنید.

مدیریت کلیدها با ssh-agent

هر بار وارد کردن رمز کلید، خسته‌کننده است. ssh-agent یک برنامه‌ی پس‌زمینه است که کلیدهای باز‌شده‌ی شما را نگه می‌دارد و در طول جلسه‌ی کاری، به‌جای شما پاسخ چالش‌ها را می‌دهد.

# راه‌اندازی ssh-agent
eval "$(ssh-agent -s)"

# افزودن کلید به agent
ssh-add ~/.ssh/github_ed25519

# نمایش کلیدهای موجود
ssh-add -l

در macOS، می‌توانید از Keychain استفاده کنید تا کلید بین جلسات حفظ شود:

ssh-add --apple-use-keychain ~/.ssh/github_ed25519

در Windows، سرویس ssh-agent به‌صورت پیش‌فرض در PowerShell نصب است. در Linux، باید مطمئن شوید که agent در shell profile راه‌اندازی می‌شود.

نکته‌ی امنیتی: رمز کلید هرگز نباید در محیط shell به‌عنوان متغیر ذخیره شود. اگر از ssh-agent استفاده می‌کنید، کلید فقط در حافظه‌ی agent نگه داشته می‌شود و در دیسک رمزنگاری‌شده باقی می‌ماند.

مدیریت چند کلید و پیکربندی config

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

فایل ~/.ssh/config نقش کلیدی در این مدیریت دارد:

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/github_personal
  IdentitiesOnly yes

Host github-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/github_work
  IdentitiesOnly yes

با این پیکربندی، می‌توانید برای حساب شخصی از git@github.com:user/repo.git استفاده کنید و برای حساب کاری از git@github-work:org/repo.git. SSH بر اساس نام میزبان، کلید مناسب را انتخاب می‌کند.

پارامتر IdentitiesOnly yes مهم است. بدون آن، SSH همه‌ی کلیدهای موجود در agent را امتحان می‌کند و ممکن است به‌دلیل تعداد زیاد کلید، به محدودیت تعداد تلاش در سرور برخورد کند. این خطا در GitHub به‌صورت Too many authentication failures ظاهر می‌شود.

برای درک بهتر اینکه چطور پیکربندی SSH با سایر ابزارهای توسعه هماهنگ می‌شود، چرا Visual Studio Code استاندارد Editor صنعت شده است؟ از زاویه‌ی پیکربندی محیط توسعه بررسی کرده‌ام.

گواهی‌های SSH و مزیت آن‌ها در سازمان

در سازمان‌های بزرگ، مدیریت تعداد زیاد کلید عمومی به یک چالش تبدیل می‌شود. وقتی تیم چند نفر دارد و اعضا مرتب تغییر می‌کنند، نگهداری لیست کلیدها در هر سرور دشوار است. گواهی‌های SSH (SSH Certificates) این مسئله را حل می‌کنند.

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

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

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

چرخش و باطل کردن کلیدها

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

سیاست چرخش به نوع استفاده بستگی دارد:

کلید شخصی: سالی یک بار یا پس از هر حادثه‌ی امنیتی مشکوک.
کلید سازمانی: هر ۹۰ روز یا طبق سیاست امنیتی سازمان.
کلید CI/CD: هر ۶۰ روز یا در هر استقرار production.
کلیدهای موقت: با عمر محدود، پس از پایان استفاده باطل می‌شوند.

فرآیند چرخش بدون قطعی:

کلید جدید بسازید و به GitHub اضافه کنید.
تست کنید که کلید جدید کار می‌کند.
کلید قدیمی را از GitHub حذف کنید.
کلید قدیمی را از agent و دیسک پاک کنید.

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

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

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

امضای commit با کلید SSH

امضای commit با GPG رایج است، اما Git و GitHub از امضای commit با کلید SSH هم پشتیبانی می‌کنند. مزیت این روش، استفاده از همان کلیدی است که برای احراز هویت SSH به کار می‌برید. برای پیکربندی:

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/github_ed25519.pub
git config --global commit.gpgsign true

پس از پیکربندی، هر commit با کلید SSH شما امضا می‌شود و در GitHub با نشان «Verified» نمایش داده می‌شود. این نشان تأیید می‌کند که commit از طرف شما ارسال شده و دستکاری نشده است.

برای اینکه GitHub امضا را تأیید کند، باید کلید امضا را در بخش SSH and GPG keys → New SSH key و با نوع «Signing Key» اضافه کنید. توجه کنید که یک کلید می‌تواند هم به‌عنوان Authentication و هم به‌عنوان Signing استفاده شود، اما بهتر است از دو کلید جداگانه استفاده کنید تا در صورت نشت یکی، دیگری دست‌نخورده بماند.

اشتباهات رایج در مدیریت کلیدهای SSH

نگه‌داشتن کلید خصوصی در مخزن گیت: جدی‌ترین و پرهزینه‌ترین اشتباه. کلید خصوصی هرگز نباید در پروژه قرار بگیرد.
نداشتن رمز کلید: کلید بدون رمز، فقط به امنیت فایل وابسته است.
استفاده از یک کلید برای همه‌ی سرویس‌ها: اگر یک سرویس نفوذ شود، دسترسی همه‌ی سرویس‌ها در معرض خطر است.
نداشتن پیکربندی config: بدون آن، SSH همه‌ی کلیدها را امتحان می‌کند و ممکن است با محدودیت سرور مواجه شود.
استفاده از الگوریتم‌های قدیمی: DSA و RSA با طول کوتاه، امنیت کافی ندارند.
فراموش کردن کلیدهای قدیمی در GitHub: کلیدهایی که دیگر استفاده نمی‌شوند، باید حذف شوند.
اشتراک کلید بین اعضای تیم: هر عضو باید کلید خودش را داشته باشد تا بتوان فعالیت‌ها را ردیابی کرد.
نداشتن پشتیبان از کلید خصوصی: اگر کلید گم شود، دسترسی از دست می‌رود. پشتیبان رمزنگاری‌شده توصیه می‌شود.
نادیده گرفتن هشدارهای امنیتی: اگر GitHub کلید ناشناسی را گزارش داد، بررسی کنید.
بازبینی نکردن کلیدها به‌طور دوره‌ای: کلیدهایی که ماه‌ها استفاده نشده‌اند، باید بازبینی و در صورت لزوم حذف شوند.

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

پرسش‌های پرتکرار درباره SSH در GitHub

آیا باید از SSH یا HTTPS استفاده کنم؟ هر دو امن هستند. SSH برای محیط‌هایی که چند حساب دارید یا نیاز به خودکارسازی دارید راحت‌تر است. HTTPS با توکن برای سناریوهای ساده‌تر مناسب است.

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

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

چطور بفهمم کدام کلید در حال استفاده است؟ دستور ssh -vT git@github.com اطلاعات تفصیلی می‌دهد و نشان می‌دهد کدام کلید انتخاب شده. همچنین ssh-add -l کلیدهای موجود در agent را نمایش می‌دهد.

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

تفاوت کلید Authentication و Signing چیست؟ کلید Authentication برای احراز هویت در زمان اتصال استفاده می‌شود. کلید Signing برای امضای commit و tag. استفاده از دو کلید جداگانه، امنیت را بالا می‌برد.

آیا SSH روی Windows کار می‌کند؟ بله. Windows ۱۰ و ۱۱ شامل OpenSSH client هستند. باید سرویس ssh-agent را فعال کنید و کلیدها را با ssh-add اضافه کنید.

چطور بفهمم یک مخزن با SSH یا HTTPS clone شده است؟ با دستور git remote -v. اگر URL با git@ شروع شود، SSH است؛ اگر با https://، HTTPS.

آیا کلیدهای SSH منقضی می‌شوند؟ کلیدهای معمولی SSH تاریخ انقضا ندارند. اما به دلایل امنیتی، توصیه می‌شود هر سال چرخانده شوند. گواهی‌های SSH دارای تاریخ انقضا هستند.

آیا می‌توانم از یک کلید برای چند حساب GitHub استفاده کنم؟ GitHub اجازه نمی‌دهد یک کلید عمومی به چند حساب اضافه شود. برای هر حساب، کلید جداگانه بسازید.

نگاه مهندسی سطح بالا به احراز هویت با SSH

از منظر معماری امنیتی، SSH یک پروتکل احراز هویت مبتنی بر چالش-پاسخ (Challenge-Response) است. هر اتصال با یک تبادل کلیدی (Key Exchange) آغاز می‌شود که یک کانال رمزنگاری‌شده ایجاد می‌کند. سپس احراز هویت در این کانال انجام می‌شود. این تفکیک دو لایه، امنیت را در برابر حملات شنود و حمله‌ی مرد میانی تقویت می‌کند.

الگوریتم‌های تبادل کلید در SSH از نسخه‌ی ۲ تکامل یافته‌اند. الگوریتم‌هایی مثل Curve25519 و ECDH امنیت بالایی با کارایی خوب فراهم می‌کنند. الگوریتم‌های قدیمی مثل diffie-hellman-group1-sha1 امروز ناامن محسوب می‌شوند و باید در پیکربندی سرور غیرفعال باشند.

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

در لایه‌ی شبکه، محدودسازی دسترسی SSH به IPهای مشخص یک لایه‌ی دفاعی اضافه می‌کند. سرورهای Git معمولاً از این قابلیت استفاده می‌کنند. در GitHub، این محدودسازی برای حساب‌های سازمانی از طریق تنظیمات امنیتی قابل انجام است.

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

از منظر زنجیره‌ی تأمین، SSH فقط یکی از نقاط ورود است. کلیدهای GPG، توکن‌های API و سکرت‌های CI هم به‌طور مشابه باید مدیریت شوند. یک استراتژی کامل مدیریت اعتبارنامه، همه‌ی این نقاط را پوشش می‌دهد. اصول کلی این حوزه با آنچه در Boilerplate های امن چه ویژگی‌هایی باید داشته باشند؟ توضیح داده شده، هم‌راستاست. 🔐

یک نکته‌ی ظریف در سطح رمزنگاری: Ed25519 بر پایه‌ی منحنی Edwards است و از نظر مقاومت در برابر حملات کانال جانبی (Side-Channel) مزیت دارد. این ویژگی در محیط‌هایی که کد روی سخت‌افزار مشترک اجرا می‌شود، اهمیت پیدا می‌کند. انتخاب الگوریتم، فقط یک تصمیم سرعت نیست؛ یک تصمیم معماری است. 🧩

بستن بحث

مدیریت کلیدهای SSH یک کار ساده به نظر می‌رسد، اما در عمل نقش کلیدی در امنیت حساب GitHub دارد. ساخت کلید با الگوریتم مناسب، استفاده از رمز کلید، پیکربندی درست ~/.ssh/config و چرخش دوره‌ای کلیدها، چهار اصل پایه‌ای هستند که بیشتر ریسک‌ها را پوشش می‌دهند.

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

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