SSH ProxyCommand و احراز هویت مبتنی بر میزبان: کدام میزبان امضا میکند؟
انتقال یک جریان TCP از طریق یک سنگرگاه را از راهاندازی یک کلاینت دوم SSH در همانجا زمانی که احراز هویت مبتنی بر میزبان در میان است، تشخیص دهید.
هدف میتواند اتصال TCP را ببیند که از سنگرگاه میآید، در حالی که کلاینت SSH که احراز هویت را انجام میدهد هنوز روی ایستگاه کاری اجرا میشود.
Host behind-bastion
ProxyCommand ssh -W %h:%p bastionاینجا کمککننده به سنگرگاه وارد میشود و از سرور SSH آن یک اتصال انتقالیافته به هدف میخواهد. کلاینت SSH بیرونی ایستگاه کاری پروتکل SSH هدف را از طریق همان جریان مبادله میکند. سنگرگاه انتقال را فراهم میکند؛ خودش کلاینت SSH رو به هدف را راهاندازی نکرده است.
این تمایز برای احراز هویت مبتنی بر میزبان مهم است. کمککننده ssh-keysign در OpenSSH به کلیدهای میزبان محلی دسترسی میگیرد تا امضای لازم را بسازد. اینکه نشانی مبدأ شبکه مربوط به سنگرگاه باشد باعث نمیشود ایستگاه کاری با کلید میزبان سنگرگاه امضا کند.
این را با مورد زیر مقایسه کنید:
ssh -t bastion ssh targetاین برنامه SSH دیگری را روی سنگرگاه راهاندازی میکند. پیکربندی محلی و کلیدهای میزبانِ در دسترس آن به همان ماشین تعلق دارند، بنابراین میتواند در ترتیبی از اعتماد مبتنی بر میزبان که پیشتر بین سنگرگاه و هدف تنظیم شده مشارکت کند. با این حال هنوز به مجوز متناظر و بررسی نام در سمت هدف نیاز دارد.
شکل دوم نحوه کار نشست را هم تغییر میدهد: یک فرمان راه دور اجرا میکند و از ترمینال استفاده میکند. جایگزین شفافی برای هر انتقال فایل SSH یا انتقال خودکارسازی نیست. ترتیب را بر اساس اینکه کدام ماشین باید در برابر هدف احراز هویت کند برگزینید، نه با تضعیف بررسیهای اعتماد سرور تا نشانی مبدأ کافی به نظر برسد.