مشکل گستردگی جفت‌کلیدهای SSH؛ گواهی‌ها راه‌حل

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

مشکل گستردگی کلیدهای SSH

طبق نظرسنجی Venafi در مورد مدیریت هویت ماشین‌ها در سال ۲۰۲۴، میانگین طول عمر یک کلید SSH در سازمان‌های با بیش از ۱۰۰ مهندس ۴.۳ سال است. مهندسان جدید می‌آیند، یک جفت‌کلید می‌سازند، کلید عمومی را در authorized_keys هر سروری که نیاز دارند paste می‌کنند و بعد – وقتی می‌روند، چیزی تغییر نمی‌کند. چک‌لیست‌های خروج برخی سرورها را از قلم می‌اندازند. کلیدها به حیات خود ادامه می‌دهند.

مشکلات ساختاری جفت‌کلیدهای SSH در مقیاس بزرگ:

• بدون تاریخ انقضا. کلیدی که در ۲۰۱۹ ساخته شده تا ۲۰۲۶ هم معتبر است مگر اینکه کسی دستی آن را از تمام فایل‌های authorized_keys در تمام سرورهایی که اضافه شده حذف کند.
• بدون ابطال متمرکز. اگر کلید خصوصی دزدیده شود یا لپ‌تاپ گم شود، برای لغو دسترسی باید SSH بزنید به هر سرور و authorized_keys را ویرایش کنید. در محیطی با ۲۰۰ سرور این کار ساعت‌ها طول می‌کشد – اگر اصلاً بدانید که کلید در کدام سرورها هست.
• بدون لاگ حسابرسی. sshd لاگ می‌کند که کدام fingerprint کلید یک نشست را احراز هویت کرده، اما هیچ رکورد معتبری وجود ندارد که آن fingerprint را به هویت یک مهندس خاص در زمان صدور متصل کند. Fingerprint کلیدها هویت نیستند.
• ریسک حرکت جانبی. یک کلید دزدیده شده به همه سرورهایی که در آن اضافه شده دسترسی می‌دهد. هیچ محدودیت دامنه، مرز زمانی یا راهی برای محدود کردن کلید به IP منبع خاص پس از صدور وجود ندارد.

هیچکدام از اینها فرضی نیستند. نقض امنیتی توییتر در سال ۲۰۲۰ شامل یک فرد داخلی بود که با مهندسی اجتماعی دسترسی SSH گرفته بود. گستردگی کلیدها دامنه‌بندی حادثه را بسیار سخت‌تر کرد.

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

یک مرجع صدور گواهی SSH (CA) خودش یک جفت‌کلید SSH است – معمولاً ed25519. به جای توزیع کلیدهای عمومی کاربران روی سرورها، سرورها را طوری تنظیم می‌کنید که به کلید عمومی CA اعتماد کنند. سپس CA کلیدهای عمومی هر کاربر را امضا می‌کند و گواهی تولید می‌کند.

یک گواهی SSH امضا شده شامل فیلدهای زیر است:

• Principals: لیست نام‌کاربری یا گروه‌هایی که این گواهی برای آنها معتبر است (مثلاً alice، eng-team)
• Valid after / Valid before: timestamp‌های سخت – گواهی خارج از این بازه از نظر رمزنگاری نامعتبر است
• Source address restriction: محدوده IP اختیاری که می‌توان از آن گواهی استفاده کرد
• Extensions: قابلیت‌هایی مثل permit-pty، permit-port-forwarding، permit-agent-forwarding – هر کدام می‌توانند در هر گواهی داده یا رد شوند
• Certificate serial number: یک شناسه یکتا که در لاگ‌های احراز هویت sshd ظاهر می‌شود

فایل sshd_config سرور فقط یک خط دارد: TrustedUserCAKeys /etc/ssh/ca_user_key.pub. این تنها تغییر تنظیمات لازم است. دیگر خبری از مدیریت فایل‌های authorized_keys نیست.

راه‌اندازی CA خودتان در ۱۵ دقیقه

برای شروع نیازی به Teleport یا HashiCorp Vault ندارید. OpenSSH همه چیز مورد نیاز را همراه خود دارد.

مرحله ۱ – تولید کلید CA روی یک میزبان امن:

ssh-keygen -t ed25519 -f /etc/ssh/ca_user_key -C "SSH User CA"

کلید خصوصی ca_user_key را آفلاین یا در یک secrets manager نگه دارید. کلید عمومی ca_user_key.pub را به همه سرورها توزیع کنید.

مرحله ۲ – تنظیم sshd روی هر سرور:

TrustedUserCAKeys /etc/ssh/ca_user_key.pub

sshd را reload کنید. سرور اکنون هر گواهی امضا شده توسط این CA را می‌پذیرد، مشروط به محدودیت‌های principal و اعتبار.

مرحله ۳ – صدور گواهی برای یک کاربر:

ssh-keygen -s ca_user_key -I "[email protected]" -n alice -V +8h alice.pub

این دستور alice-cert.pub را تولید می‌کند. پرچم -I key ID را تنظیم می‌کند (در لاگ احراز هویت ثبت می‌شود)، -n alice principal را تعیین می‌کند، -V +8h گواهی را برای ۸ ساعت از الان معتبر می‌کند.

مرحله ۴ – کاربر به طور عادی متصل می‌شود:

ssh alice@prod-server-01

OpenSSH به صورت خودکار گواهی را همراه کلید خصوصی ارائه می‌دهد. تغییری در workflow کاربر ایجاد نمی‌شود.

گواهی‌های کوتاه‌مدت + پلتفرم‌های هویتی

صدور دستی گواهی برای تیم‌های کوچک خوب است. برای تولید در مقیاس بزرگ، به صدور خودکار متصل به identity provider خود نیاز دارید.

Teleport هم به عنوان SSH CA و هم به عنوان یک لایه پروکسی عمل می‌کند. مهندسان از طریق Okta یا Azure AD SSO احراز هویت می‌کنند، Teleport یک گواهی کوتاه‌مدت (پیش‌فرض ۱۲ ساعت) صادر می‌کند و تمام فعالیت نشست ضبط می‌شود. لغو دسترسی یعنی حذف کاربر از گروه IdP – بدون نیاز به تغییر در سرورها.

HashiCorp Vault SSH Secrets Engine قابلیت CA را بدون لایه پروکسی فراهم می‌کند. یک نقش Vault تنظیم کنید:

vault write ssh/roles/eng-ssh \
  key_type=ca \
  allowed_users="*" \
  default_user=ubuntu \
  ttl=8h \
  max_ttl=24h \
  allowed_extensions="permit-pty,permit-port-forwarding"

مهندسان به Vault احراز هویت می‌کنند (از طریق OIDC/Okta/Azure AD + MFA)، با دستور vault ssh -role eng-ssh -mode ca -mount-point ssh user@host درخواست گواهی می‌دهند و یک گواهی محدود به زمان دریافت می‌کنند. Vault هر صدور را با هویت درخواست‌کننده لاگ می‌کند.

AWS EC2 Instance Connect به صورت بومی از همین مدل برای نمونه‌های EC2 استفاده می‌کند – یک کلید عمومی موقت (معتبر ۶۰ ثانیه) ارسال می‌کند، متصل می‌شوید، تمام. هیچ authorized_keys دائمی وجود ندارد.

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

گواهی‌های میزبان: نیمه دیگر

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

بدون گواهی‌های میزبان، SSH از روش TOFU (Trust On First Use) استفاده می‌کند – اولین باری که به یک میزبان متصل می‌شوید، از شما خواسته می‌شود fingerprint آن را بپذیرید. این روش در برابر حملات MITM با کلیدهای میزبان جعلی آسیب‌پذیر است و این اخطار مهندسان را به نادیده گرفتن هشدارهای امنیتی عادت می‌دهد.

با یک Host CA، کلید میزبان هر سرور را امضا می‌کنید:

ssh-keygen -s ca_host_key -I "prod-server-01" -h -n prod-server-01,10.0.1.5 -V +52w /etc/ssh/ssh_host_ed25519_key.pub

CA را به known_hosts کلاینت اضافه کنید:

@cert-authority *.internal.example.com ssh-ed25519 AAAA... SSH Host CA

حالا هر سرور در ناوگان شما به صورت خودکار توسط همه کلاینت‌ها trusted است. خبری از اخطار fingerprint نیست. خبری از TOFU نیست. اگر سروری به خطر بیفتد و کلید میزبانش تغییر کند، کلاینت‌ها بلافاصله اتصال را رد می‌کنند.

لاگ حسابرسی واقعی که به دست می‌آورید

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

LogLevel VERBOSE

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

Accepted publickey for alice from 10.0.1.22 port 52341 ssh2: ED25519-CERT SHA256:... ID [email protected] (serial 42) CA ED25519 SHA256:...

شماره سریال ۴۲ به یک ورودی لاگ صدور خاص در Vault یا رویداد حسابرسی Teleport برمی‌گردد با زمینه کامل هویت: چه کسی گواهی را درخواست کرده، چه زمانی، از چه IP، پس از احراز هویت با چه روش MFA. این همان لاگ حسابرسی است که ابزارهای SIEM و حسابرسان انطباق واقعاً به آن نیاز دارند – نه یک fingerprint کلید که از هرگونه هویت جدا شده است.

مسیر مهاجرت

مهاجرت یک ناوگان موجود اگر به ترتیب انجام شود straightforward است:

• ابتدا حسابرسی کنید. دستور find / -name authorized_keys 2>/dev/null را در کل ناوگان خود اجرا کنید (یا از ابزار مدیریت پیکربندی استفاده کنید). هر کلید، زمان اضافه شدن و مالک آن را مستند کنید.
• اعتماد CA را بدون حذف کلیدهای موجود اضافه کنید. TrustedUserCAKeys را به sshd_config همه سرورها اضافه کنید. احراز هویت مبتنی بر کلید قبلی همچنان کار می‌کند.
• برای همه مهندسان گواهی صادر کنید. از هر مهندس بخواهید یک جفت‌کلید جدید بسازد و امضا بگیرد، یا در Teleport/Vault ثبت‌نام کند تا صدور خودکار گواهی داشته باشد.
• به مدت ۳۰ روز هر دو روش را فعال نگه دارید. در این بازه هر دو روش کار می‌کنند. لاگ‌های احراز هویت را زیر نظر بگیرید تا مطمئن شوید همه لاگین‌های تولید از طریق گواهی انجام می‌شود.
• کلیدهای خام را حذف کنید. پس از ۳۰ روز لاگین فقط با گواهی، ورودی‌های قدیمی authorized_keys را حذف کنید.
• یک کلید break-glass نگه دارید. یک جفت‌کلید طولانی‌مدت در یک secrets vault مهر و موم شده (مثلاً HashiCorp Vault با سیاست break-glass) برای دسترسی اضطراری نگه دارید. دسترسی به آن را هر سه ماه یکبار حسابرسی کنید.

مهاجرت نیازی به downtime ندارد و مهندسان تقریباً هیچ تغییری در workflow روزمره خود نمی‌بینند – جز اینکه دیگر برای سرورهای جدید درخواست fingerprint نمی‌شود.

نتیجه‌گیری

SSH مبتنی بر گواهی استفاده پیچیده‌تری از احراز هویت با کلید ندارد. برای مهندسان تجربه یکسان یا ساده‌تر است – بدون توزیع دستی کلید، بدون درخواست fingerprint، بدون «کلید عمومی‌تان را در این اسلک ترد paste کنید.» برای تیم‌های امنیتی، کنترل متمرکز، ابطال فوری، انقضای اجباری و لاگ حسابرسی برای هر نشست که به هویت‌های واقعی متصل است فراهم می‌کند. ابزارها – OpenSSH، Teleport، HashiCorp Vault، AWS EC2 Instance Connect – بالغ و مستند هستند. تنها چیزی که اکثر تیم‌ها را از انتقال باز می‌دارد اینرسی است.