Darslik · 2026-08-16 · ~6 daqiqa o‘qiladi · boshlang'ich
Yangi VPS qo'lga tegdi: birinchi soatda qilinadigan ishlar
Mundarija
Server sotib oldingiz, pochtangizga IP manzil va root parol keldi. Ko'pchilik shu zahoti loyihasini yuklashga oshiqadi, sozlashni esa "keyin qilamiz" deb qoldiradi. Keyin esa hech qachon kelmaydi — server yillab root paroli bilan, firewall'siz ishlab yuraveradi. Internetga ochilgan har qanday server esa birinchi daqiqadanoq skanerlar nishoniga aylanadi: log'ni ochsangiz, tanimagan IP'lar parol terib ko'rayotganini o'z ko'zingiz bilan ko'rasiz.
Shuning uchun kelishib olaylik: loyiha serverga birinchi soatdan keyin chiqadi. Avval quyidagi beshta ish qilinadi. Men bularni o'z serverlarimda necha marta takrorlaganman, tartib ham shunga yarasha joylashgan — har qadam keyingisiga zamin tayyorlaydi. Misollar Ubuntu 24.04 uchun, boshqa distributivlarda buyruqlar ozgina farq qilishi mumkin.
1-qadam: yangilash va vaqt mintaqasi#
Birinchi ulanish hali root bilan bo'ladi — boshqa foydalanuvchi yo'q:
ssh root@SERVER_IP
# paketlarni yangilaymiz — yangi serverda deyarli har doim eskirgan paketlar bo'ladi
apt update && apt upgrade -y
# vaqt mintaqasini to'g'rilaymiz — loglar va cron o'z vaqtida yashasin
timedatectl set-timezone Asia/Tashkent
Vaqt mintaqasi mayda ishday tuyuladi, lekin keyin log o'qiganda "bu xato soat 3 da bo'lganmi yoki 8 damii" deb bosh qotirmaysiz.
2-qadam: alohida foydalanuvchi#
Root bilan kundalik ishlash — xatoning bir buyruqlik masofasida yurish
degani. Bitta noto'g'ri rm yoki xatolik bilan qo'yilgan probel butun
tizimni olib ketishi mumkin, chunki root'dan hech kim ruxsat so'ramaydi.
O'zimizga oddiy foydalanuvchi ochamiz va kerak bo'lganda sudo bilan
ko'tarilamiz:
adduser deploy # parol so'raydi — kuchli parol qo'ying
usermod -aG sudo deploy # sudo guruhiga qo'shamiz
Endi tekshirib ko'ramiz — yangi terminalda:
ssh deploy@SERVER_IP
sudo whoami # parol so'raydi, javob: root
3-qadam: SSH kalit va parolni butunlay o'chirish#
Parol bilan kirish qulay, lekin parolni terib topish mumkin — butun dunyo bo'ylab botlar kechayu kunduz shu ish bilan band. SSH kalit esa amalda terib topilmaydi. Kalitni o'z kompyuteringizda yasab, serverga ko'chiramiz:
# o'z kompyuteringizda (agar kalitingiz hali bo'lmasa):
ssh-keygen -t ed25519 -C "deploy uchun"
# ochiq kalitni serverdagi deploy foydalanuvchisiga yuboramiz:
ssh-copy-id deploy@SERVER_IP
# tekshiramiz — endi parol so'ramasligi kerak:
ssh deploy@SERVER_IP
Kalit ishlayotganiga to'liq ishonch hosil qilgach, parol bilan kirishni va root'ning SSH orqali kirishini o'chiramiz. Bu ikkisi yangi serverdagi eng katta ikki eshikni yopadi:
sudo nano /etc/ssh/sshd_config
# /etc/ssh/sshd_config ichida shu qatorlarni toping va shunday qiling:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
sudo systemctl restart ssh
Avval kalitni tekshiring, keyin eshikni yoping
PasswordAuthentication no qilishdan oldin kalit bilan kirish ishlayotganini
alohida terminalda albatta tekshiring, va hozirgi sessiyangizni yopmang.
Kalit ishlamay turib parolni o'chirsangiz, o'z serveringizdan o'zingiz
qulflanib qolasiz — keyin provayder konsoli orqali qutqarish operatsiyasi
boshlanadi. SSH kalitlar qanday ishlashi haqida alohida yozganman:
Linux ruxsatlar va SSH kalitlar.
4-qadam: firewall — faqat kerakli eshiklar#
Serverda qaysi portlar ochiqligini bilmaslik — eng keng tarqalgan holat. Ubuntu'da buning uchun ufw bor, mantiq juda sodda: hammasini yopamiz, keraklisini ochamiz.
sudo ufw default deny incoming # kiruvchi hamma narsa yopiq
sudo ufw default allow outgoing # chiquvchi ochiq (apt, API chaqiruvlar...)
sudo ufw allow OpenSSH # SSH'siz qolib ketmaslik uchun BIRINCHI shu
sudo ufw allow 80/tcp # http
sudo ufw allow 443/tcp # https
sudo ufw enable
sudo ufw status
Ro'yxatda uchta qoida ko'rinadi: SSH, 80 va 443. Boshqa hech narsa. Keyinroq biror xizmatga port kerak bo'lsa (masalan tashqi Postgres ulanishi), ongli ravishda ochasiz — "qaysi portim ochiq ekan o'zi" degan savol endi bo'lmaydi.
ufw enable'dan oldin SSH qoidasi
ufw enable mavjud ulanishlarni uzmaydi, lekin SSH'ga ruxsat qo'shilmagan
bo'lsa, keyingi ulanishingiz o'tmaydi. Shuning uchun tartib qat'iy: avval
allow OpenSSH, keyin enable.
5-qadam: swap — kichik serverning sug'urtasi#
1-2 GB xotirali arzon VPS'da xotira to'lib qolsa, Linux'ning OOM-killer'i kelib eng "semiz" jarayonni o'ldiradi — odatda bu sizning ilovangiz yoki bazangiz bo'ladi. Swap fayl bunga arzon sug'urta: tezlik pasayadi, lekin jarayonlar tirik qoladi.
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile # swap faylni faqat root o'qiy olishi kerak
sudo mkswap /swapfile
sudo swapon /swapfile
# reboot'dan keyin ham ishlashi uchun fstab'ga yozamiz:
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
free -h # Swap qatorida 2.0Gi ko'rinishi kerak
Shu joyda o'zimning saboqlarimdan biri: yaqinda bir serverda 2021-yildan
qolgan 40 MB'lik swap faylni topdim — o'sha paytda test uchun yaratilgan-u,
kattalashtirish esdan chiqqan. Server yillab amalda sug'urtasiz ishlagan.
Sozlaganda free -h bilan tekshirib qo'yish bir soniya oladi.
Yakuniy tekshiruv#
Birinchi soat tugadi. Endi serverni shu ro'yxat bilan bir aylanib chiqamiz:
ssh deploy@SERVER_IP # kalit bilan kiradi, parol so'ramaydi
ssh root@SERVER_IP # rad etilishi kerak
sudo ufw status # faqat SSH, 80, 443
free -h # swap ko'rinadi
timedatectl # Asia/Tashkent
Beshala javob to'g'ri bo'lsa, server loyiha qabul qilishga tayyor. E'tibor bering, hali nginx ham, baza ham, ilova ham yo'q — ular keyingi qismlarning ishi. Lekin ana shu yalang'och holatida ham server endi tasodifiy hujumlarga ochiq emas.
Keyingi qismda serverga birinchi xizmatni joylaymiz: systemd unit'ini chuqur tushunish — web-ilovani xizmat sifatida ishga tushirish, bog'liqliklar va ishga tushish tartibi.