آموزش لینوکس پیشرفته؛ مدیریت، امنیت و عیب‌یابی سرور

سناریو: برای دسترسی به یک برنامهٔ داخلی باید از میزبان واسط عبور کنید و برای هر میزبان کلید جداگانه دارید. تکرار گزینه‌ها احتمال اشتباه در نام کاربر، هویت و مسیر اتصال را بالا می‌برد. هدف، ساخت نام‌های مستعار روشن و بررسی تصمیم کلاینت پیش از اتصال است. تمرین فقط یک فایل محلی می‌سازد؛ به سرور وصل نمی‌شود و تنظیمات sshd، ورود root یا روش ورود یک سرور موجود را تغییر نمی‌دهد.

نام مستعار باید قرارداد اتصال را روشن کند

Host نامی است که هنگام اجرای ssh می‌نویسید و HostName مقصد واقعی آن را تعیین می‌کند. IdentityFile مسیر هویت کلاینت است؛ این کلید با کلید میزبان که هویت سرور را ثابت می‌کند تفاوت دارد. IdentitiesOnly yes مجموعهٔ هویت‌های قابل‌ارائه را به هویت‌های پیکربندی‌شده محدود می‌کند تا کلیدهای اضافی agent خودکار پیشنهاد نشوند؛ به‌معنای خاموش‌شدن کامل agent نیست. مسیر نمونهٔ زیر فرضی است و برای ارزیابی پیکربندی لازم نیست هیچ کلید خصوصی بسازید یا محتوایش را نمایش دهید.

ssh_lab=$(mktemp -d)

متن زیر را با ویرایشگر در فایل config داخل پوشهٔ معرفی‌شده با متغیر ssh_lab ذخیره کنید. نام‌های دارای پسوند invalid عمداً برای نمونه‌اند. میزبان واسط و مقصد تنظیمات جدا دارند؛ گزینه‌های مخصوص مقصد معمولاً تنظیمات میزبان واسط را تعیین نمی‌کنند. بخش‌های خاص را پیش از Host * قرار می‌دهیم، چون برای بیشتر گزینه‌ها نخستین مقدار به‌دست‌آمده استفاده می‌شود. IdentityFile استثنای مهمی است و تکرار آن می‌تواند چند هویت به فهرست اضافه کند.

Host course-gateway
    HostName jump.example.invalid
    User learner
    IdentityFile ~/.ssh/course_gateway_ed25519
    IdentitiesOnly yes

Host course-app
    HostName app.internal.example.invalid
    User learner
    IdentityFile ~/.ssh/course_app_ed25519
    IdentitiesOnly yes
    ProxyJump course-gateway

Host *
    ForwardAgent no
    StrictHostKeyChecking yes
    ConnectTimeout 5

ProxyJump از واسط برای رساندن اتصال TCP به مقصد کمک می‌گیرد؛ کلاینت شما هویت مقصد را جداگانه بررسی می‌کند. برای این مسیر لازم نیست ForwardAgent را روشن کنید. با agent forwarding، فردی که روی میزبان دوردست به سوکت agent دسترسی مؤثر پیدا کند می‌تواند از هویت‌های بارگذاری‌شده برای احراز هویت استفاده کند، هرچند کلید خصوصی را استخراج نکند. بنابراین ForwardAgent no را صریح نگه می‌داریم. دسترسی مجاز واسط به مقصد نیز شرط جداگانه‌ای است.

ssh -F "$ssh_lab/config" -G course-app |
  awk '$1 ~ /^(hostname|user|identityfile|identitiesonly|proxyjump|forwardagent|stricthostkeychecking|connecttimeout)$/ {print}'

گزینهٔ -G پیکربندی ارزیابی‌شده را چاپ می‌کند و برای این نمونه اتصال نمی‌سازد؛ -F فایل مستقل ما را انتخاب می‌کند. انتظار داریم hostname مقصد داخلی، user برابر learner، proxyjump برابر course-gateway و forwardagent برابر no باشد. نمایش yes به شکل true در بعضی خروجی‌ها طبیعی است. این آزمایش وجود کلید، دسترسی شبکه یا موفقیت احراز هویت را ثابت نمی‌کند. پیکربندی ناشناس را صرفاً برای آزمایش وارد نکنید: گزینه‌هایی مانند Match exec می‌توانند هنگام ارزیابی فرمان اجرا کنند.

اعتماد به کلید میزبان، یک چرخهٔ عمر دارد

پیش از نخستین اتصال واقعی، کلید عمومی میزبان یا اثرانگشت SHA256 آن را از مسیری مستقل و احراز‌شده، مانند کنسول مدیریتی یا مسئول شناخته‌شده، بگیرید. اثرانگشت باید با کلید همان میزبان، الگوریتم و پورت تطبیق داده شود. اثرانگشت به‌تنهایی خط معتبر known_hosts نیست؛ فایل اعتماد به نام میزبان و دادهٔ کلید عمومی نیاز دارد. StrictHostKeyChecking yes در نبود کلید ازپیش‌تأییدشده اتصال را رد می‌کند، بنابراین آماده‌سازی اعتماد باید پیش از اتصال انجام شود.

برای مشاهدهٔ اثرانگشت یک فایل عمومی تأییدشده می‌توان از ssh-keygen -l -E sha256 -f استفاده کرد. برای یافتن رکورد موجود، ssh-keygen -F با نام میزبان و فایل known_hosts مناسب به‌کار می‌رود؛ برای پورت غیراستاندارد شکل [host]:port اهمیت دارد. خروجی جمع‌آوری‌شده با ssh-keyscan به‌تنهایی هویت سرور را تأیید نمی‌کند. کلید خصوصی، عبارت عبور یا محتوای فایل‌های محرمانه را داخل فرمان یا خروجی آموزشی نگذارید.

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

تمرین و پاسخ: اگر -G نام مقصد و ProxyJump را درست نشان داد اما اخطار تغییر کلید گرفتید، آیا آمادهٔ ورود هستید؟ خیر؛ ارزیابی محلی فقط انتخاب تنظیمات را تأیید کرده است. مسیر دسترسی و اعتماد میزبان دو تصمیم مستقل‌اند. اثرانگشت جدید و رویداد تغییر را خارج از همان اتصال بررسی کنید؛ پس از تطبیق معتبر، رکورد مربوط را اصلاح کنید. خاموش‌کردن بررسی کلید یا روشن‌کردن agent forwarding پاسخی به این اخطار نیست.

منابع رسمی انگلیسی:
ssh_config: https://man.openbsd.org/ssh_config
ssh: https://man.openbsd.org/ssh
ssh-keygen: https://man.openbsd.org/ssh-keygen

تألیف و مثال‌های اختصاصی: تحریریه درس‌آوند. منابع رسمی انگلیسی برای مطالعهٔ تکمیلی معرفی شده‌اند.