SSH konfiguratsiyasi

SSH kalit autentifikatsiyasi dan keyin, ayniqsa bir nechta server va bir nechta kalit paydo bo'lganda, bitta ulanishning o'zi ssh -i ~/.ssh/id_work [email protected] kabi uzun buyruqni talab qilishi mumkin. Yana bir hali ochiq savol ham bor: serverning o'zi qaysi autentifikatsiya usullariga ruxsat beradi va root umuman to'g'ridan-to'g'ri kira oladimi. Bular ikki alohida masala — klient tomonidagi qulaylik va server tomonidagi siyosat — va ular ikki butunlay boshqa konfiguratsiya fayli bilan boshqariladi.

Ikki mustaqil konfiguratsiya fayli

SSH’da konfiguratsiyaning ikki butunlay alohida darajasi bor:

Bu ikkalasini ajratib turish muhim: klient konfiguratsiyasidagi o'zgarish faqat ssh ning sizning mashinangizda qanday ishlashiga ta’sir qiladi; server konfiguratsiyasidagi o'zgarish esa o'sha serverga ulanadigan hammaga qo'llanadi.

Klient konfiguratsiyasi: ~/.ssh/config

Agar fayl hali mavjud bo'lmasa, uni yarating:

touch ~/.ssh/config
chmod 600 ~/.ssh/config

Har bir server o'zining Host blokiga ega bo'ladi:

Host prod-web
    HostName 192.168.1.50
    User alice
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

Host staging-db
    HostName 10.20.0.15
    User deploy
    IdentityFile ~/.ssh/id_work

Endi to'liq buyruq o'rnini qisqa alias egallaydi:

ssh prod-web

Bu funksional jihatdan ssh -p 2222 -i ~/.ssh/id_ed25519 [email protected] ni ishga tushirish bilan bir xil.

Eng ko'p ishlatiladigan direktivalar

• Host — blok qaysi alias(lar)ga tegishli ekanini belgilaydi; bir nechta andozaga ruxsat beriladi (masalan, Host *.internal);
• HostName — haqiqiy manzil yoki domen nomi;
• User — masofaviy foydalanuvchi nomi;
• Port — sukut bo'yicha 22 dan boshqa port;
• IdentityFile — qaysi private key faylidan foydalanish;
• ProxyJump — oraliq (bastion/jump) server orqali ulanish, masalan:

Host internal-app
    HostName 10.20.0.30
    User deploy
    ProxyJump bastion-server

Bu ichki tarmoqqa faqat bitta, qattiq nazorat qilinadigan bastion server orqali yetish mumkin bo'lgan arxitekturalarda keng tarqalgan andoza: ssh internal-app ni ishga tushirish bu ikki qadamni qo'lda bajarmasdan avval avtomatik ravishda bastion-server ga, so'ng ichki 10.20.0.30 ga ulanadi.

Har bir host uchun umumiy sozlamalar

Host * bloki sozlamalarni har bir serverga qo'llaydi:

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

• ServerAliveInterval 60 — klient serverga har 60 soniyada keep-alive so'rovini yuboradi; bu uzoq vaqt harakatsiz turgan ulanishni NAT yoki firewall indamay uzib qo'yishining oldini oladi;
• ServerAliveCountMax 3 — ulanish o'lgan deb hisoblanishidan oldin nechta javobsiz so'rovga chidash kerakligi.

Server konfiguratsiyasi: /etc/ssh/sshd_config

Bu fayl sshd xizmatining xatti-harakatini boshqaradi va uni faqat root huquqlari bilan tahrirlash mumkin.

Asosiy direktivalar

Port 22
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers alice deploy

• Port — xizmat qaysi portni tinglashi; sukut bo'yicha bo'lmagan qiymatni tanlash SSH hardening maqolasida chuqurroq ko'rib chiqiladi;
• PermitRootLogin no — root foydalanuvchisining SSH orqali to'g'ridan-to'g'ri kirishiga yo'l qo'ymaydi; administrator avval oddiy foydalanuvchi sifatida kirib, so'ng sudo dan foydalanishi kerak — bu Root va sudo maqolasidagi eng kam huquq tamoyilining to'g'ridan-to'g'ri qo'llanishi;
• PasswordAuthentication no — faqat kalit bilan kirishga ruxsat beradi va parol urinishlarini butunlay o'chiradi;
• PubkeyAuthentication yes — kalit autentifikatsiyasi yoqilganini tasdiqlaydi (odatda allaqachon sukut bo'yicha shunday);
• AllowUsers — faqat ro'yxatdagi foydalanuvchilar SSH orqali kira oladi; boshqa har qanday tizim hisobi — hatto to'g'ri parol yoki kalitga ega bo'lsa ham — to'g'ridan-to'g'ri rad etiladi.

Konfiguratsiyani xavfsiz o'zgartirish

sshd_config dagi har qanday o'zgarishdan keyin xizmatni qayta yuklashdan oldin sintaksisni tekshirish kerak:

sudo sshd -t

Chiqish bo'lmasligi muvaffaqiyatni bildiradi. Xato bo'lsa, u aniq qator raqami bilan ko'rsatiladi. Faqat shundan keyin xizmatni qayta yuklang:

sudo systemctl reload ssh

reload restart dan afzalroq — u mavjud ulanishlarni uzmasdan yangi konfiguratsiyani qayta o'qiydi. Bu ayniqsa masofaviy o'zgarishlar uchun muhim: agar yangi konfiguratsiya buzilgan bo'lib chiqsa va xizmat to'liq qayta ishga tushirilsa, o'zingizni serverdan uzib qo'yishingiz mumkin; reload esa joriy sessiyani tirik saqlaydi.

Amaliy vaziyat: root login’ni o'chirishdan oldin kirish rejasini tekshirish

Muammo: yangi server hozircha faqat root sifatida kirishga ruxsat beradi; buni xavfsizroq sozlamaga o'tkazish kerak.

1-qadam — joriy amaldagi qiymatlarni tekshirish:

sudo sshd -T | grep -iE 'permitrootlogin|passwordauthentication'

sshd -T barcha amaldagi sozlamalarni — sukut bo'yicha qiymatlarni ham, fayldan o'qilganlarini ham — chiqaradi. Bu faylni to'g'ridan-to'g'ri o'qishdan ishonchliroq, chunki muayyan o'rnatmada ayrim qiymatlar hujjatlashtirilgan sukut bo'yicha qiymatlardan allaqachon farq qiladi.

2-qadam — avval oddiy foydalanuvchi va kalit autentifikatsiyasini sozlash: SSH kalit autentifikatsiyasi maqolasiga ko'ra alice uchun authorized_keys tayyorlanadi va kirish yangi terminalda ssh alice@server bilan tekshiriladi.

3-qadam — sudo huquqini tasdiqlash:

ssh alice@server "sudo -l"

4-qadam — konfiguratsiyani o'zgartirish:

sudo sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sshd -t

5-qadam — eski sessiyani ochiq qoldirib qayta yuklash, so'ng yangi terminalda sinash:

sudo systemctl reload ssh

Yangi terminalda:

ssh root@server

root@server: Permission denied (publickey,password).

alice@server sifatida kirish ishlashda davom etadi.

6-qadam — natija va hujjatlashtirish: root endi to'g'ridan-to'g'ri kira olmasligini, alice esa kalit bilan kirib, ma’muriy vazifalarni sudo orqali bajara olishini tasdiqlang. O'zgarish sanasi va sababini (masalan, xavfsizlik siyosatiga moslashtirish) qayd qiling.

Keng tarqalgan xatolar

Avval sshd -t siz to'g'ridan-to'g'ri restart ni ishga tushirish

Konfiguratsiyada sintaksis xatosi bo'lgan holda xizmatni qayta ishga tushirish uni umuman ishga tusha olmaydigan holatda qoldirishi mumkin — bunday holatda serverga SSH orqali kirish butunlay yo'qoladi.

Xavfli o'zgarish uchun bitta ochiq sessiyaga tayanish

Yuqorida ta’kidlanganidek, o'zgarishni sinashdan oldin joriy sessiyani yopish buzilgan konfiguratsiyani tuzatishning har qanday yo'lini yo'q qiladi.

~/.ssh/config da noto'g'ri IdentityFile yo'lini yozish

Agar yo'l mavjud bo'lmasa yoki noto'g'ri faylga (masalan, .pub faylga) ishora qilsa, ssh indamay boshqa sukut bo'yicha kalitlarni sinab ko'rishga o'tadi — bu debug qilishni chalkashtirishi mumkin. Aslida qaysi kalit ishlatilayotganini ko'rish uchun -v flag'idan foydalaning.

AllowUsers ni yangilashda mavjud foydalanuvchini unutish

Yangi foydalanuvchi qo'shishda AllowUsers qiymatiga qo'shish o'rniga uni butunlay almashtirish avval ruxsat berilgan foydalanuvchilarning kirish imkonini yopib qo'yishi mumkin.

Mashqlar

1. ~/.ssh/config da laboratoriya serveringiz uchun Host blokini (alias, HostName, User, IdentityFile) yarating va ssh <alias> yordamida ulaning.
2. sudo sshd -T | less chiqishidan PermitRootLogin, PasswordAuthentication va X11Forwarding qiymatlarini toping va har birining amaliy ma’nosini yozing.
3. Yuqoridagi vaziyatni takrorlang: oddiy foydalanuvchi uchun kalit autentifikatsiyasini sozlang va faqat shundan keyin PermitRootLogin no ni yoqing.
4. sshd_config ga ataylab sintaksis xatosi kiriting (masalan, Port abc), sudo sshd -t uni qanday ko'rsatishini kuzating, so'ng uni tuzating.

Mashqni bajardim deyish uchun: 3-mashqda to'g'ridan-to'g'ri ssh root@server urinishi Permission denied qaytarishi, ssh alice@server esa muvaffaqiyatli bo'lishi va sudo -l mavjud buyruqlarni ro'yxatlashi kerak — tekshiruvlardan biri muvaffaqiyatsiz bo'lsa, o'zgarish to'g'ri qo'llanmagan.

Manbalar

• man7.org: ssh_config(5)
• man7.org: sshd_config(5)
• man7.org: sshd(8)
• OpenSSH Wikibook — Cookbook: proxy va jump host’lar
• Ubuntu Server — OpenSSH konfiguratsiyasi