A primeira hora com a VM. Sai do estado "recebi um IP, um usuário e uma senha" e chega no estado "to dentro, senha trocada, sudo respondendo, firewall conhecido". Sem essa fase, nenhuma das próximas roda.
Os exemplos usam placeholders genéricos: IP_DA_VM, seu-usuario, senha-inicial, sua-senha-nova. Substitua pelos valores reais do seu setup.
Abre um terminal no Windows (Windows Terminal, PowerShell, cmd, ou cliente gráfico tipo MobaXterm / PuTTY / Termius — todos funcionam) e roda:
ssh seu-usuario@IP_DA_VMO SSH mostra uma mensagem grande com a fingerprint da máquina e pergunta se você confia:
The authenticity of host 'IP_DA_VM (IP_DA_VM)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Are you sure you want to continue connecting (yes/no/[fingerprint])?Responde yes e dá Enter. A fingerprint fica guardada no seu computador no arquivo ~/.ssh/known_hosts, e o SSH nunca mais pergunta. Se um dia a fingerprint mudar do nada, o SSH grita — porque pode ser um ataque de homem-no-meio.
Quando o SSH pede a senha, nada aparece na tela. Sem asterisco, sem ponto, o cursor não se mexe. Dá a impressão de que o teclado não funciona — mas funciona normal. É proposital: quem está do seu lado não vê nem o tamanho da senha. Digita, Enter, vai.
Na primeira vez que você loga, o sistema não te dá o shell de cara. Marca a conta como "senha expirada" e força a troca antes de tudo:
You are required to change your password immediately (administrator enforced).
Changing password for seu-usuario.
Current password: ← digite a senha-inicial de novo
New password: ← escolha uma senha NOVA forte
Retype new password: ← repita a senha novaTrês digitações, todas invisíveis. Se a confirmação bater, o sistema aceita e a sessão SSH cai imediatamente — é normal. Reconecta com a senha nova:
ssh seu-usuario@IP_DA_VMDica: no Windows Terminal você consegue colar a senha com Ctrl+Shift+V ou clique direito do mouse. Nada aparece na tela enquanto cola — é normal, só dá Enter.
Authentication token manipulation errorSe você ver isso depois de digitar as três senhas:
passwd: Authentication token manipulation error
passwd: password unchanged
Connection to IP_DA_VM closed.Causas mais comuns, em ordem:
Current password. Ele pede a senha atual (ainda é a inicial — senha-inicial). Não a nova que você acabou de inventar. Erro clássico: colar a senha nova nos três campos.pam_pwquality). Quando é esse o caso, aparece uma linha tipo BAD PASSWORD: ... logo acima do erro principal.A sessão cai depois do erro. Reconecta com ssh seu-usuario@IP_DA_VM usando a senha inicial (que ainda é válida — nada foi trocado) e tenta de novo.
12345678, qwerty, seu nome)Em qualquer outro dia, já logado, o comando é:
passwdEle pede a senha atual e a nova duas vezes.
Dentro da SUA VM você tem sudo total. Isso significa que você é root quando precisa. Pode instalar e remover pacotes, parar e iniciar serviços, abrir e fechar portas no firewall, criar e remover usuários, reconfigurar o que quiser.
sudo apt update
sudo systemctl restart tomcat
sudo ufw allow 8443/tcpQuando você usa sudo, o sistema pede sua senha (a mesma do login).
Num setup típico, dois papéis administrativos coexistem:
| Papel | Escopo | Pode | NÃO pode |
|---|---|---|---|
| Você | Admin da VM | Sudo livre dentro da VM | Mexer no host que hospeda a VM |
| Admin do host | Dono do hardware / hypervisor | Acessar a VM via console em caso de emergência | Mexer no que rola dentro da sua VM no dia-a-dia |
O firewall do host bloqueia as portas administrativas (SSH 22, RDP 3389, SMB 445, WinRM) entre a VM e o host. O firewall da VM também bloqueia o mesmo caminho. Os dois lados travam. Se um dia a VM for invadida, o atacante fica preso dentro dela — não consegue saltar pro host nem pras outras VMs do mesmo host.
Essa camada de isolamento não deve ser removida — ela protege você e protege os outros.
| Pode (sudo livre) | NÃO pode |
|---|---|
Instalar/remover pacotes (sudo apt install ...) | Acessar serviços admin do host (SSH/RDP/SMB/WinRM) |
Reiniciar/parar/iniciar serviços (sudo systemctl ...) | Mudar o que está rodando fora da VM |
Abrir/fechar portas no firewall (sudo ufw ...) | Acessar arquivos no host |
Criar/remover usuários (sudo adduser ...) | (Tudo o resto: dentro da VM você é root) |
| Instalar Tailscale, cloudflared, Docker, k3s, o que quiser |
A VM tem um IP fixo, um gateway (saída pra internet), DNS, e um firewall chamado ufw. O ufw é uma camada simples por cima do iptables — bem fácil de operar.
sudo ufw statusNuma VM típica logo no começo, as portas de entrada abertas são:
| Porta | Serviço | Pra quê |
|---|---|---|
| 22 | SSH | Você entra por aqui |
| 8080 | Tomcat | App responde aqui (depois de deployar) |
A saída pra internet em geral é livre — você consegue baixar pacotes, clonar repositórios, baixar imagens Docker. As regras de saída são mais permissivas que as de entrada.
sudo ufw allow 8443/tcp comment 'HTTPS do meu app'
sudo ufw status numberedO comment é opcional mas ajuda muito a lembrar pra que serve cada regra depois. O status numbered mostra cada regra com um número, útil pra remover uma regra específica.
Cuidado: cada porta aberta é mais uma superfície de ataque. Só abra o que vai usar de verdade.
Digitar senha toda vez que loga é chato e é menos seguro do que parece. O jeito profissional é usar uma chave SSH. Gera um par de chaves no seu Windows uma única vez (no PowerShell, não na VM):
ssh-keygen -t ed25519Aceita os defaults dando Enter em tudo (incluindo passphrase vazia, se quiser login sem digitar nada). Isso cria dois arquivos em C:\Users\seu-nome\.ssh\:
id_ed25519 — chave privada, nunca compartilhe com ninguém, nunca sai do notebookid_ed25519.pub — chave pública, pode distribuir livremente, é o que vai pra VMPegadinha do Explorer do Windows: ele mostra o id_ed25519.pub como tipo "Microsoft Publisher Document" (por causa da extensão .pub). Não é — é só um arquivo de texto. Abre normal no Notepad.
No PowerShell do Windows, esse comando lê a sua chave pública e empurra direto pra VM:
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh seu-usuario@IP_DA_VM "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"Vai pedir sua senha uma última vez. Depois disso, login é direto. Funciona bem quando tudo dá certo — mas o comando é longo e quebra fácil se você colar errado.
Mais à prova de bobeira. Abre o id_ed25519.pub no Notepad, copia a linha inteira (começa com ssh-ed25519 AAAA... e termina com usuario@MAQUINA), e já logado na VM por senha, cola um comando por vez:
1. Cria a pasta ~/.ssh se não existir:
mkdir -p ~/.ssh2. Ajusta a permissão da pasta (SSH ignora pastas com permissão aberta demais):
chmod 700 ~/.ssh3. Acrescenta sua chave no fim do authorized_keys:
echo 'ssh-ed25519 AAAA...sua-chave-publica-inteira... usuario@MAQUINA' >> ~/.ssh/authorized_keys'...') preservam o conteúdo literal — a chave tem /, +, = que o bash poderia interpretar>> acrescenta no fim (se usar > com uma só, apaga o que tinha — perigoso quando você já tem outras chaves lá)4. Ajusta a permissão do arquivo (sem isso, o SSH ignora a chave por segurança):
chmod 600 ~/.ssh/authorized_keysConfere com cat ~/.ssh/authorized_keys — tem que mostrar sua linha inteira. Aí exit, e do PowerShell roda ssh seu-usuario@IP_DA_VM — entra direto, sem pedir senha.
Uma chave Ed25519 de 256 bits é infinitamente mais difícil de adivinhar do que qualquer senha de texto. Mais rápido e mais seguro.
Importante: a chave só funciona pro computador onde a chave privada mora. Se trocar de notebook, gera uma chave nova no novo notebook e adiciona a pública dele no mesmo authorized_keys da VM.
Sequência mínima pra deixar a VM utilizável:
seu-usuario / senha-inicialsudo responde (sudo whoami deve devolver root)sudo ufw statusCom isso pronto, a VM está em estado utilizável pra qualquer uma das próximas fases: Tomcat (deploy de app), PostgreSQL (banco), Tailscale (rede privada) ou Cloudflare Tunnel (domínio próprio com HTTPS).