SSH kalitlar va fayl ruxsatlari: serverdagi birinchi darslar

Birinchi serverimni olganimda hammasi juda oddiy tuyulgandi: pochtaga IP manzil va root parol keldi, ulanib ishlayverdim. Bir necha kundan keyin qiziqib kirish loglarini ochdim va o‘sha yerda birinchi jiddiy saboqni oldim. Logda minglab qatordan iborat ro‘yxat turardi: Xitoy, Rossiya, Braziliya, Niderlandiya — turli IP manzillardan kelgan botlar tinimsiz parol terib ko‘rayotgan ekan. Hech kim mening serverimni maxsus tanlamagan, ular shunchaki butun internetni skanerlab yuradi va ochiq turgan har qanday SSH portini sinab ko‘radi.

Shundan keyin men uchun ikkita narsa yangi serverda birinchi soatda qilinadigan ishga aylandi: parol bilan kirishni yopish va fayl ruxsatlarini joyiga qo‘yish. Ikkalasi ham murakkab emas, lekin ular haqida vaqtida o‘ylamaslik qimmatga tushadi.

Nega kalit paroldan xavfsizroq#

Parolning muammosi shundaki, uni taxmin qilish mumkin. Bot soatiga minglab variant sinab ko‘radi va sizning parolingiz qanchalik murakkab bo‘lsa ham, u imkoniyat masalasi bo‘lib qolaveradi.

Kalit boshqacha ishlaydi. Siz ikkita fayl yaratasiz: private key va public key. Public key'ni serverga qo‘yasiz, private key esa faqat sizning kompyuteringizda qoladi va hech qachon hech qayerga uzatilmaydi. Ulanish paytida server sizga tasodifiy bir "topishmoq" yuboradi, siz uni private key'ingiz bilan imzolab qaytarasiz, server esa public key yordamida signature'ni tekshiradi. Ya'ni tarmoq orqali sirning o‘zi emas, faqat uning isboti yuriladi. Botning terib topishi uchun esa bu yerda tera oladigan narsaning o‘zi yo‘q.

Kalit yaratish bir buyruq:

ssh-keygen -t ed25519 -C "izoh"

Bugungi kunda ed25519 ni tanlash ma'qul: u eski RSA'ga qaraganda qisqaroq, tezroq va zamonaviy standart hisoblanadi. Buyruq parol (passphrase) so‘raydi va uni bo‘sh qoldirmagan yaxshi — noutbukingiz yo‘qolsa, kalitni topgan odam uni ishlata olmaydi. Har ulanishda parol terishdan qo‘rqmang, ssh-agent uni bir marta so‘raydi va seans davomida eslab turadi.

Ikkita fayl hosil bo‘ladi:

• id_ed25519 — private key, hech kimga bermang, serverga yuklamang
• id_ed25519.pub — public key, uni serverga qo‘yasiz

Public key'ni serverga uzatish ham bitta buyruq bilan bo‘ladi:

ssh-copy-id user@server

Bu buyruq kalitni serverdagi ~/.ssh/authorized_keys fayliga qo‘shib qo‘yadi. O‘sha fayl — serverning "kimlarni kalitsiz kiritaman" degan ro‘yxati.

Endi kalit bilan ulanib ko‘ring. Ishladimi — serverda parol bilan kirishni butunlay o‘chiring: /etc/ssh/sshd_config faylida PasswordAuthentication no qatorini qo‘ying va SSH xizmatini qayta ishga tushiring:

sudo sshd -t                      # sozlamada xato bormi
sudo systemctl restart ssh

Va endi eng muhimi: o‘chganini tekshiring#

Bu qadamni o‘tkazib yubormang, chunki zamonaviy Ubuntu va Debian'da PasswordAuthentication no ni yozib qo‘yish yetarli bo‘lmasligi mumkin. Sabab sshd_config ning boshida turgan bitta qatorda:

12:Include /etc/ssh/sshd_config.d/*.conf

Bulutli serverlar (DigitalOcean, Hetzner, AWS va boshqalar) odatda o‘sha papkaga 50-cloud-init.conf degan fayl qo‘yib yuboradi, uning ichida esa ko‘pincha PasswordAuthentication yes yozilgan bo‘ladi. SSH sozlamalarni o‘qiganda birinchi uchragan qiymatni oladi, Include esa faylning boshida turibdi — ya'ni siz pastga yozgan no hech qachon ishlamaydi.

Buni o‘zim sinab ko‘rdim. Asosiy faylga PasswordAuthentication no yozib, drop-in faylga yes qo‘yib, haqiqiy natijani so‘radim:

sudo sshd -T | grep -i passwordauthentication

passwordauthentication yes

Ya'ni sozlama yozilgan, server qayta ishga tushirilgan, siz esa parol bilan kirish yopilgan deb ishonib yuribsiz — aslida u ochiq. sshd -T buyrug‘i barcha fayllar birlashtirilgandan keyingi haqiqiy qiymatni ko‘rsatadi, shuning uchun har o‘zgarishdan keyin shu buyruq bilan tekshirgan ma'qul. Agar yes chiqsa, drop-in fayllarni qarang:

grep -r PasswordAuthentication /etc/ssh/sshd_config.d/

Endi tuzatishga kelsak, bu yerda yana bitta tuzoq bor va men unga o‘zim tushdim. "Drop-in papkaga o‘z faylimni qo‘shaman" deb 99-yopamiz.conf yasash tabiiy tuyuladi — lekin u ishlamaydi. Fayllar nomi bo‘yicha, alifbo tartibida o‘qiladi, ya'ni 50-cloud-init.conf 99- dan oldin keladi va birinchi uchragan qiymat yutadi. Uchala variantni ham o‘lchab ko‘rdim:

Ya'ni ikki yo‘l bor: yo 50-cloud-init.conf faylining o‘zidagi qatorni to‘g‘rilaysiz, yo undan oldin o‘qiladigan nom qo‘yasiz (01- kabi). Qaysi birini tanlasangiz ham, oxirida sshd -T bilan tekshiring — taxmin qilmang.

chmod: raqamlar nimani anglatadi#

Endi ikkinchi mavzuga o‘tamiz, u birinchisi bilan bevosita bog‘langan.

Linux'da har bir fayl uchta guruh uchun ruxsatga ega: egasi, guruhi va qolgan hamma. Har biriga uchta huquq beriladi — o‘qish (r), yozish (w) va bajarish (x). Raqamlar aynan shu huquqlarni bildiradi: o‘qish 4, yozish 2, bajarish 1. Ularni qo‘shib, bitta raqam olinadi. Masalan 6 — bu 4+2, ya'ni o‘qish va yozish; 7 esa 4+2+1, ya'ni hammasi.

Uchta raqam esa yuqoridagi uch guruhga tegishli:

chmod 600 maxfiy.key    # egasi o‘qiydi/yozadi, boshqalar — hech narsa
chmod 644 index.html    # egasi o‘qiydi/yozadi, boshqalar faqat o‘qiydi
chmod 755 script.sh     # egasi to‘liq, boshqalar o‘qiydi/bajaradi

Papkalar uchun x biroz boshqacha ma'no beradi: u "papka ichiga kira olish" degani. Shuning uchun papkalarda odatda 755 turadi, fayllarda esa 644.

SSH kalitni nega rad etadi#

Mana shu yerda ikkala mavzu tutashadi. Ko‘pchilik kalitni to‘g‘ri sozlaydi-yu, ulanmoqchi bo‘lganda server baribir parol so‘rayveradi yoki Permission denied (publickey) deb qaytaradi. Sababi deyarli har doim bitta: ruxsatlar juda keng.

SSH ataylab shunday qilingan. Agar kalitni yoki u yotgan papkani boshqalar ham o‘zgartira oladigan bo‘lsa, u butun tekshiruvni ishonchsiz deb biladi va rad etadi. Shuning uchun tartib qat'iy:

chmod 700 ~/.ssh                    # papkaga faqat egasi kiradi
chmod 600 ~/.ssh/id_ed25519         # private key — faqat egasiga
chmod 644 ~/.ssh/id_ed25519.pub     # public key'ni hamma o‘qisa ham bo‘ladi
chmod 600 ~/.ssh/authorized_keys    # ro‘yxatni boshqalar o‘zgartira olmasin

Ikki xil rad etish — va ular butunlay boshqacha ko‘rinadi#

Bu yerda bitta chalkashlik bor va u odamlarni soatlab ovora qiladi: xato sizning kompyuteringizdami yoki serverdami — ikki holatda siz butunlay boshqa narsa ko‘rasiz. Ikkalasini ham sinab ko‘rdim.

Xato sizda bo‘lsa, ya'ni private key'ning ruxsati keng bo‘lsa, SSH buni yashirmaydi:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'id_ed25519' are too open.
This private key will be ignored.

Aniq, baland ovozda — muammoni topish uchun hech narsa qidirish kerak emas.

Xato serverda bo‘lsa esa manzara butunlay boshqacha. ~/.ssh papkasini serverda 777 qilib qo‘yib, ssh -v bilan ulanib ko‘rdim:

debug1: Offering public key: id_ed25519 ED25519 SHA256:zuRRAqXC... explicit
debug1: Authentications that can continue: publickey
olim@localhost: Permission denied (publickey).

Diqqat qiling: -v bo‘lishiga qaramay, sababi haqida bitta so‘z yo‘q. Mijoz kalitni taklif qildi, server jimgina rad etdi. Sabab faqat serverning jurnalida yozilgan:

Authentication refused: bad ownership or modes for directory /home/olim/.ssh

Shuning uchun qoida shunday: ssh -v mijoz tomonidagi muammoni ko‘rsatadi, server tomonidagisini esa serverning o‘zidan qidirish kerak — sudo journalctl -u ssh -n 50 yoki /var/log/auth.log.

Aynan nima rad etishga sabab bo‘ladi#

Chegarani ham o‘lchab ko‘rdim (Ubuntu 24.04, OpenSSH 9.6). Serverda kalit tekshiruvini buzadigan narsa — hammaga yozish ruxsati berilgani:

Ko‘rib turganingizdek, SSH aslida ruxsat berganidan ko‘ra kengroq qiymatlarni ham qabul qilaveradi. Lekin bunga tayanmang: bu versiyaga bog‘liq narsa va har holda 644 turgan authorized_keys — "serverdagi har kim mening kalitlar ro‘yxatimni o‘qiy oladi" degani. Yuqoridagi to‘rt qatorni shundoq qo‘ying va boshingiz og‘rimaydi.

Amalda eslab qoladigan bir necha qoida#

Private key'lar, sertifikatlar va .env fayllari doim 600 bo‘lsin: ular ichida parol va tokenlar yotadi, ularni serverdagi boshqa hech kim ko‘rmasligi kerak.

chmod 777 ni esa umuman unutganingiz ma'qul. Bu "serverdagi har qanday foydalanuvchi va har qanday jarayon bu yerga yozishi mumkin" degani, va odatda uni "ishlamayapti, bir sinab ko‘ray" deb qo‘yishadi-da, keyin shundayligicha qolib ketadi.

Xavfi ikki tomonlama. Birinchisi — yuqorida ko‘rganimiz: 777 turgan papka SSH tekshiruvini butunlay buzadi. Ikkinchisi og‘irroq: serverda ishlaydigan boshqa bir xizmat buzilsa, hujumchi o‘sha papkadagi fayllaringizni almashtirib qo‘ya oladi — sizning skriptingizni, sozlamangizni, hatto authorized_keys ni. Foydalanuvchilar fayl yuklaydigan papka esa alohida e'tibor talab qiladi: agar veb-server o‘sha yo‘ldagi fayllarni bajarishga sozlangan bo‘lsa (PHP'da bu ko‘p uchraydi), yuklangan fayl kodga aylanadi. Shuning uchun yuklanadigan fayllar hech qachon bajariladigan yo‘lda turmasligi kerak.

Va oxirgisi: kundalik ishni root bilan qilmang. Oddiy foydalanuvchi ochib, kerak bo‘lganda sudo bilan ko‘tarilgan ancha xavfsiz. Xizmatlarni ham alohida foydalanuvchi nomidan ishlating — shunda ilovada zaiflik topilsa ham, hujumchining qo‘li butun serverga yetmaydi.

Bu narsalar bir marta o‘rganilib, keyin har serverda avtomatik takrorlanadigan odatga aylanadi. Va ishoning, o‘sha loglardagi minglab urinishni bir marta ko‘rgan odam bu odatni umrbod eslab qoladi.