Ubuntu VPS sozlash: SSH’dan HTTPS’gacha
Yangi Ubuntu 24.04 LTS VPS’da Nginx bilan kichik statik saytni HTTPS orqali oching. Alohida administrator, SSH kaliti, sertifikat yangilanishi va reboot’dan keyingi tekshiruvni tayyorlang. Bu ketma-ketlik mavjud ishlayotgan saytga tekshiruvsiz qo‘llash uchun emas.
VPSuntu · Yangilandi: · O‘qish: taxminan 4 daqiqa
Qo‘llanma mazmuni
Server, domen va tiklash kirishini tayyorlang
Yangi Ubuntu 24.04 VPS, provayderning recovery console’i va DNS’ini boshqaradigan domen kerak. Misollardagi 203.0.113.10 va example.com hujjat uchun ajratilgan qiymatlar; ularni o‘zingiznikiga almashtiring. DNS to‘g‘ridan-to‘g‘ri serverga yo‘nalsin, SSH porti 22 bo‘lsin.
Kompyuteringizdagi buyruqlar Bash muhiti uchun; serverga kirgandan keyingi buyruqlar Ubuntu ichida bajariladi. Windows’da mos Bash/WSL yoki buyruqqa mos terminaldan foydalaning. SSH va firewall o‘zgarishidan oldin provayder konsoliga kira olishingizni tekshiring. Oracle Cloud Ubuntu obrazida UFW bosqichini o‘tkazib yuboring: OCI tarmoq qoidalari va obrazning mavjud iptables tizimini saqlang.
SSH kalitini yarating yoki mavjud kirishga qo‘shing
Kompyuteringizda alohida kalit yarating va passphrase tanlang. Xuddi shu fayl allaqachon bo‘lsa, uni ustiga yozmang: yangi nom tanlab, keyingi buyruqlarda ham shu nomdan foydalaning. .pub ochiq kalit; yopiq kalit kompyuteringizda qoladi.
mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pubYangi VPS uchun: Ubuntu 24.04 serverini yaratishda ochiq kalitni provayderning SSH key maydoniga qo‘shing. Dastlabki foydalanuvchi nomini tekshiring va pastdagi host fingerprint tekshiruviga o‘ting. Mavjud server uchun berilgan keyingi ikki buyruqni o‘tkazib yuboring.
Oldin yaratilgan bo‘sh VPS uchun: ishlayotgan SSH sessiyasini ochiq qoldiring. Kompyuteringizdagi boshqa terminaldan yangi ochiq kalitni joriy autentifikatsiya orqali ko‘chiring. existing_vps_key o‘rniga joriy yopiq kalit yo‘lini qo‘ying. Agar hozirgi kirish parol yoki SSH agent orqali bo‘lsa, -i ~/.ssh/existing_vps_key qismini olib tashlang; serverning autentifikatsiya siyosatini o‘zgartirmang.
scp -i ~/.ssh/existing_vps_key ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pubKeyingi buyruqni serverdagi hali ochiq sessiyada bajaring. U yangi kalitni authorized_keys’ga qo‘shadi; mavjud kalitlarni almashtirmaydi va satr oxiri yo‘qligini hisobga oladi.
if ssh-keygen -lf ~/ubuntu-vps-admin.pub; then
mkdir -p ~/.ssh
chmod 700 ~/.ssh
printf '\n' >> ~/.ssh/authorized_keys
cat ~/ubuntu-vps-admin.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
fiYangi ulanishdan oldin provayderning ishonchli konsolida host kalitining fingerprint’ini oling. Bu mijozingizning SSH kaliti emas.
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pubKompyuteringizdan alohida ulaning. Taklif etilgan fingerprint konsoldagi qiymatga mos bo‘lsin; mos kelmasa to‘xtab, instance va IP’ni tekshiring.
ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10Yangi sessiyada foydalanuvchi va sudo huquqini tekshiring. Eski ishlayotgan sessiyani hozircha yopmang.
scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pubAlohida administrator yarating va sinang
Serverdagi mavjud administrator sessiyasida quyidagini bajaring. deploy bu misoldagi yangi foydalanuvchi; shu nom allaqachon ishlatilsa, avval uni tekshiring, mavjud hisob sozlamalarini almashtirmang. Kuchli, boshqa joyda ishlatilmagan parol tanlang.
cat /etc/os-release
free -h
df -h /
sudo apt update
sudo apt upgrade
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo install -m 600 -o deploy -g deploy ~/ubuntu-vps-admin.pub /home/deploy/.ssh/authorized_keysOchiq kalitni yangi administratorning katalogiga to‘g‘ri egasi va ruxsatlari bilan o‘rnating.
ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10Kompyuteringizda yangi terminal ochib, deploy bilan kiring va sudo’ni sinang. Bu muvaffaqiyatli bo‘lmaguncha eski kirishni yopmang yoki o‘chirmang.
sudo whoamiNginx o‘rnating va obrazga mos firewall ishlating
Sinovdan o‘tgan administrator orqali serverda paketlarni yangilang va Nginx o‘rnating. Yangilash paytidagi konfiguratsiya savollarini o‘qib chiqing.
sudo apt install nginx
sudo systemctl enable --now nginxQuyidagi UFW buyruqlari faqat provayder UFW’ni qo‘llaydigan yangi, oddiy Ubuntu obraziga tegishli. Avval SSH’ga ruxsat beriladi; cloud firewall yoki security group’da ham 22, 80 va 443 portlari kerakli manbalardan ochiq bo‘lishi kerak. SSH’ni o‘z IP’ingiz bilan cheklang, saytning 80/443 portlarini esa tashqi tekshiruv uchun oching.
Oracle Cloud Ubuntu’da bu UFW blokini bajarmang. Obrazning iptables va iSCSI uchun mavjud qoidalarini saqlang; provayder ko‘rsatmasiga muvofiq OCI security list/NSG hamda guest firewall’ni moslang.
sudo apt install ufw
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verboseFirewall o‘zgarishidan keyin boshqa terminaldan yangi SSH ulanishini sinang. Yangi kirish ishlamasa, ochiq sessiya yoki recovery console orqali aynan o‘zgartirilgan qoidani tekshiring.
Alohida Nginx sayti bilan sahifa chiqaring
Yangi sinov VPS’ida domeningiz uchun alohida katalog va statik sahifa yarating. example.com’ni barcha kerakli joyda o‘zingiz boshqaradigan domen bilan almashtiring.
sudo install -d -m 755 /var/www/first-site
printf '%s\n' '<!doctype html><html lang="en"><title>First deployment</title><h1>Ubuntu VPS is serving this page</h1></html>' | sudo tee /var/www/first-site/index.html
sudo tee /etc/nginx/sites-available/first-site >/dev/null <<'EOF'
server {
listen 80;
listen [::]:80;
server_name app.example.com;
root /var/www/first-site;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
EOF
sudo ln -s /etc/nginx/sites-available/first-site /etc/nginx/sites-enabled/first-site
sudo nginx -tQuyidagi konfiguratsiyani alohida faylga yozing. Quoted heredoc ichidagi $uri shell tomonidan almashtirilmaydi; bu Nginx o‘zgaruvchisi bo‘lib qolishi kerak.
sudo systemctl reload nginxSaytni yoqing, konfiguratsiyani tekshiring va faqat tekshiruv o‘tsa reload qiling. Mavjud production serverdagi boshqa sayt yoki standart konfiguratsiyani ko‘r-ko‘rona o‘chirmang: ushbu ketma-ketlik yangi sinov serveriga mo‘ljallangan.
curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/curl --resolve orqali DNS hali yangilanmagan bo‘lsa ham kerakli IP va Host bilan HTTP javobini tekshirish mumkin. Ko‘zlangan sahifa chiqishini, standart Nginx sahifasi kelmayotganini tekshiring.
DNS’ni ulang va HTTPS sertifikatini oling
A yozuvini VPS’ning ommaviy IPv4 manziliga yo‘naltiring. AAAA faqat IPv6 yo‘li servergacha to‘liq ishlasa bo‘lsin; eskirgan yoki ishlamaydigan AAAA tekshiruvni buzishi mumkin. Tashqi kompyuterdan DNS va HTTP’ni tekshiring.
Ubuntu repository’laridan Certbot va Nginx plaginini o‘rnating; kerak bo‘lsa Ubuntu Universe yoqing. Domeningizni buyruqqa kiriting, haqiqiy email va shartlarga javob bering. Certbot Nginx konfiguratsiyasini o‘zgartiradi.
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d app.example.com --redirect
sudo nginx -t
sudo certbot renew --dry-run
systemctl list-timers --all certbot.timerYangilanishning dry-run sinovi o‘tsin va systemd timer ishlasin. HTTP-01 yangilanishi uchun 80-portni yopib qo‘ymang. Sertifikat bo‘lishi o‘zi saytning barcha vazifalari ishlashini anglatmaydi.
Tashqaridan va reboot’dan keyin tekshiring
Quyidagi tekshiruvlarni mos joyda bajaring: curl va brauzer orqali tashqi HTTPS, serverda Nginx va timer holati. TLS tekshiruvini -k bilan chetlab o‘tmang.
curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/Faqat yangi sinov serverini qayta ishga tushiring; ishlayotgan production xizmatga rejasiz reboot bermang. Server qaytgach yangi SSH sessiyasi, Nginx, tashqi HTTPS, to‘g‘ri domen va sertifikatni qayta tekshiring. Runtime yoki baza keyin qo‘shilsa, ularning avtomatik ishga tushishi va health check’larini ham sinang.
Xatoni ajrating va tiklashga tayyorlaning
Kichik ekranda barcha ustunlarni ko‘rish uchun jadvalni yon tomonga suring.
| Belgi | Birinchi tekshiruv |
|---|---|
| SSH timeout | Manzil, provayder va guest firewall, recovery console |
| Permission denied (publickey) | Foydalanuvchi, yopiq kalit va authorized_keys ruxsatlari |
| Standart Nginx sahifasi chiqadi | DNS manzili, server_name va faol sayt |
| Sertifikat tekshiruvi o‘tmaydi | Ommaviy A/AAAA yozuvlari va 80-port |
| O‘zgarishdan keyin Nginx ishlamaydi | sudo nginx -t va sudo journalctl -u nginx -n 50 --no-pager |
Kirish uzilsa, sozlamalarni o‘zgartirishdan oldin SSH diagnostikasi orqali tarmoq, xizmat va kalit muammosini ajrating.
Sayt fayllari, Nginx konfiguratsiyasi, DNS yozuvlari va qayta qurish bosqichlarini VPS’dan tashqarida saqlang. Zaxira nusxani tiklash mashqi fayl darajasini tekshiradi; to‘liq xizmatni alohida muhitda tiklashni ham sinang.
Ko‘p so‘raladigan savollar
Bu buyruqlarni mavjud saytimda bajarsam bo‘ladimi?
Avval alohida sinov VPS’ida ishlang. Misol fayllar yaratadi, firewall yoqadi va Certbot’ga Nginx’ni o‘zgartirishga ruxsat beradi. Ishlayotgan serverda mavjud saytlar, kirish qoidalari va tiklash jarayonini oldindan tekshirish kerak.
Bu WordPress, Node.js yoki bazani ham o‘rnatadimi?
Yo‘q, natija statik HTTPS saytidir. Shu ishlaydigan asosni saqlab, keyin runtime’ni qo‘shing va uning ishga tushishi, health check hamda ma’lumotni tiklashini sinang.