Trilha · SSH e VPS
Nove aulas curtas pra você conectar na sua VPS pelo terminal, entender as chaves SSH e resolver sozinho os travamentos mais comuns — sem esperar suporte técnico pra cada ajuste.
Aulas
Entenda o que acontece numa conexão remota e reconheça os 4 elementos que ela sempre precisa.
Confira se o SSH já está no seu Windows e entre na sua VPS pela primeira vez, com senha.
Os comandos do dia a dia pra se localizar, mexer em pastas e sair com segurança.
Por que existem duas metades de uma chave, onde elas moram e a regra de ouro que nunca se quebra.
O erro mais comum de quem copia comando de um lugar errado — e como nunca mais cair nele.
O passo a passo pra gerar uma chave nova, sua, em vez de depender só de senha.
A sequência completa — da chave no seu PC até conectar sem digitar senha nunca mais.
Pare de digitar IP e caminho de chave toda vez — conecte só com um apelido.
"Permission denied", conexão recusada, chave antiga — o diagnóstico de cada um.
Trilha · Aula 1
Ao fim desta aula você reconhece, em qualquer comando de conexão remota, os 4 elementos que ele sempre precisa ter — sem decorar nenhum código.
Hoje, quando algo trava na automação que roda na sua VPS, você depende de mandar mensagem pro suporte e esperar. As próximas aulas resolvem isso — mas antes, você precisa entender o que está de fato acontecendo quando alguém "entra" num servidor. Sem essa base, qualquer comando vira decoreba.
↓ role para estudar
Uma VPS é um computador que fica ligado 24 horas num data center, rodando a automação do seu negócio. O SSH é o corredor privado que liga o seu computador direto a esse servidor — sem precisar viajar até o data center.
Depois que Marta, dona de salão de beleza, conecta por SSH na VPS onde roda a confirmação automática de horários por WhatsApp, tudo que ela digita passa a rodar lá dentro, não mais no notebook dela.
Com SSH você entra na VPS e resolve, com as próprias mãos, o que hoje pede suporte: reiniciar um serviço travado, olhar por que uma mensagem não saiu, ajustar um arquivo, ou só confirmar que está tudo funcionando.
Ricardo, dono de loja de roupas, usa uma automação que posta as novidades de coleção sozinha. Quando ela para de postar, é o SSH que deixa ele entrar na VPS e ver o que aconteceu, no mesmo minuto — em vez de esperar alguém disponível.
Toda conexão por SSH — a de Marta, a de Ricardo, a de qualquer pessoa — depende sempre dos mesmos 4 elementos, nunca mais nem menos:
Teste-se
Se você troca de VPS (por exemplo, a Hostinger em vez da AWS), qual dos 4 elementos muda?
Um comando de conexão parece uma fileira de símbolos estranhos na primeira vez. Depois desta aula, ele vira só isto: cliente, servidor, IP e autenticação, numa ordem fixa — nada além disso.
Marta olhava para ssh root@123.123.123.123 como um enigma. Hoje ela sabe: é o cliente dela (o ssh) autenticando um usuário (root) num endereço (123.123.123.123) — os 4 elementos, na mesma ordem de sempre.
Antes
Um comando de conexão era um bloco de texto pra copiar sem entender, torcendo pra funcionar.
Depois
O mesmo comando vira 4 peças reconhecíveis — e você sabe qual delas ajustar quando algo muda.
Pratique agora 0/2 feito
Ler o mini-caso abaixo e apontar os 4 elementos — ~8 min.
Não existe nada pra quebrar aqui: é só leitura e raciocínio, sem tocar em nenhuma VPS de verdade.
Mini-caso
Marta quer entrar na VPS onde roda sua automação de WhatsApp. Ela abre o terminal do próprio notebook e digita ssh admin@45.77.12.9. Aparece um aviso pedindo a senha; ela digita e entra. Ricardo, na loja de roupas, faz o mesmo, só que na VPS dele o endereço é outro e o usuário também.
IP: 45.77.12.9 — o endereço da VPS de Marta. Usuário: admin — quem está autenticando. O cliente é o terminal do notebook dela; o servidor é o serviço SSH ligado dentro da VPS. No caso de Ricardo, IP e usuário mudam porque são de outra VPS — mas os 4 papéis (cliente, servidor, IP, autenticação) continuam os mesmos, porque é assim que o SSH funciona sempre.
Você acabou de conseguir reconhecer os 4 elementos de qualquer conexão SSH — a base que todas as próximas aulas usam.
Resumo
Trilha · Aula 2
Ao fim desta aula você confere se o SSH já está pronto no seu Windows e conecta na sua própria VPS pela primeira vez, usando senha.
Toda a teoria da aula 1 só vira útil quando você abre o corredor de verdade, uma vez. É a diferença entre saber o que é uma chave de carro e sentar no banco do motorista.
↓ role para estudar
Isto é uma receita simples: você abre o terminal (CMD ou PowerShell), digita um comando de checagem, e lê a resposta.
Marta abre o menu Iniciar, digita "cmd", abre o Prompt de Comando e digita ssh -V. Se aparecer algo como OpenSSH_for_Windows, o SSH já está instalado — ela não precisa fazer mais nada nesta etapa.
ssh -V
comando certo
$ ssh -V
OpenSSH_for_Windows_9.5, LibreSSL 3.9.2
erro comum
$ ssh -v
OpenSSH_for_Windows_9.5, LibreSSL 3.9.2 debug1: Reading configuration data ... (-v minúsculo liga o modo detalhado — não é isto que confirma a versão)
Se o comando não for reconhecido, o Windows 10/11 tem o SSH pronto pra ativar, sem baixar nada de fora: Configurações → Apps → Recursos opcionais → Adicionar recurso → OpenSSH Client.
Ricardo passou por isso na loja: o comando deu erro na primeira vez, ele ativou o recurso pelo caminho acima, reabriu o terminal, e o ssh -V funcionou.
Erro comum
Testar o comando sem fechar e reabrir o terminal depois de ativar o recurso. O Windows só reconhece o SSH numa janela nova — feche o terminal antigo e abra outro antes de testar de novo.
Com o SSH pronto, a conexão em si é uma linha: ssh usuário@IP_DA_VPS. Marta digita ssh root@123.123.123.123 (o IP é sempre o da VPS dela, não este exemplo).
Na primeira vez que qualquer pessoa conecta numa VPS nova, aparece uma pergunta: Are you sure you want to continue connecting?. É o computador confirmando que você reconhece esse servidor — digite yes e Enter.
Teste-se
Essa pergunta de confirmação aparece toda vez que você conecta, ou só na primeira vez com aquela VPS?
Depois do yes, a VPS pede a senha. Ricardo, na primeira vez, achou que o teclado tinha travado: nenhuma letra aparecia enquanto ele digitava.
É assim mesmo, de propósito: por segurança, a senha nunca aparece na tela, nem como pontinhos. Digite normalmente e aperte Enter — ela está sendo recebida, só não é mostrada.
Checklist da primeira conexão
ssh usuário@IP_DA_VPS com os dados da sua própria VPS.yes quando perguntado.Pratique agora 0/3 feito
Confirmar o SSH instalado e entrar na sua VPS com senha — ~10 min.
Conectar e olhar não muda nada na VPS. Se algo parecer errado, digite exit e você sai sem ter alterado nada.
ssh -V ssh usuario@IP_DA_VPS
Você acabou de entrar na sua própria VPS pela primeira vez — a mesma ação que Marta e Ricardo fazem sempre que precisam checar algo de perto.
Resumo
yes) — só na primeira vez.Trilha · Aula 3
Ao fim desta aula você se localiza dentro da sua VPS, anda entre pastas, confere informações básicas e sai com segurança.
Depois de entrar (aula 2), o primeiro susto de quem nunca usou terminal é não saber onde está nem o que fazer a seguir. Estes 5 comandos resolvem 90% do "estou perdido".
↓ role para estudar
Assim que entra, dá pra confirmar dois pontos: onde você está e o que existe ao redor. pwd mostra o caminho da pasta atual; ls lista os arquivos e pastas dentro dela.
Marta entra na VPS, digita pwd e vê algo como /root — a "sala" onde ela chegou. Depois digita ls e vê os arquivos da automação de WhatsApp que estão ali guardados.
pwd ls
comando
$ pwd $ ls
/root automacao_whatsapp config.json logs
Pra entrar numa pasta, use cd nome-da-pasta ("cd" de mudar de diretório). Pra voltar uma pasta, cd .. — os dois pontos significam "a pasta de cima".
Ricardo quer ver a pasta da automação de posts: digita cd automacao, confirma com pwd, e quando termina de olhar, digita cd .. pra voltar de onde veio.
Erro comum
Esquecer o espaço entre "cd" e o nome da pasta, ou errar uma letra do nome. O terminal é bem literal — cdautomacao não funciona, e um nome de pasta errado dá "não encontrado". Confira com ls o nome exato antes de entrar.
uname -a mostra informações do sistema (qual versão do Linux está rodando). Em servidores baseados em Ubuntu ou Debian — os mais comuns em VPS de automação — sudo apt update && sudo apt upgrade -y atualiza os programas instalados.
Marta roda essa atualização uma vez por mês na VPS do salão, do mesmo jeito que atualiza o celular — é manutenção preventiva, não corrige um problema específico.
uname -a sudo apt update && sudo apt upgrade -y
comando certo
$ sudo apt update && sudo apt upgrade -y
Lendo listas de pacotes... Pronto Todos os pacotes estão atualizados.
erro comum
$ apt update
Permission denied (você precisa de privilégio de administrador) E: Não é possível abrir o arquivo de trava — esqueceu o "sudo" na frente
Teste-se
O comando de atualização precisa ser rodado toda vez que você entra na VPS?
Pra sair da VPS e voltar pro seu próprio computador, digite exit e Enter. O prompt muda de volta, confirmando que você já não está mais "dentro" do servidor.
Ricardo termina de checar a automação, digita exit, e volta a ver o terminal do seu próprio notebook — sinal de que qualquer comando que ele digitar agora roda no notebook, não mais na VPS.
Checklist de navegação básica
pwd — onde estou.ls — o que tem aqui.cd nome / cd .. — entrar / voltar de pasta.exit — sair da VPS com segurança.Pratique agora 0/2 feito
Rodar os 4 comandos de localização e sair com segurança — ~10 min.
pwd, ls, uname -a e exit só leem informação — nenhum deles apaga ou altera nada. Se algo parecer estranho, exit sempre te tira de lá.
pwd ls cd nome-de-uma-pasta-que-voce-viu-no-ls cd .. exit
Você acabou de aprender a se mover dentro da sua VPS sem depender de ninguém pra "só dar uma olhada".
Resumo
pwd e ls mostram onde você está e o que tem ali — sempre o primeiro passo.cd entra numa pasta, cd .. volta — o terminal é literal com nomes e espaços.exit sai da VPS com segurança e devolve o controle ao seu computador.Trilha · Aula 4
Ao fim desta aula você reconhece, dentro da pasta de chaves do seu computador, qual arquivo é privado e qual é público — e por que ter várias chaves é normal.
A partir da aula 6 você vai criar sua própria chave. Antes disso, precisa entender o que uma chave SSH é e onde ela mora — senão, qualquer passo seguinte vira decoreba de novo.
↓ role para estudar
Uma chave SSH é uma forma de entrar sem digitar senha. E, assim como você tem chaves diferentes pra casa e pro carro, é comum ter uma chave SSH diferente pra cada serviço.
Marta tem uma chave pra VPS do salão e outra pra GitHub, onde guarda o código da automação. São chaves separadas, cada uma abrindo só a porta a que pertence.
No Windows, as chaves ficam guardadas numa pasta escondida chamada .ssh, dentro da sua pasta de usuário: C:\Users\SEU_USUARIO\.ssh\. No Linux ou Mac, o mesmo lugar se chama ~/.ssh/.
Ricardo encontrou a pasta dele em C:\Users\ricardo\.ssh\ — o mesmo padrão, só trocando o nome de usuário do Windows dele.
.ssh é uma gaveta só sua — cada chave dentro dela abre uma porta específica.Dentro de .ssh você pode encontrar nomes como id_ed25519, hostinger_vps.pub, config e known_hosts. A regra pra reconhecer é simples:
.pub no final = chave privada..pub no final = chave pública.config = atalhos de conexão (aula 8).known_hosts = lista de servidores já confirmados (a pergunta "yes" da aula 2).Teste-se
Marta vê dois arquivos: hostinger_vps e hostinger_vps.pub. Qual dos dois é a chave privada?
A chave pública (.pub) pode ser colocada em qualquer VPS, no GitHub, no GitLab — ela só serve pra "reconhecer" a chave privada correspondente, nunca pra entrar sozinha.
A chave privada nunca deve ser compartilhada, copiada pra nuvem pública ou mandada por mensagem. Ricardo mantém a dele só no próprio notebook, do mesmo jeito que guarda a chave física da loja com ele, nunca emprestando o molde pra qualquer um copiar.
Antes
Uma senha só, que qualquer um pode tentar adivinhar testando várias vezes.
Depois
Um par de chaves: a pública espalhada onde precisar, a privada guardada só com você — impossível de adivinhar por tentativa.
Pratique agora 0/2 feito
Listar sua pasta .ssh e classificar cada arquivo — ~8 min.
Listar arquivos só mostra os nomes, não abre nem altera nada dentro deles. Nenhum risco.
dir %USERPROFILE%\.ssh
Você acabou de conseguir reconhecer, na sua própria pasta, o que é privado e o que pode ser compartilhado.
Resumo
.ssh da sua conta de usuário, no Windows, Linux ou Mac..pub é privada, com .pub é pública — e a privada nunca sai do seu computador.Trilha · Aula 5
Ao fim desta aula você reconhece em qual terminal está e evita o erro de sintaxe mais comum de quem copia comando do lugar errado.
O Windows tem dois terminais diferentes, e um comando que funciona num não funciona no outro. É a causa nº 1 de "copiei certinho e não funcionou" — vamos resolver isso antes de criar sua chave, na aula 6.
↓ role para estudar
O Windows traz dois terminais diferentes: o CMD (Prompt de Comando, mais antigo) e o PowerShell (mais novo, mais recursos). Os dois abrem uma janela parecida, mas entendem sintaxes diferentes pra algumas coisas — como referenciar a pasta do seu usuário.
Marta abriu o CMD sem perceber, pois ela buscou "prompt" no menu Iniciar — o PowerShell aparece quando se busca "powershell". Nenhum dos dois é "o errado"; são só diferentes.
Ricardo estava no CMD, no caminho C:\Users\ricardo\projetos\testes>, e tentou rodar type $env:USERPROFILE\.ssh\id_ed25519.pub — um comando de PowerShell, digitado dentro do CMD.
Erro comum
Usar $env:USERPROFILE dentro do CMD (ou %USERPROFILE% dentro do PowerShell). O erro aparece como algo do tipo "a sintaxe do nome do arquivo... está incorreta" — porque $env:USERPROFILE é sintaxe do PowerShell, e o CMD não entende.
A regra é: no CMD, a pasta do seu usuário se escreve %USERPROFILE%; no PowerShell, se escreve $env:USERPROFILE. É o mesmo lugar, só com uma "palavra" diferente pra cada terminal.
Marta aprendeu a olhar o título da janela ou o próprio prompt: se aparece só um caminho simples como C:\Users\marta>, costuma ser CMD; se aparece PS C:\Users\marta> com "PS" na frente, é PowerShell.
A partir de agora, todo comando que envolve %USERPROFILE% ou $env:USERPROFILE nesta trilha indica pra qual dos dois terminais ele serve — confira antes de colar. Foi exatamente esse hábito que evitou o mesmo erro de Ricardo se repetir com Marta.
Checklist rápido
%USERPROFILE%.$env:USERPROFILE.Pratique agora 0/2 feito
Rodar o mesmo pedido nos dois terminais, cada um com sua sintaxe — ~8 min.
Só estamos listando o conteúdo de uma pasta — nenhum dos dois comandos altera nada.
REM no CMD: dir %USERPROFILE%\.ssh # no PowerShell: dir $env:USERPROFILE\.ssh
Você acabou de aprender a reconhecer, antes de digitar, qual sintaxe cada terminal espera.
Resumo
$env:USERPROFILE no CMD, ou %USERPROFILE% no PowerShell.Trilha · Aula 6
Ao fim desta aula você tem uma chave SSH própria, criada por você, pronta pra ser colocada na sua VPS na próxima aula.
Até aqui você só reconheceu chaves já existentes. Agora é a sua vez de gerar a primeira — o passo que te deixa independente de digitar senha a cada conexão.
↓ role para estudar
Antes de criar uma chave nova, vale ver como uma chave pública se parece por dentro: um texto longo, começando com ssh-ed25519. No CMD, type mostra o conteúdo de um arquivo de texto.
Marta já tem a chave id_ed25519.pub de um teste antigo; ela roda type %USERPROFILE%\.ssh\id_ed25519.pub e vê algo como ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... minha-vps.
type %USERPROFILE%\.ssh\id_ed25519.pub
comando certo
$ type %USERPROFILE%\.ssh\id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... minha-vps
erro comum
$ type %USERPROFILE%\.ssh\minha_vps.pub
O sistema não pode encontrar o arquivo especificado. (nome de arquivo errado — confira o nome exato com dir antes)
Se preferir ver os arquivos como ícones em vez de texto, o comando explorer %USERPROFILE%\.ssh abre a pasta no Explorer do Windows, a mesma janela de sempre pra ver arquivos.
Ricardo prefere esse jeito: ele digita o comando, o Explorer abre, e ele vê os arquivos hostinger_vps e hostinger_vps.pub lado a lado, do jeito que já está acostumado a olhar pastas.
Erro comum
Arrastar ou copiar a chave privada pra fora dessa pasta "só pra guardar num lugar mais fácil". Qualquer cópia da chave privada em outro lugar (área de trabalho, nuvem pessoal) é uma cópia a mais que pode vazar — deixe-a só ali dentro.
O tipo de chave recomendado hoje é o ed25519 — mais moderno e mais seguro. O comando de criação pede um caminho e um nome pra sua chave nova.
Marta escolhe chamar a dela de minha_vps, no CMD:
ssh-keygen -t ed25519 -C "minha-vps" -f %USERPROFILE%\.ssh\minha_vps
comando certo
$ ssh-keygen -t ed25519 -C "minha-vps" -f %USERPROFILE%\.ssh\minha_vps
Generating public/private ed25519 key pair. Your identification has been saved in minha_vps Your public key has been saved in minha_vps.pub
erro comum
$ ssh-keygen -t ed25519 -C "minha-vps" -f %USERPROFILE%\.ssh\minha_vps
minha_vps already exists. Overwrite (y/n)? (já existe uma chave com esse nome — escolha outro nome em vez de sobrescrever sem querer)
Depois disso, é só apertar Enter nas perguntas seguintes (elas pedem uma senha extra opcional pra chave — pode deixar em branco e confirmar).
Teste-se
Depois de rodar o comando acima, quantos arquivos novos aparecem na pasta .ssh?
O comando da etapa anterior cria dois arquivos: minha_vps (chave privada — nunca compartilhe) e minha_vps.pub (chave pública — pode ir pra VPS).
Ricardo confere os dois arquivos na sua pasta e já reconhece qual é qual, aplicando a regra da aula 4: sem .pub é privada, com .pub é pública.
Conferindo sua chave nova
ssh-keygen com -f apontando pro nome escolhido..pub.Pratique agora 0/2 feito
Criar um par de chaves novo, escolhendo seu próprio nome — ~10 min.
Criar uma chave nova não apaga nenhuma chave existente nem mexe na sua VPS — é só um par de arquivos novo dentro da pasta .ssh. Se não gostar do nome escolhido, pode apagar os 2 arquivos e criar de novo.
ssh-keygen -t ed25519 -C "minha-vps" -f %USERPROFILE%\.ssh\<escolha um nome>
Você acabou de criar sua própria chave SSH — pronta pra entrar na VPS na próxima aula.
Resumo
ssh-keygen -t ed25519 cria um par de chaves novo, com o nome que você escolher..pub, correspondente a ela.Trilha · Aula 7
Ao fim desta aula você conecta na sua VPS usando a chave que criou, sem digitar senha nenhuma.
Você já tem a chave (aula 6). Falta um passo: entregar a metade pública dela pra VPS reconhecer, e testar. É a aula mais longa da trilha porque reúne tudo que veio antes — vale a pena ir com calma.
↓ role para estudar
A regra é sempre a mesma: só a chave pública (o arquivo .pub) viaja até a VPS. A privada nunca sai do seu computador — nem nesta aula.
Marta já rodou ssh-keygen e tem minha_vps e minha_vps.pub. Ela segue os passos abaixo uma vez, e da próxima vez que precisa checar a automação de WhatsApp, entra sem digitar nada além do comando. Ricardo faz exatamente a mesma sequência, na VPS da loja dele, trocando só o IP e o nome da chave.
Primeiro, veja sua chave pública no seu computador (type %USERPROFILE%\.ssh\minha_vps.pub) e copie o texto inteiro. Depois, entre na VPS com senha (aula 2) e crie, dentro dela, a pasta e o arquivo que guardam as chaves autorizadas:
mkdir -p ~/.ssh nano ~/.ssh/authorized_keys
O nano é um editor de texto simples que abre dentro do próprio terminal. Cole ali a chave pública copiada, e salve com CTRL+O, Enter, depois CTRL+X pra sair. Foi assim que Ricardo colou a chave pública da loja dentro da VPS, na primeira vez que fez esse passo.
Checklist completo: chave no seu PC até dentro da VPS
mkdir -p ~/.ssh — criar a pasta, se ainda não existir.nano ~/.ssh/authorized_keys — colar a chave e salvar (CTRL+O, Enter, CTRL+X).comando
$ mkdir -p ~/.ssh $ nano ~/.ssh/authorized_keys
(o nano abre uma tela de edição — cole a chave, CTRL+O, Enter, CTRL+X)
O permissões da pasta e do arquivo precisam estar corretas, ou a VPS ignora a chave por segurança. Ainda dentro da VPS, rode:
chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys
Ricardo esqueceu esse passo na primeira tentativa e sua chave simplesmente não funcionou — sem nenhuma mensagem de erro clara. Depois de ajustar as permissões, funcionou de primeira.
comando certo
$ chmod 700 ~/.ssh $ chmod 600 ~/.ssh/authorized_keys
(nada aparece — no Linux, silêncio depois de um comando quase sempre significa sucesso)
erro comum
$ ssh -i minha_vps root@IP_DA_VPS (pulando o chmod)
root@IP: Permission denied (publickey,password). (a VPS recusa a chave porque as permissões da pasta .ssh estão abertas demais)
Teste-se
Se você pular a etapa do chmod, o que tende a acontecer ao tentar conectar com a chave?
Digite exit pra sair da VPS, volte pro seu computador, e conecte de novo — agora indicando qual chave usar, com -i:
ssh -i %USERPROFILE%\.ssh\minha_vps usuario@IP_DA_VPS
Se tudo estiver certo, Marta entra direto, sem nenhuma tela pedindo senha — só a chave já basta.
Antes
Toda conexão pedia a senha, e ela precisava lembrar ou copiar de algum lugar.
Depois
A chave prova quem ela é sozinha — conexão mais rápida e mais segura, sem senha nenhuma.
comando certo
$ ssh -i %USERPROFILE%\.ssh\minha_vps root@123.123.123.123
Welcome to Ubuntu 22.04 LTS root@vps:~#
erro comum
$ ssh -i %USERPROFILE%\.ssh\minha_vps root@123.123.123.123
root@123.123.123.123's password: (ainda pediu senha — a chave não foi aceita: revise o authorized_keys e o chmod)
Pratique agora 0/4 feito
Seguir a sequência completa, do seu computador até a VPS reconhecer sua chave — ~15 min.
Você sempre pode entrar de novo com senha (aula 2) se algo travar aqui — nenhum passo desta prática apaga o acesso por senha que já existe.
type %USERPROFILE%\.ssh\minha_vps.pub ssh usuario@IP_DA_VPS mkdir -p ~/.ssh nano ~/.ssh/authorized_keys chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys exit ssh -i %USERPROFILE%\.ssh\minha_vps usuario@IP_DA_VPS
Você acabou de conseguir entrar na sua VPS só com a chave — o mesmo fluxo que Marta e Ricardo usam todo dia, sem depender de suporte técnico.
Resumo
~/.ssh/authorized_keys, na própria VPS.chmod 700 na pasta, chmod 600 no arquivo) são obrigatórias — sem elas, a VPS ignora a chave.-i apontando pra chave elimina a necessidade de digitar senha.Trilha · Aula 8
Ao fim desta aula você conecta na sua VPS digitando só um apelido, sem repetir IP, usuário e caminho da chave toda vez.
O comando da aula 7 funciona, mas é longo de repetir todo dia. Um arquivo de 4 linhas resolve isso de vez.
↓ role para estudar
Todo dia, pra entrar na VPS com a chave, é preciso lembrar (ou copiar de algum lugar) um comando inteiro: usuário, IP e caminho da chave. É fácil errar um caractere no meio disso.
Ricardo mantinha o comando completo anotado num bloco de notas, só pra colar toda vez que precisava — funcionava, mas era um passo extra desnecessário.
No seu computador, dentro da pasta .ssh, você pode criar um arquivo chamado exatamente config (sem nenhuma extensão), com um bloco parecido com este:
Host hostinger
HostName 123.123.123.123
User root
IdentityFile ~/.ssh/minha_vpsMarta cria o dela com o apelido salao, trocando o IP e o usuário pelos da VPS dela mesma.
Erro comum
Esquecer o recuo (espaços) antes de cada linha depois de "Host". O arquivo config segue um formato onde as linhas de baixo do "Host" precisam estar recuadas — sem isso, a conexão pelo apelido não funciona.
comando certo
$ ssh hostinger
Welcome to Ubuntu 22.04 LTS root@vps:~#
erro comum
$ ssh hostinger
ssh: Could not resolve hostname hostinger: Name or service not known (o arquivo config existe, mas as linhas abaixo de "Host" não estavam recuadas)
Host é o apelido que você escolhe (o nome que vai digitar). HostName é o IP de verdade da VPS. User é o usuário. IdentityFile aponta pra chave privada que deve ser usada.
Teste-se
No exemplo do Ricardo, qual linha ele precisa trocar pra apontar pra chave que criou na aula 6?
Depois de salvo o arquivo, o comando de conexão vira só: ssh hostinger — em vez de digitar usuário, IP e caminho da chave toda vez. Marta faz isso hoje em segundos, no meio de um dia cheio de clientes no salão.
Checklist do atalho
config dentro da pasta .ssh.Host / HostName / User / IdentityFile, recuado.ssh <apelido escolhido>.Pratique agora 0/2 feito
Escrever o arquivo config e conectar só com o apelido — ~8 min.
O arquivo config só afeta o seu computador, não a VPS — se errar algo, é só reabrir e corrigir, sem risco de travar o servidor.
Host <escolha um apelido>
HostName IP_DA_SUA_VPS
User <seu usuario>
IdentityFile ~/.ssh/minha_vpsVocê acabou de reduzir todo o processo de conexão a uma única palavra — o seu apelido.
Resumo
config, dentro da pasta .ssh, guarda apelidos de conexão.Host (apelido), HostName (IP), User e IdentityFile (chave).ssh <apelido>.Trilha · Aula 9
Ao fim desta aula você diagnostica sozinho os 4 erros de conexão mais frequentes e sabe qual ação tomar em cada um.
Em algum momento, uma conexão vai falhar — é normal, não é sinal de que você fez algo fundamentalmente errado. O que muda tudo é reconhecer a mensagem e já saber por onde começar a investigar.
↓ role para estudar
O SSH sempre devolve uma mensagem quando algo falha — e essa mensagem já indica a direção certa da investigação. As 4 mais comuns são: Permission denied, Connection timed out, Connection refused, e um erro de "assinatura" mudada.
Marta, na primeira vez que viu Permission denied, achou que tinha quebrado alguma coisa. Não tinha: era só um usuário digitado errado.
Essa mensagem quer dizer que a conexão chegou até a VPS, mas a autenticação falhou. As causas mais comuns: senha errada, usuário errado, chave errada, a chave pública não foi colocada no authorized_keys, ou as permissões da pasta .ssh estão erradas (aula 7). Foi exatamente essa mensagem que Marta viu na primeira tentativa, por um usuário digitado errado.
Erro comum
"Permission denied" ao tentar conectar com -i pela chave. Antes de suspeitar da chave em si, confira: o arquivo authorized_keys tem exatamente a chave certa colada, e as permissões estão em 700/600.
Connection timed out significa que o pedido nem chegou a uma resposta — geralmente IP errado, VPS desligada, ou uma porta bloqueada por firewall. Connection refused significa que a VPS respondeu dizendo "não" — o serviço SSH pode estar desligado nela, ou a porta usada está errada.
Ricardo recriou a VPS da loja uma vez, e ao tentar conectar de novo recebeu um aviso de que a "assinatura" do servidor tinha mudado — o comando ssh-keygen -R IP_DA_VPS limpa a assinatura antiga guardada e permite conectar de novo, aceitando a nova.
Se você já está dentro da VPS (por exemplo, entrando com senha depois de uma falha com chave), systemctl status ssh (ou sshd, dependendo do sistema) mostra se o serviço está ativo. Ricardo usou esse comando quando a automação de posts da loja parou de responder, e confirmou que o serviço estava de pé — o problema era outro.
systemctl status ssh sudo systemctl enable ssh sudo systemctl start ssh
Checklist final: do zero até conectar com chave
comando certo
$ systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
Active: active (running)
erro comum
$ systemctl status sshd
Unit sshd.service could not be found. (neste sistema o serviço se chama "ssh", não "sshd" — tente o outro nome)
Pratique agora 0/2 feito
Ler os 2 mini-casos e apontar a causa mais provável de cada um — ~8 min.
É só leitura e raciocínio — nenhuma VPS de verdade é tocada nesta prática.
Caso 1. Marta tenta conectar com ssh -i ~/.ssh/minha_vps admin@45.77.12.9 e recebe Permission denied. Ela confirma que o IP e o usuário estão certos.
Caso 2. Ricardo tenta conectar na VPS da loja e o terminal fica parado por um minuto, até aparecer Connection timed out. Ele confirma no navegador de outro serviço que a VPS está ligada.
Caso 1: como IP e usuário já foram confirmados, a causa mais provável é a chave pública não estar corretamente colada em authorized_keys, ou as permissões da pasta .ssh/arquivo estarem erradas — o mesmo diagnóstico do step 2 desta aula. Caso 2: "timed out" (sem resposta nenhuma) aponta pra um problema de rede antes mesmo de chegar no SSH — porta bloqueada por firewall é a causa mais comum quando a VPS está confirmadamente ligada.
Você acabou de conseguir diagnosticar problemas de conexão pela mensagem de erro, sem depender de mais ninguém pra entender o que está acontecendo.
Resumo
systemctl status ssh, direto na VPS, confirma se o serviço está ativo.