Konfigurimi i Ubuntu VPS: nga SSH te faqja me HTTPS
Konfiguroni një VPS të ri me Ubuntu 24.04 LTS dhe publikoni një faqe të vogël statike me Nginx e HTTPS. Udhëzuesi përfshin administrator të veçantë, hyrje me çelës SSH, rinovim certifikate dhe kontroll pas rindezjes.
VPSuntu · Përditësuar: · Leximi: rreth 6 min
Përmbajtja e udhëzuesit
Përgatitni serverin, domain dhe aksesin e rikuperimit
Përdorni një VPS të ri me Ubuntu 24.04, IPv4 publike, SSH në portën 22, përdorues fillestar me sudo dhe domain që kontrolloni. Krijoni çelësin në hapin pasues para instancës. Për një server bosh tashmë të krijuar ndiqni rrugën alternative përmes aksesit që funksionon.
Komandat lokale përdorin Bash në Linux, macOS ose WSL; komandat e serverit ekzekutohen brenda SSH. Nëse shtigjet e shembullit i përkasin një instalimi ekzistues, ndaloni. Zëvendësoni 203.0.113.10 me IP-në tuaj, app.example.com me hostname tuaj dhe ubuntu me llogarinë fillestare të ofruesit.
Hapni konsolën e rikuperimit para ndryshimeve të aksesit ose firewall. Kontrolloni udhëzimet për imazhin konkret. Imazhet Ubuntu në Oracle Cloud duhet të anashkalojnë të gjithë bllokun UFW.
Krijoni çelësin ose shtojeni përmes aksesit ekzistues
Në kompjuterin tuaj krijoni një çelës të veçantë dhe zgjidhni passphrase. Nëse emri i skedarit ekziston, përdorni një emër tjetër në gjithë procedurën. Vetëm skedari .pub është publik; skedari privat mbetet në kompjuterin tuaj.
mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pubPër VPS të ri: krijoni tani serverin Ubuntu 24.04 dhe vendosni çelësin publik në fushën SSH të ofruesit. Konfirmoni përdoruesin fillestar. Anashkaloni dy blloqet për server ekzistues dhe kaloni te verifikimi i identitetit të serverit.
Për VPS bosh të krijuar më parë: mbajeni sesionin SSH që funksionon. Nga një terminal tjetër lokal kopjoni çelësin publik me autentikimin ekzistues. Zëvendësoni existing_vps_key me çelësin që përdorni. Nëse hyni me fjalëkalim ose agent SSH, hiqni -i ~/.ssh/existing_vps_key pa ndryshuar politikën e serverit.
scp -i ~/.ssh/existing_vps_key ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pubNë sesionin ekzistues të serverit verifikoni skedarin dhe shtojeni në authorized_keys të llogarisë suaj fillestare. Ruhen hyrjet e tjera dhe shtohet ndarje edhe kur rreshti i fundit nuk përfundon me newline. Pa akses funksional, përdorni më parë rikuperimin e ofruesit.
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
fiPër të dyja rrugët, para pranimit të lidhjes së parë, merrni fingerprint të çelësit publik të serverit përmes konsolës së besuar. Për Ed25519, ekzekutoni atje:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pubNga kompjuteri juaj hapni një lidhje të re. Krahasoni llojin dhe fingerprint; pranoni vetëm përputhjen. Mbajeni aksesin e vjetër deri në sukses.
ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10Nga një terminal tjetër lokal kopjoni çelësin publik që do t’i jepet administratorit të veçantë. Rikopjimi i këtij skedari të përkohshëm publik është në rregull nëse rruga e serverit ekzistues e ngarkoi më parë.
scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pubKrijoni administratorin dhe provoni hyrjen e tij
Në server kontrolloni fillimisht getent passwd deploy. Nuk duhet të ekzistojë llogari e tillë. Nëse ekziston, zgjidhni emër të papërdorur dhe ndryshojeni kudo, përfshirë dosjet home dhe grupet, që të mos zëvendësoni çelësat e dikujt tjetër.
Kontrolloni sistemin e burimet, shqyrtoni përditësimet dhe krijoni administratorin. Zgjidhni fjalëkalim të fortë për kërkesat sudo. Komandat install vendosin pronësinë dhe lejet e kufizuara të çelësit.
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_keysNë një terminal tjetër në kompjuterin tuaj, hyni si administratori i ri:
ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10Brenda këtij sesioni të ri në server, provoni sudo. Pasi pranohen kredencialet e deploy, rezultati duhet të jetë root. Vazhdoni vetëm kur hyrja dhe kjo provë funksionojnë; ruani aksesin fillestar.
sudo whoamiInstaloni Nginx dhe përdorni firewall e mbështetur
Në server instaloni dhe nisni Nginx. Si firewall i ofruesit ashtu edhe ai brenda sistemit ndikojnë në lidhje. Mbajeni konsolën dhe sesionin funksional të hapur.
sudo apt install nginx
sudo systemctl enable --now nginxTe firewall i ofruesit lejoni TCP 22 nga vendndodhja juaj administrative dhe TCP 80/443 për vizitorët. Nëse SSH përdor port tjetër, ruani atë rregull. Leja në cloud nuk hap një port që bllokohet nga sistemi.
Oracle Cloud Ubuntu: mos ekzekutoni bllokun UFW më poshtë. UFW mund të ndërhyjë te rregullat thelbësore të imazhit dhe nisja e sistemit. Ruani iptables, përfshirë rregullat iSCSI për boot e block volumes. Përdorni OCI security lists/NSG dhe rregullat e dokumentuara të sistemit për HTTP/HTTPS; mos i zbrazni rregullat dhe mos zëvendësoni paketat firewall.
Për imazhe të tjera të reja Ubuntu: blloku vlen vetëm nëse ofruesi mbështet UFW dhe imazhi nuk kërkon konfigurim tjetër. Lejoni portën reale SSH para aktivizimit; këtu është 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 verbosePas secilës rrugë provoni hyrje të re SSH. Sesioni i vjetër nuk është kjo provë. Para certifikatës duhet të kalojë edhe kontrolli i jashtëm HTTP në hapin vijues.
Publikoni faqen në konfigurim të veçantë Nginx
Në server krijoni dosjen e faqes dhe konfigurimin e ri. Zëvendësoni hostname brenda bllokut. Ruani thonjëzat te EOF që shell të mos zëvendësojë variabla Nginx si $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 -tBëni reload në server vetëm nëse nginx -t përfundon me sukses:
sudo systemctl reload nginxNga kompjuteri juaj kërkoni hostname në adresën e serverit përpara ndryshimit të DNS. Duhet të merrni titullin e faqes suaj, jo faqen fillestare të Nginx.
curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/Lidhni DNS dhe lëshoni certifikatën HTTPS
Krijoni A record për IPv4 të VPS-it. Publikoni AAAA vetëm kur IPv6 punon realisht; një rekord i vjetër mund të çojë vizitorët dhe verifikimin e certifikatës diku tjetër. Shembulli përdor DNS drejtpërdrejt drejt VPS-it, pa proxy.
Në kompjuter kërkoni http://app.example.com/ pa --resolve dhe vazhdoni kur merrni faqen tuaj. Pastaj në server instaloni Certbot dhe shtesën Nginx nga Ubuntu archive. Paketat kërkojnë Universe; zgjidhni një gabim package-not-found para vazhdimit.
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.timerPlotësoni email dhe lexoni kushtet. Certbot ndryshon konfigurimin e kësaj faqeje dhe aktivizon ridrejtimin HTTP→HTTPS. Verifikoni dry-run dhe timer e rinovimit; nëse është joaktiv, aktivizojeni me sudo systemctl enable --now certbot.timer. Mbajeni portën 80 të arritshme për validim dhe rinovim HTTP.
Kontrolloni nga jashtë dhe pas rindezjes
Në kompjuterin tuaj verifikoni ridrejtimin, certifikatën dhe përmbajtjen. HTTP duhet të ridrejtojë në HTTPS, që duhet të japë titullin e pritur. Mos shtoni -k te curl për të fshehur gabime certifikate.
curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/Ndërsa instalimi është ende provë, ekzekutoni sudo reboot në server. Kjo mbyll qëllimisht SSH. Kur serveri të kthehet, hyni si deploy, kontrolloni systemctl is-active nginx dhe përsëritni kërkesën e jashtme HTTPS. Nëse nuk kthehet, përdorni konsolën.
Diagnostikoni dështimin dhe ruani mënyrën e rikthimit
Në ekran të vogël, lëvizeni tabelën anash për të parë të gjitha kolonat.
| Simptoma | Kontrolli fillestar |
|---|---|
| SSH timeout | Adresa, firewall i ofruesit dhe sistemit, konsola e rikuperimit |
| Permission denied (publickey) | Përdoruesi, çelësi privat dhe lejet authorized_keys |
| Faqja fillestare e Nginx | DNS, server_name dhe konfigurimi i aktivizuar |
| Dështim i certifikatës | A/AAAA publike dhe arritshmëria e portës 80 |
| Nginx dështon pas ndryshimit | sudo nginx -t dhe sudo journalctl -u nginx -n 50 --no-pager |
Për hyrje të dështuar ndiqni diagnostikimin SSH para ndryshimeve të rastësishme. Ruani jashtë VPS-it skedarët, konfigurimin Nginx, DNS dhe hapat e rindërtimit. Nëse kopjoni çelësa privatë certifikate, mbrojeni ruajtjen e tyre.
Shtoni njoftime për disponueshmërinë dhe skadimin e certifikatës; një sukses sot nuk monitoron rinovimin nesër. Filloni me rikthimin e kopjes së skedarëve pa prekur faqen aktive. Rikuperimi i plotë kërkon edhe asetet, certifikatat dhe konfigurimin tjetër.
Ky instalim shërben skedarë statikë. Baza ose runtime aplikacioni kërkon konfigurim shërbimi dhe backup të vetin. Kur i shtoni, përdorni matjen e burimeve Linux VPS.
Pyetje të shpeshta
A mund t’i përdor këto komanda në një faqe ekzistuese?
Filloni në VPS prove të veçantë. Shembulli krijon skedarë, aktivizon firewall dhe lejon Certbot të ndryshojë Nginx. Serveri aktiv kërkon shqyrtim të faqeve, aksesit dhe rikuperimit ekzistues.
A instalon WordPress, Node.js ose bazë të dhënash?
Jo. Rezultati është faqe statike HTTPS. Ruani këtë pikë funksionale, pastaj shtoni runtime dhe provoni nisjen, shëndetin e shërbimit dhe rikuperimin e të dhënave.