Linux / Comando ssh: acesso remoto e verificação da chave do servidor

O comando ssh do OpenSSH permite entrar em uma máquina remota e executar comandos por uma conexão criptografada. Para usar SSH, de Secure Shell, informe o servidor e a conta remota e confirme a identidade do servidor pela chave de host antes de aceitar uma conexão desconhecida.

A chave de host identifica o servidor; a senha ou a chave do usuário participa da autenticação da conta. São verificações diferentes. A criptografia protege o transporte, mas não torna confiável um servidor cuja identidade você não confirmou.

Sintaxe e preparação

ssh [opções] [usuário@]host [comando remoto]

Em usuário@host, o usuário pertence à máquina remota. Se você o omitir, a configuração do cliente e seu nome de usuário local podem influenciar a conta escolhida. Confirme endereço, conta, porta e método de autenticação com o responsável pelo servidor. É necessário que o serviço SSH remoto esteja disponível e que você tenha autorização para acessá-lo.

Consulte ssh -V para identificar o cliente e man ssh para suas opções. Um arquivo de configuração pode definir aliases, portas, identidades e outros parâmetros por host. O manual de configuração do OpenSSH descreve essas regras; não presuma que duas máquinas com o mesmo comando tenham a mesma configuração efetiva.

Os nomes server.example.com e server.example.test e as contas alice e user são exemplos. Substitua-os pelos dados autorizados; eles não anunciam um serviço SSH público para esta prática. Os domínios de exemplo e de teste são reservados conforme a RFC 2606.

Login, porta alternativa e comando remoto

Abrir uma sessão remota

ssh alice@server.example.com

O cliente tenta acessar a conta alice. Conforme a configuração e o histórico, pode solicitar a confirmação da chave do servidor e depois a autenticação do usuário. Confirme a impressão digital por um canal independente antes de aceitar uma chave desconhecida, como explicado na próxima seção. Não envie senha ou chave privada para resolver uma dúvida sobre a identidade do servidor.

Após uma autenticação bem-sucedida, normalmente aparece o shell remoto. Os comandos digitados nessa sessão atuam na máquina remota e usam as permissões daquela conta. Ao terminar, use exit para sair do shell; confira o prompt local antes de executar tarefas no seu computador.

Usar a porta informada pelo administrador

ssh -p 2222 alice@server.example.com

A opção é -p minúscula. Ela seleciona a porta TCP do servidor, aqui 2222, em vez do padrão 22 quando nenhuma configuração o altera. TCP é o Protocolo de Controle de Transmissão. Essa opção não muda a porta de escuta do serviço remoto nem abre o firewall; o servidor já precisa estar acessível na porta escolhida.

Executar uma consulta no servidor

ssh alice@server.example.com hostname

Depois da verificação do servidor e da autenticação, o SSH solicita a execução de hostname no destino, sem abrir um shell de login interativo. A saída esperada é o nome configurado naquela máquina, que pode ser curto ou completo; não precisa coincidir com o endereço usado na conexão.

O comando remoto também pode falhar por ausência do programa ou por restrições da conta. O cliente normalmente devolve seu código de saída; erros do SSH podem produzir 255. Para comandos mais complexos, planeje as aspas e a expansão pelo shell local e pelo remoto antes de executar: transportar argumentos não equivale a executar uma sequência arbitrária com segurança.

Confirmar a chave na primeira conexão

Este segundo nome também é apenas ilustrativo:

ssh user@server.example.test

Uma mensagem de confirmação pode ter o formato abaixo. Os três pontos substituem a impressão digital real; não são um valor para comparar nem uma saída obtida no teste deste artigo.

The authenticity of host 'server.example.test' can't be established.
ED25519 key fingerprint is SHA256:...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

1. Confirme o endereço e a porta pretendidos e obtenha a impressão digital do servidor por uma fonte independente e confiável, como o administrador por um canal já conhecido.
2. Compare o tipo de chave e a impressão digital completa. A mensagem recebida da própria conexão não é uma confirmação independente de identidade.
3. Somente depois da correspondência aceite a chave. Na política interativa usual, essa aceitação registra a chave no arquivo local known_hosts; configurações gerenciadas podem adotar outro fluxo.
4. Se os valores não corresponderem ou a origem da chave não estiver confirmada, interrompa a conexão e esclareça a diferença antes de autenticar a conta.

A mensagem permanece em inglês para corresponder ao exemplo do programa. Ela pergunta se você quer continuar apesar de a chave ainda não ser conhecida. Não automatize a resposta yes. Um registro já confiável ou uma política gerenciada pode evitar esse prompt, portanto sua ausência não deve ser interpretada sem conhecer a configuração.

Se surgir depois um aviso de chave alterada, pode ter ocorrido reinstalação ou rotação de chaves, mas também pode haver um servidor indevido no caminho. Não apague indiscriminadamente known_hosts nem desative a verificação para silenciar o alerta. Confirme a nova impressão digital de forma independente antes de atualizar o registro correto.

Opções principais e alcance

A opção -i não deve ser entendida como garantia de que apenas uma identidade será oferecida: o agente e a configuração também contam. A política IdentitiesOnly controla o uso das identidades configuradas. Proteja a chave privada e seu backup e limite o acesso ao arquivo; a chave pública é a parte destinada a ser instalada ou compartilhada conforme a política de acesso.

O encaminhamento com -L pode expor um serviço a outros clientes se o endereço de escuta permitir. Confirme a interface de escuta e o destino autorizado; localhost usado como destino no lado remoto se refere à perspectiva daquela máquina. Um túnel SSH não torna automaticamente criptografado o trecho entre o servidor SSH e um terceiro serviço de destino.

Separar falhas de conexão e autenticação

Investigue em ordem: resolução do nome, alcance TCP na porta correta, negociação SSH, verificação da chave de host e autenticação da conta. Uma recusa de conexão é diferente de uma senha rejeitada; um tempo esgotado não identifica sozinho qual equipamento ou regra interrompeu o caminho.

O -v ajuda a localizar a etapa em que o cliente parou. Revise os detalhes antes de compartilhar logs, pois podem conter nomes de máquinas, contas, caminhos e informações de configuração. Em falhas de chave, confira a conta remota, a identidade selecionada, as permissões locais e a autorização da chave pública no servidor, sem publicar a chave privada.

Na verificação deste artigo, o OpenSSH 10.3p1 do Git para Windows foi executado com -G -F none apenas para imprimir configurações e sair. Foram confirmados a conta alice, as portas 22 e 2222 e o reconhecimento das opções de salto, encaminhamento e ausência de comando remoto. Os quatro comandos de conexão passaram também pela análise de sintaxe do Bash. Não houve conexão SSH, autenticação, comando remoto, túnel aberto ou aceitação de chave; isso não é um teste de execução nativa no Linux.

Pergunta frequente

O que fazer quando o SSH avisa que a chave do servidor mudou?

Interrompa a tentativa e confirme com o administrador, por um canal independente, se houve uma mudança legítima e qual é a nova impressão digital. Preserve a verificação de identidade enquanto investiga; apagar registros ou desativá-la sem essa confirmação elimina uma proteção importante.

Documentação oficial

O manual oficial do cliente ssh descreve as opções e a verificação de chaves. Compare as instruções com o manual da versão instalada antes de aplicar configurações.