Ubuntu VPS-ի կարգավորում առաջին HTTPS կայքի համար

Պատրաստեք սերվերը, դոմենն ու վերականգնման մուտքը

Օրինակը նոր Ubuntu 24.04 VPS-ի համար է՝ public IPv4, SSH պորտ 22, sudo իրավունքով սկզբնական հաշիվ և ձեր վերահսկողության տակ գտնվող դոմեն։ SSH բանալին ստեղծեք հաջորդ բաժնում՝ նախքան provisioning-ը։ Արդեն ստեղծված դատարկ սերվերի համար օգտագործեք գործող մուտքով բանալի ավելացնելու տարբերակը։ Կլիենտի հրամանները Bash-ում են՝ Linux, macOS կամ WSL, սերվերինը՝ SSH սեսիայում։ Եթե օրինակների ուղիներն արդեն պատկանում են գործող կայքին, կանգ առեք։

Ամեն 203.0.113.10 փոխարինեք սերվերի հասցեով, app.example.com-ը՝ ձեր hostname-ով․ երկուսն էլ փաստաթղթային օրինակներ են։ Սկզբնական ubuntu օգտատիրոջ փոխարեն անհրաժեշտության դեպքում նշեք մատակարարի հաշիվը։ Մինչ մուտքի կամ firewall-ի փոփոխությունը բացեք recovery console-ը։ Նախ կարդացեք իմիջի firewall հրահանգները․ Oracle Cloud Ubuntu-ն այլ մոտեցում է պահանջում։

Ստեղծեք բանալի կամ ավելացրեք այն գործող մուտքով

Ձեր համակարգչում ստեղծեք առանձին բանալի և ընտրեք գաղտնաբառային արտահայտություն։ Եթե այդ անունով ֆայլ կա, ամբողջ հրահանգում օգտագործեք այլ անուն։ .pub-ը հանրային է, private ֆայլը պահեք ձեր համակարգչում։

mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pub

Նոր VPS-ի համար․ ստեղծեք Ubuntu 24.04 սերվերը և մատակարարի SSH-key դաշտում տվեք այս public key-ը։ Ճշտեք սկզբնական username-ը և անցեք host fingerprint-ի ստուգմանը՝ բաց թողնելով արդեն ստեղծված սերվերի հրամանները։

Արդեն ստեղծված դատարկ VPS-ի համար․ պահեք գործող SSH սեսիան։ Ձեր համակարգչի երկրորդ տերմինալից public key-ը փոխանցեք աշխատող authentication-ով։ existing_vps_key-ը փոխարինեք ընթացիկ private key-ի անունով։ Password կամ SSH agent օգտագործելիս բաց թողեք -i ~/.ssh/existing_vps_key-ը․ սերվերի authentication policy-ն մի փոխեք։

scp -i ~/.ssh/existing_vps_key ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pub

Գործող սերվերային սեսիայում ստուգեք փոխանցված public-key ֆայլը և ավելացրեք սկզբնական հաշվի authorized_keys-ին։ Append-ը պահպանում է հին տողերը, լրացուցիչ newline-ը՝ նաև վերջին տողի ճիշտ բաժանումը։ Սա ձեր սկզբնական հաշվի համար է։ Եթե աշխատող մուտք չկա, նախ օգտագործեք մատակարարի recovery գործընթացը։

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
fi

Երկու ուղու դեպքում էլ առաջին կապն ընդունելուց առաջ fingerprint-ը համեմատեք trusted recovery console-ում համապատասխան host public key-ի հետ։ Ed25519-ի համար կոնսոլում գործարկեք՝

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Ձեր համակարգչից նոր բանալիով բացեք նոր SSH կապ։ Մինչ հաջող մուտքը հին սեսիան մի փակեք։

ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Մեկ այլ տեղային տերմինալից փոխանցեք public key-ը հաջորդ բաժնի առանձին ադմինիստրատորի համար։ Եթե ժամանակավոր public-key ֆայլն արդեն փոխանցվել է, այն նորից պատճենելը թույլատրելի է։

scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pub

Ստեղծեք առանձին ադմինիստրատոր և փորձարկեք մուտքը

Սերվերում նախ ստուգեք getent passwd deploy-ը․ հաշիվ չպետք է վերադարձվի։ Եթե deploy-ն արդեն կա, ընտրեք չօգտագործվող username և փոխեք այն ամբողջ օրինակով՝ ներառյալ home paths-ն ու groups-ը։ Այսպես ուրիշի key file-ը չեք փոխարինի։

Ստուգեք իմիջն ու ռեսուրսները, ուսումնասիրեք upgrades-ը և ստեղծեք ադմինիստրատորին։ Sudo-ի համար ուժեղ գաղտնաբառ դրեք։ Install հրամանները սահմանափակում են key file-ի թույլտվություններն ու ճիշտ owner-ը։

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_keys

Ձեր համակարգչի նոր տերմինալից միացեք նոր օգտատիրոջով։

ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10

Նոր սերվերային սեսիայում sudo-ն deploy-ի գաղտնաբառից հետո պետք է տպի root։ Շարունակեք այստեղ, երբ երկու ստուգումն էլ հաջող է․ սկզբնական մուտքը պահպանեք։

sudo whoami

Տեղադրեք Nginx և օգտագործեք իմիջի աջակցվող firewall-ը

Սերվերում նախ տեղադրեք Nginx։ Մուտքի վրա ազդում են guest firewall-ը և մատակարարի ցանցային firewall-ը․ երկուսը կարգավորելիս պահեք recovery console-ն ու գործող SSH սեսիան։

sudo apt install nginx
sudo systemctl enable --now nginx

Մատակարարի firewall-ում թույլատրեք TCP 22-ը ձեր վարչական հասցեից և TCP 80/443-ը կայքի այցելուների համար։ Եթե SSH-ն այլ պորտ ունի, պահեք դրա կանոնը։ Ցանցային կանոնը չի բացում guest firewall-ի արգելափակած պորտը։

Oracle Cloud Ubuntu իմիջների համար․ ամբողջ UFW բլոկը բաց թողեք։ Oracle-ը զգուշացնում է, որ UFW-ն կարող է խանգարել իմիջի անհրաժեշտ կանոններին և boot-ին։ Պահպանեք iptables-ի կանոնները, այդ թվում՝ iSCSI boot/block volumes-ը պաշտպանողները։ Կարգավորեք OCI security lists կամ NSGs և փաստաթղթավորված guest կանոնները HTTP/HTTPS-ի համար։ Մի մաքրեք կանոնները և մի փոխարինեք իմիջի firewall փաթեթները։

Այլ նոր Ubuntu իմիջների UFW տարբերակ․ օգտագործեք միայն, եթե մատակարարն աջակցում է UFW-ին և առանձին managed firewall չի պահանջում։ Մինչ միացնելը թույլատրեք իրական SSH պորտը․ այստեղ այն 22 է։

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 verbose

Երկու տարբերակից հետո ստուգեք նոր SSH login․ բաց սեսիան նոր կապի փորձ չէ։ Հաջորդ բաժնի արտաքին HTTP ստուգումն էլ պետք է հաջողվի՝ նախքան վկայագիր խնդրելը։ Ախտորոշման ընթացքում հին մուտքի մեթոդները պահպանեք։

Հրապարակեք էջը առանձին Nginx կայքով

Սերվերում ստեղծեք նոր document root և configuration։ Բլոկում փոխարինեք hostname-ը։ Պահեք չակերտավորված EOF նշիչները․ դրանք թույլ չեն տալիս shell-ին ընդլայնել Nginx-ի փոփոխականները, օրինակ՝ $uri-ը։

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 -t

Սերվերում reload արեք միայն հաջող configuration test-ից հետո։

sudo systemctl reload nginx

Ձեր համակարգչից hostname-ը հարցրեք սերվերի հասցեով՝ նախքան DNS-ի փոփոխությունը։ Սպասվում է ձեր վերնագիրը, ոչ թե Nginx-ի լռելյայն ողջույնը։

curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/

Կապեք DNS-ը և ստացեք HTTPS վկայագիր

Hostname-ի A գրառումը ուղղեք VPS-ի IPv4-ին։ AAAA ավելացրեք միայն աշխատող IPv6-ի դեպքում․ հին AAAA-ն կարող է այցելուներին և վկայագրի ստուգումը այլ տեղ ուղարկել։ Օրինակը ենթադրում է ուղիղ DNS՝ առանց proxy-ի։

Ձեր համակարգչից բացեք http://app.example.com/ առանց --resolve-ի։ Երբ ստանում եք ձեր էջը, սերվերում տեղադրեք Ubuntu արխիվի Certbot-ն ու Nginx plugin-ը։ Դրանց պետք է Universe repository․ package-not-found սխալը նախ լուծեք։

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.timer

Լրացրեք email-ի և պայմանների հարցումները։ Certbot-ը փոխում է այս կայքի configuration-ը և միացնում HTTP→HTTPS redirect-ը։ Համոզվեք, որ renewal timer-ը պլանավորված է․ եթե ոչ՝ sudo systemctl enable --now certbot.timer։ Պորտ 80-ը պահեք հասանելի HTTP validation-ի և renewal-ի համար։

Ստուգեք դրսից և reboot-ից հետո

Ձեր համակարգչից ստուգեք redirect-ը, certificate-ը և էջը։ HTTP-ն պետք է տանի HTTPS, իսկ HTTPS-ը հաջողությամբ ցույց տա ձեր վերնագիրը։ Curl-ի -k մի ավելացրեք․ այն թաքցնում է վկայագրի ստուգման սխալը։

curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/

Դեռ փորձնական տեղակայման ընթացքում սերվերում գործարկեք sudo reboot։ Վերադառնալուց հետո միացեք deploy-ով, ստուգեք systemctl is-active nginx-ը և կրկնեք արտաքին HTTPS հարցումը։ Reboot-ը փակում է SSH սեսիաները․ եթե մեքենան չի վերադառնում, օգտագործեք կոնսոլը։

Ախտորոշեք խափանումն ու պահեք վերականգնման նյութերը

Փոքր էկրանին բոլոր սյունակները տեսնելու համար աղյուսակը ոլորեք հորիզոնական։

Մուտքի կարգավորումները փոխելուց առաջ SSH-ի ախտորոշմամբ տարբերակեք ցանցի, ծառայության և բանալու խնդիրը։

Կայքի ֆայլերը, Nginx configuration-ը, DNS գրառումները և rebuild քայլերը պահեք VPS-ից դուրս և վերականգնեք առանձին մեքենայում։ Certificate private keys-ի backup-ը պաշտպանված պահեստ է պահանջում։ Միացրեք հասանելիության ու վկայագրի ժամկետի alerts․ մեկ հաջող ստուգումը վաղվա renewal-ը չի վերահսկում։

Սկսեք ֆայլերի պահուստավորման և վերականգնման փորձից՝ գործող կայքին չվերագրելով։ Ամբողջական recovery-ին պետք են նաև մնացած assets-ը, certificates-ը և service configuration-ը։ Այս տեղակայումը ստատիկ ֆայլեր է սպասարկում․ runtime-ին և բազային պետք է սեփական configuration և backup մեթոդ։ Դրանք ավելացնելիս օգտվեք ռեսուրսների չափման ուղեցույցից։

Հաճախ տրվող հարցեր

Պաշտոնական աղբյուրներ

1. Փաստաթուղթ 1․ ubuntu.com
2. Փաստաթուղթ 2․ ubuntu.com
3. Փաստաթուղթ 3․ ubuntu.com
4. Փաստաթուղթ 4․ eff-certbot.readthedocs.io
5. Փաստաթուղթ 5․ packages.ubuntu.com
6. Փաստաթուղթ 6․ docs.oracle.com