أزواج مفاتيح SSH تتفشى كالمشكلة. الشهادات هي الحل.

أزواج مفاتيح SSH تعمل جيدًا لثلاثة خوادم. عند الثلاثين، تصبح مسؤولية أمنية. عند ثلاثمئة، تصبح كابوسًا للامتثال. المفاتيح القديمة تتراكم دون فرض انتهاء صلاحية، ولا آلية إبطال مركزي، ولا أثر تدقيق يربط المفتاح بحالة تسجيل دخول محددة. شهادات SSH تحل هذه المشاكل الثلاث دون تغيير أي شيء في كيفية اتصال المهندسين بالخوادم.

مشكلة انتشار مفاتيح SSH

متوسط عمر مفتاح SSH في مؤسسة تضم أكثر من 100 مهندس هو 4.3 سنوات، وفقًا لمسح Venafi لعام 2024 حول إدارة هويات الآلات. ينضم المهندسون، ينشئون زوج مفاتيح، يلصقون مفتاحهم العام في authorized_keys على كل خادم يحتاجونه، ثم — لا شيء يتغير عندما يغادرون. قوائم الخروج من المؤسسة تفتقد الخوادم. المفاتيح تبقى حية.

المشاكل الهيكلية لأزواج مفاتيح SSH على نطاق واسع:

• لا انتهاء صلاحية. المفتاح الذي أُنشئ في 2019 لا يزال صالحًا في 2026 ما لم يزله أحد يدويًا من كل ملف authorized_keys على كل خادم أُضيف إليه.
• لا إبطال مركزي. إذا سُرق مفتاح خاص أو فُقد جهاز كمبيوتر محمول، فإن إبطال الوصول يعني الاتصال بـ SSH بكل خادم متأثر وتحرير authorized_keys. في بيئة تضم 200 خادم، يستغرق هذا ساعات — إذا كنت تعرف حتى أي الخوادم تمتلك المفتاح.
• لا أثر تدقيق. sshd يسجل أي بصمة مفتاح صادقت على جلسة، لكن لا يوجد سجل موثوق يربط تلك البصمة بهوية مهندس معين وقت الإصدار. بصمات المفاتيح ليست هويات.
• خطر الحركة الجانبية. المفتاح المسروق يمنح الوصول إلى كل خادم أُضيف إليه. لا يوجد تقييد للنطاق، ولا حد زمني، ولا طريقة لتقييد المفتاح بعنوان IP محدد بعد الإصدار.

لا شيء من هذه افتراضي. اختراق تويتر عام 2020 تضمن مخترقًا داخليًا استخدم وصول SSH عبر الهندسة الاجتماعية. انتشار المفاتيح جعل تحديد نطاق الحادثة أصعب بكثير.

كيف تعمل شهادات SSH

هيئة الشهادات SSH (CA) هي ببساطة زوج مفاتيح SSH — عادة ed25519. بدلاً من توزيع مفاتيح المستخدم العامة على الخوادم، تقوم بتكوين الخوادم لتثق بالمفتاح العام لهيئة الشهادات. ثم توقع هيئة الشهادات مفاتيح المستخدم العامة الفردية لإنتاج شهادات.

شهادة SSH الموقعة تتضمن الحقول التالية:

• المبادئ (Principals): قائمة أسماء المستخدمين أو المجموعات التي تكون الشهادة صالحة لها (مثل alice، eng-team)
• صالح بعد / صالح قبل: طوابع زمنية صلبة — الشهادة غير صالحة تشفيريًا خارج هذه النافذة
• تقييد عنوان المصدر: نطاق IP اختياري يمكن استخدام الشهادة منه
• الامتدادات: قدرات مثل permit-pty، permit-port-forwarding، permit-agent-forwarding — يمكن منح أو رفض كل منها لكل شهادة
• الرقم التسلسلي للشهادة: معرف فريد يظهر في سجلات المصادقة sshd

ملف sshd_config للخادم يحتوي على سطر واحد: TrustedUserCAKeys /etc/ssh/ca_user_key.pub. هذا هو التغيير الوحيد المطلوب في التكوين. لا مزيد من إدارة ملفات authorized_keys.

إعداد هيئة شهادات خاصة بك في 15 دقيقة

لا تحتاج إلى Teleport أو HashiCorp Vault للبدء. OpenSSH يأتي مع كل ما هو مطلوب.

الخطوة 1 — إنشاء مفتاح هيئة الشهادات على مضيف آمن:

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

احتفظ بـ ca_user_key (خاص) دون اتصال أو في مدير أسرار. وزع ca_user_key.pub على كل خادم.

الخطوة 2 — تكوين sshd على كل خادم:

TrustedUserCAKeys /etc/ssh/ca_user_key.pub

أعد تحميل sshd. سيقبل الخادم الآن أي شهادة موقعة من هيئة الشهادات هذه، مع مراعاة قيود المبدأ والصلاحية.

الخطوة 3 — إصدار شهادة لمستخدم:

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

ينتج هذا alice-cert.pub. العلامة -I تحدد معرف المفتاح (يُسجل عند المصادقة)، -n alice تحدد المبدأ، -V +8h تجعله صالحًا لمدة 8 ساعات من الآن.

الخطوة 4 — المستخدم يتصل بشكل عادي:

ssh alice@prod-server-01

OpenSSH يقدم الشهادة تلقائيًا بجانب المفتاح الخاص. لا تغيير في سير عمل المستخدم.

شهادات قصيرة العمر + منصات الهوية

إصدار الشهادات يدويًا يعمل للفرق الصغيرة. للإنتاج على نطاق واسع، تحتاج إلى إصدار آلي مرتبط بموفر الهوية الخاص بك.

Teleport يعمل كـ هيئة شهادات SSH وطبقة وكيل. المهندسون يصادقون عبر Okta أو Azure AD SSO، يصدر Teleport شهادة قصيرة العمر (افتراضيًا 12 ساعة)، ويتم تسجيل كل نشاط الجلسة. إبطال الوصول يعني إزالة المستخدم من مجموعة IdP — دون تغيير في الخادم.

محرك أسرار SSH في HashiCorp Vault يوفر وظيفة هيئة الشهادات دون طبقة الوكيل. قم بتكوين دور 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 — ادفع مفتاحًا عامًا مؤقتًا (صالح 60 ثانية)، اتصل، انتهى. لا يوجد authorized_keys دائم على الإطلاق.

إبطال المفتاح في أي من هذه الأنظمة فوري. إيقاف هيئة الشهادات عن إصدار شهادات جديدة لمستخدم يعني أن جميع شهاداته الحالية ستنتهي في غضون ساعات على الأكثر. قارن ذلك بتتبع إدخالات المفاتيح يدويًا عبر مئات الخوادم.

شهادات المضيف: النصف الآخر

شهادات SSH تعمل في كلا الاتجاهين. شهادات المستخدم توثق المستخدمين للخوادم؛ شهادات المضيف توثق الخوادم للمستخدمين.

بدون شهادات المضيف، يستخدم SSH TOFU (الثقة عند أول استخدام) — في أول مرة تتصل بمضيف، يُطلب منك قبول بصمته. هذا عرضة لهجمات MITM عبر مفاتيح مضيف مزيفة، والطلب يدرب المهندسين على النقر عبر تحذيرات الأمان.

مع هيئة شهادات مضيف، توقع مفتاح مضيف كل خادم:

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

أضف هيئة الشهادات إلى known_hosts للعميل:

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

الآن كل خادم في أسطولك موثوق تلقائيًا من قبل كل عميل. لا طلبات بصمة. لا TOFU. إذا تم اختراق خادم وتغير مفتاح مضيفه، سترفض العملاء الاتصال فورًا.

أثر التدقيق الذي تحصل عليه فعلاً

مع المصادقة القائمة على الشهادات، كل حدث تسجيل دخول يحمل رقماً تسلسلياً للشهادة. قم بتمكين التسجيل المفصل في 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:...

الرقم التسلسلي 42 يعود إلى إدخال إصدار محدد في Vault أو حدث تدقيق في Teleport مع سياق الهوية الكامل: من طلب الشهادة، متى، من أي IP، بعد المصادقة عبر أي طريقة MFA. هذا هو أثر التدقيق الذي تحتاجه أدوات SIEM ومدققي الامتثال فعلاً — ليس بصمة مفتاح منفصلة عن أي هوية.

مسار الترحيل

ترحيل أسطول حالي بسيط إذا تم بالترتيب:

• التدقيق أولاً. قم بتشغيل find / -name authorized_keys 2>/dev/null عبر أسطولك (أو استخدم أداة إدارة التكوين). وثق كل مفتاح، متى أُضيف، ومن يملكه.
• أضف ثقة هيئة الشهادات دون إزالة المفاتيح الموجودة. أضف TrustedUserCAKeys إلى sshd_config على جميع الخوادم. المصادقة القائمة على المفاتيح الحالية تستمر في العمل.
• أصدر شهادات لجميع المهندسين. اطلب من كل مهندس إنشاء زوج مفاتيح جديد وتوقيعه، أو الانضمام إلى Teleport/Vault للحصول على إصدار شهادات آلي.
• شغل بالتوازي لمدة 30 يومًا. كلا الطريقتين تعملان خلال هذه النافذة. راقب سجلات المصادقة لتأكيد أن جميع عمليات تسجيل الدخول الإنتاجية تأتي عبر الشهادات.
• أزل المفاتيح الخام. بعد 30 يومًا من عمليات تسجيل الدخول النظيفة عبر الشهادات فقط، أزل إدخالات authorized_keys القديمة.
• مفتاح الطوارئ (break-glass). احتفظ بزوج مفاتيح طويل الأمد واحد في خزنة أسرار محكمة (مثل HashiCorp Vault مع سياسة break-glass) للوصول الطارئ إذا أصبحت هيئة الشهادات غير متاحة. دقق الوصول إليه ربع سنويًا.

الترحيل لا يتطلب أي فترة توقف، والمهندسون لا يلاحظون أي تغيير تقريبًا في سير عملهم اليومي — باستثناء أنهم لم يعدوا يتلقون طلبات بصمة الخوادم الجديدة.

الخلاصة

SSH القائم على الشهادات ليس أكثر تعقيدًا في الاستخدام من المصادقة القائمة على المفاتيح. بالنسبة للمهندسين، التجربة متطابقة أو أبسط — لا توزيع يدوي للمفاتيح، لا طلبات بصمة، لا "الصق مفتاحك العام في خيط Slack هذا". لفرق الأمان، يوفر تحكمًا مركزيًا، إبطال فوري، صلاحية مفروضة، وأثر تدقيق لكل جلسة مربوط بهويات حقيقية. الأدوات — OpenSSH، Teleport، HashiCorp Vault، AWS EC2 Instance Connect — ناضجة وموثقة جيدًا. الشيء الوحيد الذي يمنع معظم الفرق من التبديل هو الجمود.