Como configurar um VPS Ubuntu para publicar seu site

Prepare a instância, o domínio e a recuperação

Você precisa de uma instância nova Ubuntu 24.04, IPv4 pública, SSH na porta 22, conta inicial com sudo e um domínio que controla. Gere a chave antes de criar a VM. Se ela já existe e está vazia, use a alternativa que aproveita um acesso válido. Os comandos do cliente usam Bash no Linux, macOS ou WSL; os do servidor rodam dentro de SSH.

Substitua 203.0.113.10 pelo IP real e app.example.com pelo seu domínio: ambos são exemplos reservados para documentação. O usuário inicial mostrado é ubuntu; confira o usuário indicado pelo provedor. Abra o console de recuperação antes de alterar acessos ou firewall. Pare se os caminhos do exemplo já pertencerem a outro site.

Gere a chave e escolha apenas um caminho de instalação

No seu computador, crie uma chave exclusiva com senha. Se o arquivo já existir, escolha outro nome em todos os comandos. O arquivo .pub é público; o arquivo sem essa extensão deve ficar privado no computador.

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

VM ainda não criada: crie o Ubuntu 24.04 enviando a chave pública no campo SSH do provedor. Confira a conta inicial e siga para a verificação da impressão digital. Pule os comandos para servidor existente.

VM vazia já criada: mantenha sua sessão SSH válida aberta. Em outro terminal do computador, copie a chave pública usando a autenticação atual. Troque existing_vps_key pela chave privada que já funciona. Se usa senha ou agente SSH, omita -i ~/.ssh/existing_vps_key sem mudar a política de autenticação.

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

Na sessão já aberta do servidor, valide o arquivo e acrescente a chave à sua conta inicial. O bloco preserva entradas anteriores e inclui uma quebra de linha para não unir duas chaves. Sem nenhum acesso válido, use primeiro a recuperação do provedor.

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

Em qualquer caminho, compare a chave do servidor antes de aceitar o primeiro login. No console confiável do sistema convidado, para uma chave de host Ed25519:

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

No seu computador, abra uma conexão nova com a chave recém-criada. Compare o tipo e a impressão digital apresentados com o console. Preserve o acesso anterior até funcionar.

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

Em outro terminal do computador, envie a chave pública que será usada pelo administrador separado. Reenviar esse arquivo temporário é permitido se ele já foi enviado no caminho da VM existente.

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

Crie um administrador sem substituir outro usuário

No servidor, execute primeiro getent passwd deploy. O resultado deve estar vazio. Se a conta existe, escolha um nome livre e altere todas as referências, inclusive grupo e pasta pessoal. Isso evita substituir o authorized_keys de outra pessoa.

Confira o sistema, revise as atualizações e crie o administrador. A senha definida será usada pelo sudo. Os comandos install dão à nova conta a propriedade da pasta e da chave, com permissões restritas.

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

Em outro terminal no seu computador, entre como esse novo administrador:

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

Dentro da nova sessão no servidor, teste sudo. Após aceitar a senha, o resultado esperado é root. Continue nessa sessão somente quando login e sudo funcionarem; mantenha o acesso inicial disponível.

sudo whoami

Instale Nginx e use o firewall compatível com a imagem

No servidor, instale e habilite Nginx. As regras do provedor e as do sistema convidado precisam permitir a conexão; mantenha console e SSH disponíveis durante ajustes.

sudo apt install nginx
sudo systemctl enable --now nginx

Na rede do provedor, permita TCP 22 da sua origem administrativa e TCP 80/443 para os visitantes. Preserve a porta real do SSH se ela não for 22. Uma regra externa não libera uma porta bloqueada dentro do Ubuntu.

Imagens Ubuntu na Oracle Cloud: pule todo o bloco UFW a seguir. UFW pode conflitar com regras essenciais da imagem e impedir a inicialização. Preserve as regras iptables fornecidas, incluindo iSCSI dos volumes de inicialização e bloco. Configure listas de segurança/NSGs e as regras documentadas do sistema convidado para HTTP/HTTPS. Não limpe as regras nem substitua os pacotes de firewall.

Outras imagens Ubuntu novas com suporte a UFW: use este bloco somente quando o provedor permitir UFW e a imagem não exigir outro gerenciamento de firewall. Libere a porta efetiva do SSH antes de ativar; aqui ela é 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

Após qualquer uma das alternativas, teste um login SSH novo. Uma sessão antiga continuar aberta não valida novas conexões. O teste HTTP externo da próxima etapa também deve funcionar antes de emitir o certificado.

Publique em uma configuração própria do Nginx

No servidor, crie uma pasta e um bloco novos para o site. Troque o domínio dentro do exemplo. Mantenha as aspas em EOF para que o shell não expanda variáveis do Nginx, como $uri.

sudo install -d -m 755 /var/www/first-site
printf '%s\n' '<!doctype html><html lang="pt-BR"><title>Primeira publicação</title><h1>Esta página está no VPS 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

Recarregue Nginx somente se nginx -t terminar com sucesso:

sudo systemctl reload nginx

No seu computador, teste o domínio apontando diretamente para o IP antes de mudar DNS. Espere o título que acabou de criar, não a página padrão do Nginx.

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

Aponte DNS e ative HTTPS

Crie um registro A do domínio para a IPv4. Publique AAAA apenas se IPv6 estiver funcionando; um registro antigo pode enviar visitantes e a validação do certificado ao destino errado. Este caminho considera DNS direto para o VPS, sem proxy.

No computador, abra http://app.example.com/ sem --resolve. Quando retornar sua página, instale no servidor os pacotes Certbot do Ubuntu e o plugin Nginx. Eles exigem o repositório Universe; resolva erros de pacote inexistente antes 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

Responda ao e-mail e aos termos pedidos pelo Certbot. Ele modifica o site e habilita o redirecionamento HTTP para HTTPS. Confira se o timer de renovação está agendado; se estiver inativo, use sudo systemctl enable --now certbot.timer. Mantenha a porta 80 acessível para a validação HTTP e as renovações.

Confira de fora do servidor e depois de reiniciar

No seu computador, verifique redirecionamento, certificado e conteúdo. HTTP deve redirecionar e HTTPS deve devolver seu título. Não use curl -k: essa opção esconde erros de validação do certificado.

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

Enquanto ainda for um ambiente de teste, execute sudo reboot no servidor. Reconecte como deploy, confira systemctl is-active nginx e repita a requisição HTTPS externa. Reiniciar fecha as sessões SSH de propósito; recorra ao console se a máquina não voltar.

Diagnostique falhas e preserve uma cópia recuperável

Deslize a tabela para ver todas as colunas →

Para falhas de login, use o diagnóstico SSH antes de alterar autenticação. Guarde arquivos, configuração Nginx, DNS e passos de reconstrução fora da VM. Chaves privadas de certificados exigem armazenamento protegido se forem copiadas.

O teste de backup e restauração recupera uma página e uma configuração sem substituir o site em execução. A recuperação completa ainda precisa dos demais arquivos, certificados e serviços.

Configure alertas de disponibilidade e vencimento do certificado. Uma resposta correta hoje não monitora a renovação de amanhã. Este percurso entrega arquivos estáticos; banco e runtime exigem configuração e backup próprios. Para acrescentá-los, use a medição de recursos.

Perguntas e respostas