Lab: SSH hardening'ni o'zingizni qulflab qo'ymasdan joriy qilish

SSH hardening maqolasida to'liq checklist va har bir band ortidagi mulohaza bayon qilingan edi. Bu lab o'sha checklist’ni bir martalik mashinada to'g'ri, xavfsiz tartibda qo'llashning amaliy mashqi. U odamlarni qulflab qo'yadigan yagona xatoni — kalitga asoslangan login haqiqatan ishlashini tasdiqlashdan oldin parol autentifikatsiyasini o'chirib qo'yishni — ham ataylab qiladi. Shunda nosozlik ham, undan tiklanish ham muhim serverda sodir bo'lishidan oldin tanish bo'ladi.

Maqsad va yakuniy natija

Bu lab oxirida lab VM faqat kalitga asoslangan SSH autentifikatsiyasini qabul qiladi, root sifatida to'g'ridan-to'g'ri kirishni rad etadi va kirishni bitta nomlangan foydalanuvchi bilan cheklaydi. Siz esa zaxira yo'lni juda erta o'chirib qo'yish natijasida yuzaga kelgan qulflanishni shaxsan boshdan kechirgan va undan tiklangan bo'lasiz.

Topologiya va boshlang'ich holat

Butun lab davomida bir xil lab VM’ga ikkita terminal sessiyasi kerak: o'zgarishlar kiritiladigan asosiy sessiya va o'zgarish SSH kirishini buzsa, qaytish yo'lini ta’minlaydigan, ochiq va tegilmagan holda saqlanadigan zaxira sessiya. Bu SSH hardening maqolasining o'z takroriy ogohlantirishini aks ettiradi va bu lab aynan uni o'tkazib yuborish og'riqli bo'lishi uchun tuzilgan.

Talablar

SSH orqali ulanish mumkin bo'lgan lab VM, ideal holda haqiqiy oxirgi chora sifatida SSH’dan mustaqil konsol kirishi bilan (hypervisor konsoli yoki jismoniy kirish);
klient mashinangizda allaqachon yaratilgan SSH kalit juftligi (agar yaratish kerak bo'lsa, SSH kalit autentifikatsiyasi ga qarang).

Xavfsizlik va snapshot haqida eslatma

Danger

Bu lab /etc/ssh/sshd_config ni o'zgartiradi va qulflanish holatini ataylab yuzaga keltiradi. Buni faqat haqiqiy zaxira yo'l sifatida konsol kirishi bor bir martalik lab VM’da bajaring. SSH yagona kirish yo'li bo'lgan va konsol mavjud bo'lmagan serverda hech qachon bajarmang. Boshlashdan oldin konfiguratsiya faylining zaxira nusxasini oling:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.lab-backup

ssh-copy-id -i ~/.ssh/id_ed25519.pub <username>@<vm-ip>

Yangi sessiyadan tekshiring (kalitni nusxalash uchun hozirgina ishlatganingizdan emas):

ssh -i ~/.ssh/id_ed25519 <username>@<vm-ip> "echo key auth works"

key auth works

Aynan shu tekshiruv muvaffaqiyatli bo'lmaguncha davom etmang. Bu labdagi keyingi har bir qadam u muvaffaqiyatli bo'lgan deb hisoblaydi.

2-qadam: kirishni nomlangan foydalanuvchi bilan cheklash

sudo sed -i '/^AllowUsers/d' /etc/ssh/sshd_config
echo "AllowUsers <username>" | sudo tee -a /etc/ssh/sshd_config
sudo sshd -t

sshd -t konfiguratsiyani qayta yuklamasdan uning sintaksisini tekshiradi. sshd ni qayta ishga tushirishdan oldin buni har doim bajaring. Qayta ishga tushirishdan oldin ushlangan sintaksis xatosi besh soniyalik tuzatish, ulanish uzilib qolgan holda qayta ishga tushirishdan keyin ushlangan xuddi shu xato esa tiklanish ancha qiyin bo'lgan muammo.

Unit Debian/Ubuntu’da ssh, RHEL’da sshd

Servis unit’ining nomi distributivga qarab farq qiladi: Debian va Ubuntu’da SSH daemon’ining unit’i ssh.service (shuning uchun systemctl reload ssh dan foydalaning), RHEL, CentOS va Fedora’da esa sshd.service (systemctl reload sshd). Ubuntu’da systemctl reload sshd ni ishga tushirish Unit sshd.service not found bilan muvaffaqiyatsiz tugaydi — bu haqiqatan keng tarqalgan birinchi qoqilish. Ishonchingiz komil bo'lmasa, tizimingizdagi nomni systemctl list-units 'ssh*' bilan tasdiqlang. Shuningdek, e’tibor bering: konfiguratsiyani tekshirish binary’si distributivdan qat’i nazar har doim sshd -t, bu yerda restart emas, reload ishlatilishi esa ataylab qilingan. reload konfiguratsiyani mavjud SSH ulanishlarini uzmasdan qayta o'qiydi, shuning uchun xato o'z sessiyangizni darhol uzib qo'ymaydi.

sudo systemctl reload sshd   # 'ssh' on Debian/Ubuntu — see the note above

Yangi sessiyadan tekshirish:

ssh <username>@<vm-ip> "whoami"

Bu qadam muvaffaqiyatli bo'lgan bo'lsa ham, zaxira sessiyani (0-qadam talabi) butun jarayon davomida ochiq saqlang — uni hali yopmang.

3-qadam: root sifatida to'g'ridan-to'g'ri kirishni o'chirib qo'yish

sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sshd -t && sudo systemctl reload sshd

Tekshirish:

ssh root@<vm-ip>

root@<vm-ip>: Permission denied (publickey).

4-qadam: ataylab qilingan xato — zaxira yo'lni tekshirmasdan parollarni o'chirib qo'yish

Bu qadam aynan nosozlikni xavfsiz, nazorat qilinadigan sharoitda yaratish uchun mavjud.

sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sshd -t && sudo systemctl reload sshd

Avval mo'ljallangan xatti-harakatni tekshiring:

ssh -o PubkeyAuthentication=no -o PasswordAuthentication=yes <username>@<vm-ip>

Permission denied (publickey).

Bu parol autentifikatsiyasi aynan mo'ljallanganidek to'g'ri o'chirilganini tasdiqlaydi. Endi lab haqiqiy xatoni kiritadi. Tasavvur qiling, 1-qadamda nusxalangan kalit noto'g'ri foydalanuvchi uchun bo'lgan yoki noto'g'ri yo'lga nusxalangan va hech qachon haqiqatan tekshirilmagan. Oqibatini his qilish uchun zaxira sessiyangizni hozir ataylab yoping:

# In the fallback session:
exit

# From your client machine, attempt a fresh connection:
ssh -i ~/.ssh/some-other-key <username>@<vm-ip>

Permission denied (publickey).

Parol autentifikatsiyasi mavjud bo'lmagani va noto'g'ri kalit taqdim etilgani sababli bu ulanish haqiqatan muvaffaqiyatsiz tugaydi. Agar bu yagona sessiya bo'lganida, mashina endi SSH’dan butunlay qulflangan bo'lardi va uni faqat konsol orqali tiklash mumkin bo'lardi.

Amaliy vaziyat: qulflanishdan tiklanish

Muammo. SSH kirishi rad etilyapti, PasswordAuthentication o'chirilgan va to'g'ri kalit taqdim etilmayapti.

Tekshirish — avval shunchaki noto'g'ri kalitdan foydalanayotganingiz emas, haqiqatan qulflanganingizni tasdiqlang:

ssh -v -i ~/.ssh/id_ed25519 <username>@<vm-ip>

-v flag'i aynan qaysi kalitlar taqdim etilgani va har biri nega rad etilganini ko'rsatadi. Ko'pincha tuzatish shunchaki to'g'ri kalit faylini aniq ko'rsatish bo'ladi va bu umuman haqiqiy qulflanish emas.

Buyruq — konsol kirishi orqali tiklash (bu lab qurib kelgan haqiqiy zaxira yo'l):

# Via the hypervisor/provider console, not SSH:
sudo sed -i 's/^PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config
sudo systemctl reload sshd

Tekshirish:

ssh <username>@<vm-ip>

Natija. Parol autentifikatsiyasi tiklanadi va kirish qaytadi. Endi parol autentifikatsiyasini yana o'chirishdan oldin to'g'ri kalitni diagnostika qilib, ssh-copy-id bilan qayta nusxalash mumkin — bu safar faqat 1-qadamdagi tekshiruvni aynan qayta tasdiqlagandan keyin.

Xulosa. Zaxira sessiyani ochiq saqlashning (0-qadam) butun ma’nosi — bu tiklash yo'liga hech qachon haqiqatda muhtoj bo'lmaslik. Bu vaziyat nosozlik turi va uning konsolga asoslangan tuzatishi haqiqiy, xavfi yuqoriroq hodisa paytida birinchi marta o'rganilmasdan, oldindan tanish bo'lishi uchun mavjud.

Troubleshooting bo'yicha maslahatlar

Tahrirdan keyin sshd -t sintaksis xatosi haqida xabar beradi. Qayta yuklashdan oldin uni tuzating — o'z sintaksis tekshiruvidan o'tmagan konfiguratsiya bilan sshd ni hech qachon qayta ishga tushirmang yoki qayta yuklamang.
AllowUsers siz unutgan qonuniy ikkinchi akkauntni bloklaydi. AllowUsers — bitta qatordagi bo'sh joy bilan ajratilgan ro'yxat, xavfsiz takrorlanadigan direktiva emas. Har bir mo'ljallangan foydalanuvchini sanab o'tadigan aynan bitta AllowUsers qatori borligini tekshiring, chunki ikkinchi, keyinroq kelgan qator birinchisiga qo'shilmaydi, balki uni jimgina bekor qiladi.
Haftalar davomida faqat kalitga asoslangan login ishlatilgani sababli, konsol kirishining o'zi siz endi eslay olmaydigan parolni talab qiladi. Bu haqiqiy, takrorlanib turadigan operatsion tuzoq. Faqat har kuni ishlatiladigan SSH yo'lini emas, konsol/out-of-band kirish hali ham ishlashini ham vaqti-vaqti bilan tekshirib turing.

Orqaga qaytarish va tozalash

sudo cp /etc/ssh/sshd_config.lab-backup /etc/ssh/sshd_config
sudo sshd -t && sudo systemctl reload sshd
sudo rm -f /etc/ssh/sshd_config.lab-backup

Yakuniy baholash mezoni

Quyidagilarning hammasi bajarilsa, bu lab yakunlangan hisoblanadi:

kalitga asoslangan login ishlaydi va u har qanday cheklovchi o'zgarishdan oldin yangi sessiyadan tekshirilgan;
PermitRootLogin no va PasswordAuthentication no ning ikkalasi ham faol ekani shunchaki konfiguratsiya faylini o'qish bilan emas, muvaffaqiyatsiz login sinovi bilan tasdiqlangan;
siz konsol kirishi yordamida qulflanishni shaxsan yuzaga keltirgansiz va undan tiklangansiz hamda ishlatilgan aniq tiklash buyrug'ini tasvirlab bera olasiz;
lab oxirida asl konfiguratsiya zaxira nusxa orqali tiklangan.

Mashqlar

Yangi lab VM’da 1–3-qadamlarni takrorlang, lekin bu safar SSH hardening maqolasidagi ko'rsatmaga amal qilib SSH portini ham o'zgartiring va sshd ni qayta yuklashdan oldin firewall qoidasini mos ravishda yangilang. Biror mavjud sessiyani yopishdan oldin yangi portdagi ulanishni tekshiring.
sshd -t sintaksis xatosini qayta yuklashdan oldin ushlashi nega xuddi shu xatoni qayta yuklash faol ulanishlarni allaqachon uzib qo'ygandan keyin aniqlashdan sezilarli darajada xavfsizroq ekanini o'z so'zlaringiz bilan tushuntiring.
SSH hardening maqolasida ko'rib chiqilganiga amal qilib, sshd uchun fail2ban ni sozlang, keyin test klientidan ataylab to'rt marta login’da muvaffaqiyatsizlikka uchrang va klientning IP’si ban qilinganini tasdiqlang.