ویونیکس
گفت‌وگو با کارشناس
← شروع آموزش

WIUNIX ACADEMY

ورود کوتاه‌مدت با گواهی OpenSSH و آزمون ابطال دسترسی

صفحهٔ 3 از 3؛ مراحل قبلی و پیش‌نیازها را پیش از ادامه مرور کن.

آموزش متناسب با محیط تو

کجا اجرا می‌کنی؟

سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.

Red Hat Enterprise Linux 10بررسی‌شده با مستندات رسمی ·

آموزش متناسب با مقادیر تو

تنظیمات این آموزش

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

آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.

تنظیم مقادیر برای محیط من4 مقدار قابل‌تغییر
11

قدم بعدی

نشان دهید کلید عمومی بدون گواهی کافی نیست

پیش از ابطال، همان کلید را با بارگذاری گواهی غیرفعال امتحان کنید. این listener فایل authorized_keys ندارد، پس ورود با کلید عمومی بدون گواهی باید رد شود؛ درحالی‌که گواهی معتبر همین کلید قبلاً کار کرده است.

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

bash

ترمینال همان میزبان معرفی‌شده در توضیح گام

sudo ssh -F /etc/crypto-policies/back-ends/openssh.config -o StrictHostKeyChecking=yes -o 'UserKnownHostsFile=/var/lib/academy-ssh-cert-lab/known_hosts' -o IdentitiesOnly=yes -o IdentityAgent=none -o CertificateFile=none -i '/var/lib/academy-ssh-cert-lab/client' -p '22222' 'labuser@127.0.0.1'
از کجا بدانم درست انجام شد؟

raw key رد می‌شود و لاگ تأیید می‌کند علت، نبود مجوز گواهی در این مسیر است؛ هر خطای نامرتبطی قبولی نیست.

12

قدم بعدی

فهرست ابطال را جدا بسازید و بررسی کنید

KRL تازه را از همان گواهی بسازید تا serial در محدودهٔ CA امضاکننده باطل شود. نام مقصد باید تازه باشد. قبل از فعال‌سازی، ساختار فهرست و نتیجهٔ query روی گواهی هدف را بخوانید.

خروجی غیرصفر می‌تواند خطای خواندن یا parse هم باشد؛ فقط پس از دیدن نتیجهٔ صریح REVOKED و معتبر بودن KRL ادامه دهید. فهرست فعال را هنگام خواندن daemon درجا بازنویسی نکنید.

bash

ترمینال همان میزبان معرفی‌شده در توضیح گام

sudo test ! -e '/var/lib/academy-ssh-cert-lab/revoked.new' || exit 1
sudo ssh-keygen -k -f '/var/lib/academy-ssh-cert-lab/revoked.new' '/var/lib/academy-ssh-cert-lab/client-cert.pub' || exit 1
sudo ssh-keygen -Q -l -f '/var/lib/academy-ssh-cert-lab/revoked.new' || exit 1
sudo ssh-keygen -Q -f '/var/lib/academy-ssh-cert-lab/revoked.new' '/var/lib/academy-ssh-cert-lab/client-cert.pub'
printf 'query exit=%s (read the explicit result above)\n' "$?"
از کجا بدانم درست انجام شد؟

ساختار KRL معتبر است و همان گواهی صریحاً REVOKED گزارش می‌شود؛ خطای ابزار یا دسترسی را ابطال موفق ندانید.

13

قدم بعدی

فهرست سالم را اتمی جایگزین کنید

پس از بررسی موفق، فایل خالی قبلی را نگه دارید و مالکیت، mode و در محیط RPM برچسب فایل تازه را درست کنید. rename در همان شاخه، فایل فعال را یک‌باره با KRL سالم جایگزین می‌کند.

OpenSSH هنگام احراز هویت RevokedKeys را می‌خواند؛ SSH اصلی نیازی به reload ندارد. نسخهٔ قبل فقط شاهد این تمرین است، نه توصیهٔ برگرداندن مجوز باطل‌شده در محیط عملیاتی.

bash

ترمینال همان میزبان معرفی‌شده در توضیح گام

sudo test ! -e '/var/lib/academy-ssh-cert-lab/revoked.before' || exit 1
sudo cp -- '/var/lib/academy-ssh-cert-lab/revoked' '/var/lib/academy-ssh-cert-lab/revoked.before'
sudo chown root:root '/var/lib/academy-ssh-cert-lab/revoked.new'
sudo chmod 0644 '/var/lib/academy-ssh-cert-lab/revoked.new'
sudo restorecon -v '/var/lib/academy-ssh-cert-lab/revoked.new'
sudo mv -T -- '/var/lib/academy-ssh-cert-lab/revoked.new' '/var/lib/academy-ssh-cert-lab/revoked'
sudo stat -c '%U %G %a %n' '/var/lib/academy-ssh-cert-lab/revoked'
از کجا بدانم درست انجام شد؟

فایل فعال همان KRL بررسی‌شده، با مالک root و دسترسی و برچسب مناسب محیط است.

14

قدم بعدی

همان اتصال موفق را پس از ابطال تکرار کنید

تا گواهی هنوز از نظر زمان معتبر است، دقیقاً همان درخواست قبلی را دوباره بفرستید. اتصال تازه باید رد شود و لاگ daemon دلیل ابطال را نشان دهد.

تمام‌شدن اعتبار، passphrase اشتباه و خاموش‌بودن listener هم باعث شکست می‌شوند، اما اثر KRL را ثابت نمی‌کنند. ابطال، نشست SSH از قبل برقرار را قطع نمی‌کند.

bash

ترمینال همان میزبان معرفی‌شده در توضیح گام

sudo ssh -F /etc/crypto-policies/back-ends/openssh.config -o StrictHostKeyChecking=yes -o 'UserKnownHostsFile=/var/lib/academy-ssh-cert-lab/known_hosts' -o IdentitiesOnly=yes -o IdentityAgent=none -i '/var/lib/academy-ssh-cert-lab/client' -o 'CertificateFile=/var/lib/academy-ssh-cert-lab/client-cert.pub' -p '22222' 'labuser@127.0.0.1'
از کجا بدانم درست انجام شد؟

listener سالم است و گواهی هنوز منقضی نشده؛ بااین‌حال اتصال تازه به دلیل ابطال همان گواهی رد می‌شود.

15

قدم بعدی

فقط آزمایش را متوقف و تغییرات خودش را جمع کنید

در ترمینال اختصاصی Ctrl+C بزنید و نبود listener آزمایش را تأیید کنید. نشست مدیریت، حساب و تنظیم SSH عادی باید سالم و دست‌نخورده باشند. در مسیر RPM، فقط نگاشت پورت و معادل‌سازی برچسبی را که خود این تمرین افزوده، طبق بخش محیط جمع کنید؛ سیاست قبلی را حذف نکنید.

کلیدها و شواهد را تا بازبینی در محیط خصوصی نگه دارید و سپس از چرخهٔ عمر VM برای پایان آزمایش استفاده کنید. CA خصوصی نباید وارد Git یا مرورگر شود. برای محیط عملیاتی، آزمون principal اشتباه و گواهی منقضی و توزیع ابطال هم لازم است.

bash

ترمینال همان میزبان معرفی‌شده در توضیح گام

sudo ss -lntp 'sport = :22222'
از کجا بدانم درست انجام شد؟

listener آزمایش متوقف شده و دسترسی عادی برقرار است؛ فقط تغییرات مشخص خود آزمایش برای جمع‌کردن باقی می‌مانند.

16

قدم بعدی

فقط دو نگاشت افزوده‌شدهٔ همین آزمایش را جمع کنید

این پنل فقط پس از Ctrl+C، تأیید توقف listener و تطبیق یادداشت گام برچسب اجرا می‌شود. فقط اگر هر دو نگاشت را همین تمرین با موفقیت افزوده است، همان پورت و همان معادل‌سازی را حذف کنید. نگاشت قبلی، بازهٔ پورت، پورت 22 و سیاست SSH اصلی دست‌نخورده می‌مانند. اگر افزودن یکی شکست خورد، تنها موردی را جمع کنید که واقعاً افزوده شده است. پس از حذف معادل‌سازی، روی فایل‌های SSH اصلی restorecon اجرا نکنید؛ شاخهٔ خصوصی آزمایش تا پایان چرخهٔ VM استفادهٔ دیگری ندارد.

bash

ترمینال میزبان مجاز معرفی‌شده در همین بخش

sudo ss -lntp 'sport = :22222'
sudo semanage port -l -C
sudo semanage fcontext -l -C
read -r -p 'Type REMOVE-LAB-MAPPINGS only after checking the conditions above: ' academy_policy_confirm
test "$academy_policy_confirm" = REMOVE-LAB-MAPPINGS || exit 1
sudo semanage port -d -t ssh_port_t -p tcp '22222'
sudo semanage fcontext -d -e /etc/ssh '/var/lib/academy-ssh-cert-lab'
sudo semanage port -l -C
sudo semanage fcontext -l -C
از کجا بدانم درست انجام شد؟

فقط نگاشت‌های همین آزمایش حذف شده‌اند؛ listener آزمایش غایب و اتصال مدیریت سالم است.

پشتوانهٔ این آموزش

منابع رسمی

وضعیت بررسی هر محیط بالای صفحه مشخص است؛ بررسی مستندات به معنی اجرای عملی همهٔ نسخه‌ها نیست.

همهٔ آموزش‌های آکادمی ↗