ارسال نماینده SSH در برابر کپی کلید: چه چیزی واقعاً نشت می‌کند
ورود با کلید عمومی امضا می‌فرستد، نه کلید خصوصی را. ارسال نماینده همچنان به میزبان دیگری توانایی امضا کردن می‌دهد و این یک درمعرض‌قرارگرفتن جداست.
دو رویداد متفاوت کلید SSH نشت‌کرده نامیده می‌شوند و پاسخ‌های متفاوتی می‌طلبند. احراز هویت با کلید عمومی یک کلید عمومی و امضایی که با کلید خصوصی ساخته شده می‌فرستد، بنابراین کلید خصوصی هرگز فیلدی در درخواست نیست. ارسال نماینده چیز دیگری را آشکار می‌کند، چون میزبان دوری که به نمایندهٔ ارسال‌شدهٔ شما دسترسی دارد می‌تواند بدون آنکه هرگز کلید را در اختیار داشته باشد از آن امضا بخواهد. برخورد با این دو به‌عنوان یک رویداد یا به چرخش بی‌فایدهٔ کلید می‌انجامد یا به تفویضی که فعال می‌ماند.
ورود با کلید عمومی امضا می‌فرستد، نه کلید را
تبادل احراز هویت کلید عمومی کاربر و امضایی بر داده‌های نشست را حمل می‌کند. سرور آن امضا را با کلیدی که از پیش به آن اعتماد دارد بررسی می‌کند، به همین دلیل نیمهٔ خصوصی می‌تواند از طریق شبکه‌ای نامطمئن روی کارخواه بماند. اپراتور VPN که تونل را می‌پاید در هر حال یک نشست SSH رمزنگاری‌شده می‌بیند.
این پروتکل را توصیف می‌کند، نه قابلیت اعتماد هر نقطهٔ پایانی روی مسیر را. بررسی هویت میزبان را دست‌نخورده نگه دارید، چون کارخواهی که هر کلید میزبانی را می‌پذیرد کنترلی متفاوت از آنچه اینجا بحث می‌شود را رها کرده است. نشست شنودشده و کلید شنودشده یافته‌های جداگانه‌ای هستند و تنها یکی از آن‌ها از دست رفتن اعتبارنامه است. این دو را در گزارش هم در جمله‌های جدا نگه دارید.
ssh-keygen -lf ~/.ssh/id_ed25519.pub ssh -o StrictHostKeyChecking=yes [email protected]
فرمان نخست اثر انگشت عمومی را چاپ می‌کند تا آن را با آنچه سرور فهرست می‌کند مقایسه کنید. فرمان دوم بررسی کلید میزبان را صریح می‌کند به‌جای تکیه بر پیش‌فرضی که هیچ‌کس نخوانده است. پیش از تغییر هر چیز دربارهٔ کلیدها هر دو را اجرا کنید تا خط پایه مستند شود.
ارسال نماینده توانایی امضا کردن را تفویض می‌کند
با فعال بودن ارسال، سوکتی روی میزبان دور پدیدار می‌شود و نمایندهٔ محلی به درخواست‌هایی که از آن می‌رسند پاسخ می‌دهد. هر کس در طول نشست بتواند از آن سوکت استفاده کند می‌تواند خود را نزد میزبان‌هایی که هویت‌های بارگذاری‌شده را می‌پذیرند به‌جای شما احراز کند. هیچ کلید خصوصی برای این کار از شبکه عبور نمی‌کند.
آنچه در معرض است توانایی است، نه فایل. به همین دلیل ارسال به یک وظیفهٔ نام‌دار و یک میزبان نام‌دار تعلق دارد، نه به هر اتصالی که یک لپ‌تاپ برقرار می‌کند. میزبان پرشی که اتصال را بدون نمایندهٔ ارسال‌شده عبور می‌دهد معمولاً نیاز را کاملاً برمی‌دارد.
ssh-add -l ssh -o ForwardAgent=no [email protected] ssh -J [email protected] [email protected]
نخستین فرمان فهرست می‌کند که نماینده اکنون کدام هویت‌ها را در اختیار دارد، که پیش از سپردن سوکتش به ماشین دیگر دانستنش می‌ارزد. دومین بدون تفویض متصل می‌شود. سومین الگوی میزبان پرش را نشان می‌دهد که اغلب جای ارسال را کاملاً می‌گیرد.
پاسخ را بر پایهٔ شواهدی که دارید انتخاب کنید
هویت امضایی که گمان می‌رود در معرض قرار گرفته فرایند جایگزینی و ابطال را می‌طلبد و نیز برداشتن پذیرش آن از سرویس‌هایی که به آن اعتماد داشتند. پاک کردن نسخهٔ روی لپ‌تاپ شما هر نسخهٔ دیگری را دست‌نخورده می‌گذارد. از سرویس‌ها شروع کنید و سپس کارخواه‌ها را پاک‌سازی کنید.
مسئلهٔ تفویض موقت باریک‌تر است. ارسالی را که لازم نبود پایان دهید و با صاحب حادثه بررسی کنید کدام نشست‌ها و هویت‌ها را پوشش می‌داد. جایگزینی کلید ممکن است در پی بیاید، اما شواهد این را تعیین می‌کند نه نگرانی.
نبودِ خروجی مشاهده‌شده فقط ثابت می‌کند سازوکاری که از آن می‌ترسیدید پدیدار نشد. دربارهٔ اینکه میزبان طرف دیگر آن سوکت چه کار دیگری می‌توانست بکند هیچ نمی‌گوید.
کنترل‌ها را در گزارش جدا نگه دارید
از مادهٔ خصوصی محافظت کنید، محدود کنید چه کسی می‌تواند از آن امضا بخواهد و هویت طرف مقابل را بررسی‌شده نگه دارید. این‌ها سه کنترلی هستند که یکدیگر را تقویت می‌کنند و هیچ‌کدام جای دیگری را نمی‌گیرد وقتی توضیح می‌دهید چه رخ داده است.
لپ‌تاپ به‌خطرافتاده یا برنامهٔ دارای امتیاز روی آن سومین حالت با شعاع اثر بسیار گسترده‌تر است. تغییر مسیر VPN آن را حل نمی‌کند و اعتماد به کلیدی را که ممکن است از دیسک خوانده شده باشد بازنمی‌گرداند.
بنویسید به کدام مؤلفه اعتماد شده بود، آیا ارسال فعال بود و چه چیزی واقعاً مشاهده شد. همان سابقه است که تصمیم بعدی را قابل دفاع می‌کند، نه حدسی دربارهٔ معنای نشت.