Konfiguracja VPS Ubuntu krok po kroku: pierwsza strona HTTPS

Przygotuj serwer, domenę i drogę awaryjną

Potrzebujesz nowego Ubuntu 24.04, publicznego IPv4, SSH na porcie 22, początkowego konta z sudo i domeny pod Twoją kontrolą. Klucz wygeneruj w następnej części przed utworzeniem VM. Jeśli pusty serwer już istnieje, użyj opisanej alternatywnej ścieżki przez działający dostęp.

Polecenia klienta wykonuj w Bash na Linux, macOS lub WSL, a serwera — wewnątrz SSH. Zastąp 203.0.113.10 swoim adresem, app.example.com swoją nazwą i ubuntu właściwym kontem. To przykładowe wartości dokumentacyjne. Zatrzymaj się, jeśli ścieżki należą do istniejącego wdrożenia.

Otwórz konsolę odzyskiwania przed zmianą dostępu lub zapory. Sprawdź zalecenia dostawcy obrazu: Oracle Cloud Ubuntu wymaga innej konfiguracji niż opisana później gałąź UFW.

Utwórz klucz i potwierdź nowe logowanie

Na komputerze utwórz osobny klucz z hasłem. Jeśli nazwa pliku istnieje, wybierz inną i zamień ją konsekwentnie. Plik .pub jest publiczny; plik prywatny pozostaje na komputerze.

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

Nowa VM: utwórz serwer Ubuntu 24.04, podając ten klucz publiczny w panelu. Potwierdź początkową nazwę użytkownika, pomiń polecenia dodawania klucza do istniejącego konta i przejdź do kontroli odcisku hosta.

Już utworzony pusty VPS: zachowaj działającą sesję. Z drugiego lokalnego terminala skopiuj nowy klucz publiczny, używając obecnego uwierzytelniania. Zastąp existing_vps_key nazwą dotychczasowego klucza. Przy haśle lub agencie pomiń opcję -i ~/.ssh/existing_vps_key, zachowując obecną politykę logowania.

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

W dotychczasowej sesji serwera sprawdź przesłany plik i dopisz klucz do authorized_keys własnego konta początkowego. Dopisanie zachowuje poprzednie wpisy, a nowa linia obsługuje plik, który kończył się bez niej. Bez działającego dostępu najpierw użyj odzyskiwania u dostawcy.

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

W obu ścieżkach potwierdź klucz hosta przed pierwszą akceptacją. W zaufanej konsoli serwera sprawdź klucz tego samego algorytmu, który pokazuje klient. Dla Ed25519:

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

Na komputerze połącz się w nowej sesji z użyciem nowego klucza. Zachowaj pierwotny dostęp do chwili powodzenia:

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

W drugim lokalnym terminalu prześlij plik publiczny dla administratora tworzonego w kolejnym kroku. Powtórne przesłanie tego tymczasowego pliku jest dopuszczalne, jeśli już go dodałeś w ścieżce istniejącego serwera.

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

Dodaj osobnego administratora

Na serwerze najpierw sprawdź getent passwd deploy. Wynik powinien być pusty. Jeżeli konto istnieje, wybierz nieużywaną nazwę i zamień ją wszędzie, w tym w grupach i ścieżkach domowych. Zapobiega to zastąpieniu kluczy innego użytkownika.

Potwierdź system i zasoby, przejrzyj aktualizacje, następnie utwórz konto. Ustaw mocne hasło używane przy sudo. Polecenia install nadają właściwego właściciela i ograniczone uprawnienia do pliku kluczy.

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

W nowym terminalu na komputerze zaloguj się jako utworzony administrator:

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

W tej nowej sesji wykonaj sudo. Po podaniu hasła konta deploy polecenie powinno wypisać root. Kontynuuj dopiero, gdy oba sprawdzenia działają; nie zamykaj jeszcze poprzedniego dostępu.

sudo whoami

Zainstaluj Nginx i właściwie skonfiguruj zaporę

Na serwerze zainstaluj Nginx. Zostaw dostępną konsolę awaryjną i działającą sesję SSH podczas zmian reguł.

sudo apt install nginx
sudo systemctl enable --now nginx

W zaporze dostawcy zezwól na TCP 22 z miejsca administracji oraz TCP 80/443 dla odwiedzających. Jeśli używasz innego portu SSH, zachowaj go. Zapora systemu gościa także musi przepuszczać potrzebny ruch.

Obrazy Ubuntu w Oracle Cloud: pomiń cały poniższy blok UFW. Może on naruszyć istotne reguły obrazu, także iSCSI dla wolumenów rozruchowych i blokowych, i uniemożliwić start. Zachowaj iptables obrazu. Ustaw listy zabezpieczeń lub NSG w OCI oraz udokumentowane reguły HTTP/HTTPS systemu gościa. Nie czyść reguł ani nie zastępuj pakietów zapory.

Gałąź UFW dla innych nowych obrazów: użyj jej tylko wtedy, gdy dostawca obsługuje UFW, a obraz nie wymaga innej zarządzanej konfiguracji. Zezwól na rzeczywisty port SSH przed włączeniem zapory; przykład używa 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

Po każdej z gałęzi przetestuj nowe logowanie SSH. Otwarta wcześniej sesja nie sprawdza nowego połączenia. Zewnętrzny test HTTP w następnej części musi się udać przed żądaniem certyfikatu.

Opublikuj stronę w osobnej konfiguracji Nginx

Na serwerze utwórz nowy katalog i konfigurację. Wstaw własną nazwę domenową do bloku. Zachowaj cytowane znaczniki EOF, aby powłoka nie rozwijała zmiennych Nginx, takich jak $uri.

sudo install -d -m 755 /var/www/first-site
printf '%s\n' '<!doctype html><html lang="pl"><title>Pierwsze wdrożenie</title><h1>Tę stronę obsługuje VPS z Ubuntu</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

Przeładuj usługę na serwerze wyłącznie po pomyślnym teście konfiguracji:

sudo systemctl reload nginx

Na komputerze odpytaj nazwę bez zmiany DNS, wskazując adres VPS. Wynik powinien zawierać Twój nagłówek, a nie domyślną stronę Nginx.

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

Ustaw DNS i certyfikat HTTPS

Dodaj rekord A wskazujący na IPv4 VPS. Rekord AAAA publikuj tylko z działającą konfiguracją IPv6. Stary AAAA może skierować odwiedzających i weryfikację certyfikatu do innego hosta. Ten przykład zakłada DNS prowadzący bezpośrednio do VPS, bez proxy.

Na komputerze sprawdź http://app.example.com/ bez --resolve. Gdy zwraca Twoją stronę, na serwerze zainstaluj Certbot z repozytorium Ubuntu i wtyczkę Nginx. Pakiety wymagają komponentu Universe; najpierw rozwiąż ewentualny błąd braku pakietu.

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

Wypełnij pytania o e-mail i warunki. Certbot zmienia konfigurację strony i dodaje przekierowanie na HTTPS. Sprawdź zaplanowane odnawianie. Nieaktywny timer włącz przez sudo systemctl enable --now certbot.timer. Port 80 pozostaw dostępny do walidacji i odnowienia certyfikatu przez HTTP.

Sprawdź stronę z zewnątrz i po restarcie

Na komputerze potwierdź przekierowanie HTTP do HTTPS, poprawny certyfikat i treść strony. Nie dodawaj -k do curl, bo ukrywa błędy weryfikacji certyfikatu.

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

Gdy to nadal wdrożenie testowe, wykonaj sudo reboot na serwerze. Po powrocie zaloguj się jako deploy, sprawdź systemctl is-active nginx i powtórz zewnętrzne żądanie HTTPS. Restart celowo rozłącza sesje; jeśli maszyna nie wraca, skorzystaj z konsoli.

Rozpoznaj błąd i zachowaj możliwość odtworzenia

Przesuń tabelę, aby zobaczyć pozostałe kolumny →

Nieudane logowanie sprawdź według diagnostyki SSH, rozdzielając sieć, usługę i klucze. Pliki strony, konfigurację Nginx, rekordy DNS i instrukcję odbudowy przechowuj poza VPS. Kopie kluczy prywatnych certyfikatu wymagają chronionego miejsca.

Dodaj alerty dostępności i wygasania certyfikatu. Jedna udana próba nie monitoruje przyszłego odnowienia. Zacznij od testu kopii plików, a pełny powrót usługi sprawdź na oddzielnej maszynie z pozostałymi zasobami i certyfikatem.

Przykład obsługuje pliki statyczne. Aplikacja i baza wymagają własnych usług oraz metod kopii. Po ich dodaniu zastosuj pomiary zasobów.

Pytania i odpowiedzi