چه کسی واقعاً رمز عبور SSH شما را در یک VPN غیرقابل‌اعتماد می‌بیند؟

یک نشست SSH را از طریق یک VPN که خودتان اداره نمی‌کنید عبور دهید؛ رمز عبور همچنان به سرور SSH تعلق دارد، نه به شبکه میانی. اگر انتقال تا میزبان تأییدشده درست محافظت شده باشد، یک ناظر منفعل در آن مسیر رمز عبور را به شکل خوانا دریافت نمی‌کند. اما یک شرط را تغییر دهید و پاسخ عوض می‌شود: میزبان تأیید‌نشده، فهرست رمزنگاری تضعیف‌شده یا ایستگاه کاری آلوده هر یک نتایج متفاوتی می‌دهند. بررسی‌های زیر را به ترتیب انجام دهید و هر یک را شرط توقف بدانید.

پیش از تایپ هر چیزی، گیرنده را نام ببرید

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

دو جهت را در ذهن جدا نگه دارید. کلید میزبان پاسخ می‌دهد که به کدام سرور رسیدید. احراز هویت با رمز یا کلید پاسخ می‌دهد که سرور کدام کاربر را می‌پذیرد. بهبود دومی هرگز اولی را درست نمی‌کند.

هویت میزبان، سابقه و مذاکره را بررسی کنید

در سمت کلاینت با سابقه‌ای که از قبل دارید شروع کنید. اثر انگشت منتشرشده که با منبعی قابل اعتماد مقایسه شود، و یک ورودی known_hosts که هنوز مطابقت دارد، تنها شواهدی را به شما می‌دهند که پیش از آغاز احراز هویت اهمیت دارد.

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

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

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

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

روش‌هایی را بخوانید که سرور واقعاً می‌پذیرد

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

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

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

هشدار کلید میزبان را مانند یک گام رخداد مدیریت کنید

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

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

چیزی که این راهنما پوشش نمی‌دهد

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

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