Configuració d’un Ubuntu VPS amb SSH, Nginx i HTTPS
Configura un VPS nou amb Ubuntu 24.04 LTS i publica un lloc estàtic petit amb Nginx i HTTPS. La guia inclou una clau SSH, un administrador separat, renovació del certificat i verificació després de reiniciar.
VPSuntu · Actualització: · Lectura: uns 7 min
Contingut de la guia
Prepara servidor, domini i accés de recuperació
Necessites un Ubuntu 24.04 nou amb IPv4 pública, SSH al port 22, un compte inicial amb sudo i un domini que controlis. Genera la clau al pas següent abans de crear el servidor. Si el VPS buit ja existeix, afegeix-la a través de l’accés que funciona. Les ordres locals utilitzen Bash en Linux, macOS o WSL; les del servidor s’executen dins d’SSH. Atura’t si les rutes pertanyen a un desplegament existent.
Substitueix 203.0.113.10 per la IP i app.example.com pel hostname; són exemples de documentació. L’usuari inicial és ubuntu: posa el del proveïdor. Obre la consola de recuperació abans de canviar accés o tallafoc. Revisa les instruccions de la imatge: Oracle Ubuntu requereix una alternativa a UFW.
Crea la clau abans de la VM o afegeix-la amb l’accés existent
Al teu ordinador, crea una clau dedicada amb frase de pas. Si el nom ja existeix, tria’n un altre a tots els passos. El fitxer .pub és públic; conserva el privat al teu ordinador.
mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pubVPS nou: crea ara el servidor Ubuntu 24.04 i proporciona la clau pública al camp SSH del proveïdor. Confirma l’usuari inicial i continua amb la verificació de l’empremta del servidor; omet les ordres per al VPS existent.
VPS buit ja creat: deixa oberta la sessió que funciona. En un altre terminal local, copia la clau pública amb l’autenticació existent. Substitueix existing_vps_key pel fitxer privat actual. Si accedeixes amb contrasenya o agent, omet -i ~/.ssh/existing_vps_key; no canviïs la política del servidor.
scp -i ~/.ssh/existing_vps_key ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pubA la sessió existent del servidor, valida el fitxer públic i afegeix-lo a authorized_keys del teu compte inicial. S’hi conserven les entrades anteriors; el salt de línia cobreix un fitxer sense salt final. Si no tens accés, recupera’l amb el proveïdor abans de continuar.
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
fiEn tots dos casos, compara l’empremta del primer accés amb la clau pública del host a la consola fiable. Per a una clau de host Ed25519, executa-hi:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pubAl teu ordinador, obre una connexió nova amb la clau. Mantén l’accés original fins que funcioni.
ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10Des d’un altre terminal local, copia la clau pública per a l’administrador que crearàs. Pots tornar a copiar aquest fitxer temporal si ja l’havies pujat.
scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pubCrea un administrador i comprova’l per separat
Al servidor, executa primer getent passwd deploy. No ha de retornar cap compte. Si ja existeix, tria un nom lliure i substitueix-lo arreu, inclosos directoris personals i grups, per no reemplaçar claus d’un altre usuari.
Confirma imatge i recursos, revisa actualitzacions i crea el compte amb una contrasenya robusta per a sudo. Les ordres install fixen propietari i permisos restrictius del fitxer de claus.
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_keysEn un altre terminal local, connecta com a nou administrador:
ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10Dins d’aquesta nova sessió del servidor, prova sudo. Ha d’imprimir root després d’acceptar la contrasenya de deploy. Continua aquí quan totes dues comprovacions funcionin; conserva l’accés inicial.
sudo whoamiInstal·la Nginx i utilitza el tallafoc admès
Al servidor, instal·la primer Nginx. Tant el tallafoc de xarxa del proveïdor com el del sistema convidat afecten l’accés. Conserva consola i sessió SSH durant els canvis.
sudo apt install nginx
sudo systemctl enable --now nginxAl proveïdor, permet TCP 22 des de la ubicació d’administració i TCP 80/443 per als visitants. Si SSH usa un altre port, conserva la regla corresponent. Les regles de xarxa no obren ports bloquejats dins de la VM.
Imatges Ubuntu d’Oracle Cloud: omet tot el bloc UFW. Oracle avisa de conflictes amb regles essencials que poden impedir l’arrencada. Conserva iptables, inclosa la protecció d’iSCSI per als volums boot i block. Configura security lists o NSG i les regles guest documentades per a HTTP/HTTPS. No buidis les regles ni substitueixis els paquets del tallafoc.
UFW en altres imatges Ubuntu noves: només si el proveïdor l’admet i no exigeix un tallafoc gestionat diferent. Permet el port SSH real abans d’activar-lo; l’exemple assumeix 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 verboseDesprés de qualsevol branca, comprova un inici SSH nou. Una sessió oberta no prova una connexió nova. La comprovació HTTP externa següent també ha de funcionar abans de demanar el certificat.
Publica una pàgina en un lloc Nginx propi
Al servidor, crea un document root i una configuració nous. Canvia el hostname dins del bloc. Conserva els delimitadors EOF entre cometes: eviten que el shell expandeixi variables Nginx com $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 -tAl servidor, recarrega només si la prova de configuració té èxit:
sudo systemctl reload nginxDes del teu ordinador, demana el hostname a la IP del servidor abans de canviar DNS. Has de veure el teu encapçalament, no la benvinguda predeterminada de Nginx.
curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/Configura DNS i emet el certificat HTTPS
Crea un registre A que apunti a la IPv4. Publica AAAA només si IPv6 funciona: un registre antic pot enviar visitants i validació a un altre lloc. L’exemple assumeix DNS directe, sense proxy.
Localment, demana http://app.example.com/ sense --resolve. Quan retorni la pàgina, instal·la al servidor Certbot de l’arxiu Ubuntu i el connector Nginx. Requereixen Universe; resol qualsevol paquet no trobat abans de seguir.
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.timerRespon els avisos de correu i condicions. Certbot modifica aquest lloc i activa la redirecció HTTP→HTTPS. Confirma el temporitzador de renovació; si és inactiu, executa sudo systemctl enable --now certbot.timer. Mantén el port 80 accessible per validar i renovar.
Verifica des de fora i després de reiniciar
Al teu ordinador, comprova redirecció, certificat i contingut. HTTP ha de redirigir a HTTPS i HTTPS ha de mostrar el teu encapçalament. No afegeixis curl -k: amaga errors de validació.
curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/Mentre encara és una instal·lació de prova, executa sudo reboot al servidor. Torna a entrar com deploy, comprova systemctl is-active nginx i repeteix HTTPS des de fora. El reinici tanca SSH expressament; utilitza la consola si no torna.
Diagnostica una comprovació fallida i conserva el desplegament
En pantalles petites, desplaça la taula lateralment per veure totes les columnes.
| Símptoma | Primeres comprovacions |
|---|---|
| SSH timeout | Adreça, tallafocs del proveïdor i del sistema, consola |
| Permission denied (publickey) | Usuari, clau privada i permisos d’authorized_keys |
| Pàgina Nginx predeterminada | Destinació DNS, server_name i lloc habilitat |
| Validació de certificat fallida | Registres A/AAAA públics i port 80 |
| Nginx falla després d’un canvi | sudo nginx -t i sudo journalctl -u nginx -n 50 --no-pager |
Segueix el diagnòstic SSH abans de modificar l’accés. Conserva fitxers, configuració, DNS i passos de reconstrucció fora del VPS i restaura’ls en una altra màquina. Les claus privades TLS requereixen protecció si les copies. Afegeix alertes de disponibilitat i caducitat: una comprovació d’avui no vigila la renovació de demà.
L’exercici de backup i restauració verifica una còpia independent sense sobreescriure el lloc. La recuperació completa també necessita els altres recursos, certificats i serveis. Aquí se serveixen fitxers estàtics; una base o runtime exigeix configuració i còpia pròpies. En afegir-los, mesura els recursos.
Preguntes freqüents
Puc aplicar les ordres a un lloc existent?
Prova-les primer en un VPS separat. L’exemple crea fitxers, activa un tallafoc i permet a Certbot editar Nginx. Un servidor existent exigeix revisar llocs, regles d’accés i recuperació.
Això instal·la WordPress, Node.js o una base?
No. Produeix un lloc estàtic HTTPS. Conserva aquesta base funcional i després incorpora el runtime amb proves d’arrencada, salut i recuperació de dades.