Поставување Ubuntu VPS со SSH, Nginx и HTTPS
Поставете свеж Ubuntu 24.04 LTS VPS и објавете мала статична страница со Nginx и HTTPS. Постапката опфаќа SSH клуч, посебен администратор, обновување сертификат и проверка по рестартирање.
VPSuntu · Ажурирано: · Читање: околу 7 мин
Содржина на водичот
Подгответе сервер, домен и пристап за обновување
Потребни се свеж Ubuntu 24.04 VPS со јавна IPv4, SSH на портата 22, почетна сметка со sudo и домен што го контролирате. Создајте SSH клуч во следниот дел пред серверот. Ако празниот сервер веќе постои, користете го алтернативниот пат преку работниот пристап. Клиентските команди се за Bash на Linux, macOS или WSL; серверските се извршуваат во SSH. Запрете ако примерните патеки припаѓаат на постојна инсталација.
Заменете 203.0.113.10 со адресата на VPS и app.example.com со вашиот hostname. Тоа се документациски примери. Почетниот корисник е ubuntu; внесете го корисникот на провајдерот. Отворете recovery console пред промена на пристап или firewall. Oracle Ubuntu images бараат поинаков пристап од UFW гранката подолу.
Создајте клуч пред серверот или додајте го преку работен пристап
На вашиот компјутер создајте посебен клуч со лозинка за заштита. Ако името веќе постои, користете друго во сите чекори. Само .pub датотеката е јавна; приватната останува кај вас.
mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pubЗа нов VPS: сега создајте Ubuntu 24.04 сервер и внесете го јавниот клуч во SSH полето на провајдерот. Потврдете го почетниот корисник и продолжете со проверката на host fingerprint. Прескокнете ги командите за постоен сервер.
За веќе создаден празен VPS: задржете ја работната SSH сесија. Во друг терминал на вашиот компјутер копирајте го јавниот клуч преку постојната автентикација. Заменете existing_vps_key со сегашниот приватен клуч. Ако користите лозинка или SSH agent, изоставете -i ~/.ssh/existing_vps_key; не менувајте ја серверската политика.
scp -i ~/.ssh/existing_vps_key ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pubВо постојната серверска сесија проверете ја прикачената јавна датотека и додајте ја во authorized_keys на вашата почетна сметка. Додавањето ги чува постојните записи, а новиот ред покрива датотека без завршен нов ред. Ако немате работен пристап, прво користете ја постапката за обновување на провајдерот.
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За двата пата, пред да прифатите нова врска споредете го host fingerprint со соодветниот јавен клуч во доверливата recovery console. За Ed25519 host key, во таа конзола извршете:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pubНа вашиот компјутер отворете нова врска со новиот клуч. Задржете го стариот пристап додека ова не успее.
ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10Во друг локален терминал копирајте го јавниот клуч за посебниот администратор од следниот дел. Дозволено е повторно да ја копирате оваа привремена јавна датотека ако веќе била прикачена.
scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pubСоздајте администратор и тестирајте го одделно
На серверот прво проверете getent passwd deploy. Не треба да врати сметка. Ако deploy постои, изберете слободно име и заменете го насекаде, вклучувајќи home патеки и групи, за да не замените туѓа датотека со клучеви.
Потврдете ги image и ресурсите, прегледајте ги ажурирањата и создајте ја сметката. Поставете силна лозинка за sudo. Командите install ги поставуваат сопственоста и ограничените дозволи на датотеката со клучот.
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 поддржан од image
На серверот прво инсталирајте Nginx. И мрежниот firewall кај провајдерот и firewall во VM влијаат на пристапот. Чувајте ги работната SSH сесија и recovery console.
sudo apt install nginx
sudo systemctl enable --now nginxКај провајдерот дозволете TCP 22 од вашата администраторска локација и TCP 80/443 за посетителите. Зачувајте го вистинскиот SSH порт ако е друг. Мрежно правило не отвора порта блокирана во VM.
Oracle Cloud Ubuntu images: прескокнете го целиот UFW блок. Oracle предупредува дека UFW може да ги наруши неопходните правила и да го спречи подигањето. Зачувајте ги испорачаните iptables правила, вклучувајќи ги iSCSI boot/block volume правилата. За HTTP/HTTPS користете OCI security lists или NSG и документираните guest правила. Не ги празнете правилата и не ги заменувајте firewall пакетите.
UFW за други свежи Ubuntu images: користете го само ако провајдерот го поддржува и нема друга управувана конфигурација. Дозволете го вистинскиот 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 најава. Веќе отворена сесија не е доказ за ново поврзување. Надворешната HTTP проверка во следниот дел мора да успее пред барање сертификат.
Објавете страница во посебен Nginx сајт
На серверот создајте нов document root и конфигурација. Заменете го 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На серверот повторно вчитајте Nginx само ако тестот на конфигурацијата успее:
sudo systemctl reload nginxОд вашиот компјутер побарајте го hostname на адресата на VPS пред промена на DNS. Треба да го видите вашиот наслов, а не стандардната Nginx страница.
curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/Поврзете DNS и издајте HTTPS сертификат
Создајте DNS A запис кон IPv4 на VPS. Додајте AAAA само ако IPv6 навистина работи; стар AAAA може да ги насочи посетителите и проверката на сертификатот на друго место. Примерот претпоставува директен DNS без proxy.
Локално побарајте http://app.example.com/ без --resolve. Кога ќе ја врати вашата страница, на серверот инсталирајте Certbot од Ubuntu архивата со Nginx додатокот. Пакетите бараат Universe; решете евентуално 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Следете ги прашањата за е-пошта и условите. Certbot ја менува конфигурацијата на овој сајт и додава HTTP→HTTPS пренасочување. Потврдете дека renewal timer е закажан; ако е неактивен, користете sudo systemctl enable --now certbot.timer. Портата 80 треба да остане достапна за HTTP проверка и обновување.
Проверете однадвор и по рестартирање
На вашиот компјутер проверете пренасочување, сертификат и содржина. 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 барање. Рестартирањето намерно ги затвора SSH сесиите; користете конзола ако серверот не се врати.
Дијагностицирајте неуспех и зачувајте ја инсталацијата
На мал екран поместете ја табелата странично за да ги видите сите колони.
| Симптом | Прва проверка |
|---|---|
| SSH timeout | Адреса, двата firewall и recovery console |
| Permission denied (publickey) | Корисник, приватен клуч и дозволи на authorized_keys |
| Стандардна Nginx страница | DNS одредиште, server_name и активен сајт |
| Неуспешна проверка на сертификат | Јавни A/AAAA записи и достапност на портата 80 |
| Nginx не работи по промена | sudo nginx -t и sudo journalctl -u nginx -n 50 --no-pager |
За неуспешна најава користете SSH дијагностика пред менување пристап. Чувајте ги датотеките, Nginx конфигурацијата, DNS записите и чекорите за повторно поставување надвор од VPS. Проверете враќање на друга машина. Приватните сертификатски клучеви бараат заштитено складирање. Додајте известувања за недостапност и истек на сертификат; една успешна проверка не го следи утрешното обновување.
Почнете со вежбата за резервна копија и враќање, која не ја препишува активната страница. Целосното обновување ги бара и останатите ресурси и сертификати. Овој пример служи статични датотеки; runtime и база бараат сопствени сервиси и backup. При нивно додавање користете мерење ресурси.
Често поставувани прашања
Можам ли да ги извршам командите на постоен сајт?
Прво користете посебен тест VPS. Примерот создава датотеки, вклучува firewall и му дозволува на Certbot да менува Nginx. Постоен сервер бара преглед на сајтовите, пристапот и постапката за обновување.
Дали се инсталираат WordPress, Node.js или база?
Не. Резултатот е статична HTTPS страница. Потоа додајте runtime и проверете подигање, здравје на апликацијата и враќање на податоците.