Guia pràctica / configuració d’un Ubuntu VPS

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.

· 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.pub

VPS 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.pub

A 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
fi

En 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.pub

Al 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.10

Des 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.pub

Crea 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_keys

En un altre terminal local, connecta com a nou administrador:

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

Dins 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 whoami

Instal·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 nginx

Al 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 verbose

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

Al servidor, recarrega només si la prova de configuració té èxit:

sudo systemctl reload nginx

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

Respon 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ímptomaPrimeres comprovacions
SSH timeoutAdreça, tallafocs del proveïdor i del sistema, consola
Permission denied (publickey)Usuari, clau privada i permisos d’authorized_keys
Pàgina Nginx predeterminadaDestinació DNS, server_name i lloc habilitat
Validació de certificat fallidaRegistres A/AAAA públics i port 80
Nginx falla després d’un canvisudo 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.

Les ordres provenen de l’exemple EN per a Ubuntu 24.04. Substitueix les adreces de documentació i respecta els requisits de la imatge.

Fonts oficials

  1. Document 1: ubuntu.com
  2. Document 2: ubuntu.com
  3. Document 3: ubuntu.com
  4. Document 4: eff-certbot.readthedocs.io
  5. Document 5: packages.ubuntu.com
  6. Document 6: docs.oracle.com

Guies relacionades