PuTTY exibe Conexão recusada: corrigir a falha

No PuTTY, a mensagem “Erro de rede: Conexão recusada” indica que a abertura da conexão TCP foi rejeitada. O cliente ainda não chegou à etapa de senha ou chave SSH. A recusa pode vir da máquina destinatária, mas também de um firewall, gateway ou redirecionamento mal configurado: essa mensagem não prova, por si só, que o servidor correto respondeu.

Proceda do cliente para o servidor: verifique o destino, verifique a porta e, em seguida, controle a escuta e o filtro a partir de um console independente. Não reinicie o servidor e não altere o firewall “para tentar”. Se você não tiver um console de recuperação ou um acesso já aberto, pare-se antes de qualquer modificação no lado do servidor e peça ajuda ao administrador.

Confirme que se trata realmente de uma recusa TCP

Anote o texto exato exibido pelo PuTTY, a hora da tentativa e a sessão utilizada. No menu da janela do PuTTY, abra o Log de Eventos e anote o host, a porta e a presença de um proxy, se houver. O manual do PuTTY distingue explicitamente Connection refused de Connection timed out.

• Connection refused: a tentativa TCP recebe uma rejeição, geralmente um pacote RST. A recusa pode ser emitida pelo host ou por um equipamento intermediário configurado para recusar.
• Connection timed out: nenhuma resposta útil chega no prazo. Um filtragem silenciosa do tipo DROP, uma rota, um endereço errado ou um equipamento indisponível podem levar a esse resultado. Este não é o mesmo diagnóstico; o detalhe do timeout é reservado para um guia separado.
• Server refused our key: a conexão SSH chegou à fase de autenticação por chave, mas o servidor não aceita essa chave para essa conta. Verifique então as configurações da chave e a conta; consulte o guia para usar uma chave SSH com PuTTY. Trocar de chave não corrigirá uma recusa TCP inicial.

Um ping não permite decidir: ICMP e a porta TCP de SSH podem ser filtrados de maneira diferente. Um ping sem resposta não demonstra, portanto, que o SSH está fora do ar, e um ping bem-sucedido não valida a porta SSH.

Verifique o host e a porta no PuTTY

No PuTTY, carregue a sessão em questão e compare seus campos com as informações fornecidas pelo anfitrião ou administrador: Host Name deve conter o nome ou endereço, sem o prefixo https://; o tipo de conexão deve ser SSH; a porta deve ser a porta SSH realmente publicada. Não suponha que seja sempre a porta 22. Se você corrigir um valor, salve a sessão apenas após a confirmação do destino correto. Para os parâmetros básicos de uma sessão, consulte o guia verifique os parâmetros da sua sessão PuTTY.

A partir do PowerShell do Windows, substitua o nome e a porta de exemplo pelos da sua sessão:

Resolve-DnsName servidor.exemplo.net
Test-NetConnection -ComputerName servidor.exemplo.net -Port 22 -InformationLevel Detailed

Resolve-DnsName exibe os endereços associados ao nome; compare-os com o destino esperado. Test-NetConnection testa a porta TCP indicada: TcpTestSucceeded : True significa que esse teste estabeleceu a conexão TCP, não que a identidade do servidor ou a autenticação SSH estão validadas. Um valor False não é suficiente para distinguir entre rejeição e timeout: mantenha a mensagem exata do PuTTY. Se o PuTTY passar por um proxy ou uma VPN, esse teste direto pode seguir outro caminho; os dois resultados não são diretamente comparáveis.

A partir de um cliente Linux que você está autorizado a usar, você também pode testar apenas a porta alvo, se o netcat estiver instalado:

nc -vz -w 3 servidor.exemplo.net 22

Substitua os dois valores. As opções -z e -v solicitam um teste de conexão sem troca de aplicativo e um resultado legível; -w 3 limita a espera a três segundos. As variantes do netcat diferem: se a opção não for reconhecida, consulte nc -h e adapte-se à versão instalada, sem testar uma faixa de portas. Uma conexão estabelecida confirma o acesso TCP a partir deste cliente; uma recusa reforça a pista da rejeição; uma espera expirada abre outra ramificação de diagnóstico. Veja também o guia para testar uma porta TCP com netcat.

Controle o serviço a partir de um console Linux

Esta etapa é feita no console do anfitrião, da máquina virtual ou na frente do servidor, não na sessão PuTTY que falha. Mantenha este console e qualquer sessão de administração já aberta: elas são seu meio de retorno se uma modificação cortar o acesso. O nome da unidade depende da distribuição e do modo de inicialização.

systemctl list-unit-files 'ssh*' --no-pager
sudo systemctl status ssh.service --no-pager
sudo systemctl status sshd.service --no-pager
sudo systemctl status ssh.socket --no-pager

A primeira comando inventaria as unidades cujo nome começa com ssh. Em seguida, controle a unidade realmente presente: ssh.service é comum no Debian e Ubuntu; sshd.service é frequentemente encontrado no Fedora e RHEL; alguns sistemas usam uma ativação por ssh.socket. “Unidade não encontrada” indica apenas que esse nome de unidade não existe nesta máquina. Uma unidade ativa não prova que a porta solicitada está ouvindo na interface correta. Com uma ativação por socket, o systemd pode aceitar a conexão e iniciar o serviço sob demanda. Em um sistema sem systemd, use as ferramentas da sua distribuição em vez de transpor esses comandos.

Se nenhum servidor SSH estiver instalado, confirme primeiro com o administrador que esta máquina deve realmente fornecer SSH. Instalar um pacote de servidor só é justificado neste caso e de acordo com o procedimento da distribuição; não é um remédio universal para uma porta ruim ou uma rejeição de rede.

Verifique a porta e o endereço de escuta efetivos

Sempre a partir do console Linux, observe as interfaces, os sockets TCP em escuta e a configuração SSH:

ip -br address
sudo ss -ltnp
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T

ip -br address mostra os endereços locais; um servidor atrás de um NAT geralmente não exibe seu endereço público ali. Em ss -ltnp, -l limita a exibição a sockets em escuta, -t a TCP, -n mantém as portas como números e -p indica o processo quando disponível. Identifique a porta esperada e o processo proprietário, que pode ser o systemd se o socket estiver ativado.

Interprete o endereço tanto quanto a porta. Uma escuta em 127.0.0.1:22 está limitada ao loopback local; um endereço LAN específico não cobre outras interfaces. 0.0.0.0 designa todas as interfaces IPv4; uma escuta em [::] diz respeito ao IPv6 e não garante por si só o acesso IPv4. Se nada estiver ouvindo na porta à qual o tráfego chega, não comece abrindo o firewall: então não há serviço nessa destino.

sshd -t verifica a sintaxe e as chaves do host sem iniciar ou reiniciar o serviço. Uma execução válida não produz normalmente uma mensagem e retorna um código de sucesso; uma mensagem de erro deve ser corrigida antes de qualquer ação sobre o serviço. sshd -T exibe a configuração efetiva após a leitura e validação, incluindo os valores de porta e endereço de escuta. Não divulgue sua saída completa sem revisá-la e ocultar detalhes sensíveis. O manual oficial descreve as opções sshd(8) e as diretivas Port e ListenAddress. Essas páginas documentam OpenSSH; os caminhos e unidades variam segundo o Linux. Em uma configuração utilizando ssh.socket, confronte também os resultados de ss com a unidade ativa: a saída de sshd -T sozinha não prova o que o socket do systemd realmente expõe.

Não modifique Port ou ListenAddress sem antes identificar uma configuração errada e salvar a configuração afetada. Confirme qual interface deve ser acessível; não amplie a escuta para todas as interfaces por padrão. Antes de qualquer modificação ou recarga, mantenha o console de recuperação e o acesso existente abertos. O Ubuntu alerta para as precauções relacionadas à configuração do servidor em sua documentação OpenSSH Server.

Compare o filtragem local, a rede e o NAT

Se a porta estiver ouvindo na interface correta, mas o teste externo for recusado, identifique primeiro o gerenciador de firewall realmente utilizado e o caminho do tráfego. Os comandos abaixo são somente para leitura: execute apenas aquele que corresponde ao seu sistema.

sudo ufw status verbose
sudo nft list ruleset
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --list-all

UFW, nftables e firewalld não são intercambiáveis. Um comando ausente não prova que não há filtragem. Com firewalld, public é apenas um exemplo de zona: identifique a zona associada à interface e, em seguida, examine as regras, sua ordem, o protocolo TCP, a porta, as fontes autorizadas e as ações de rejeição. Não combine vários gerenciadores para aplicar alterações e não desative o firewall para testar.

Em seguida, verifique, em modo somente leitura, as regras do firewall cloud ou do provedor: porta publicada, protocolo e endereços de origem autorizados. Se o servidor estiver atrás de um roteador, controle o redirecionamento da porta externa para o endereço privado correto e a porta realmente em escuta. Por exemplo, um redirecionamento conceitual da porta externa 2222 para a porta interna 22 implica que o PuTTY se conecte à porta 2222 a partir da Internet, enquanto ss exibe a porta 22 no servidor. Verifique também se o endereço privado da máquina não mudou. Se um VPN ou um bastião for previsto, prefira esse caminho em vez de expor o SSH a toda a Internet.

Um teste a partir da mesma rede local para o endereço público depende do suporte do NAT loopback pelo roteador; ele não substitui um teste externo autorizado. A ausência de resposta relacionada à roteamento, a um endereço público ou a CGNAT frequentemente leva à ramificação do timeout: não tente contorná-la abrindo portas sem validação.

APlique uma única correção comprovada, e depois reteste

• Host ou porta errados na sessão: corrija apenas o destino do cliente confirmado pelo administrador.
• Serviço ausente quando o SSH deve ser fornecido: faça validar a instalação e a ativação conforme a distribuição.
• Serviço parado, configuração válida, unidade correta e acesso ao console garantido: um início controlado pode ser apropriado.
• Endereço de escuta incorreto: corrija apenas o bind confirmado e verifique primeiro a configuração.
• Regra de rejeição demonstrada: solicite ou aplique uma regra limitada à porta SSH, ao protocolo e às fontes necessárias.
• Redirecionamento incorreto: corrija o destino privado ou a porta externa após confirmação do caminho esperado.

Para um serviço systemd realmente parado, somente se o servidor deve fornecer SSH, se sshd -t foi bem-sucedido, se a unidade é a realmente utilizada e se o console de recuperação é acessível, o início controlado pode ser:

sudo systemctl start ssh.service

Substitua ssh.service por sshd.service se esta for a unidade presente; não inicie os dois e não inicie um serviço em concorrência com um socket de ativação. Este comando muda o estado da máquina: não deve ser usado como o primeiro teste. Após uma modificação de configuração, verifique primeiro o mecanismo de recarga suportado pela sua distribuição e sua unidade; nenhum reinício automático é recomendado aqui. A documentação oficial do Ubuntu lembra que uma modificação no SSH pode bloquear o acesso: mantenha a sessão aberta e o console de recuperação durante o controle.

Após cada correção, prossiga separadamente: reveja ss -ltnp no lado do servidor, e depois abra uma nova janela PuTTY para o host e a porta corrigidos. Se o PuTTY apresentar uma nova impressão de host, verifique-a por um canal confiável antes de aceitá-la. Atingir a banner SSH ou a tela de autenticação significa que a recusa TCP foi levantada; isso não significa que a conta já foi autenticada. Mantenha o acesso de recuperação enquanto essa nova conexão não tiver sido feita com sucesso.

Não use ufw disable, nft flush ruleset ou iptables -F. Não abra o SSH globalmente sem restrição de fonte, não contorne o problema ativando a conexão root e não enfraqueça nem as permissões SSH nem a autenticação multifatorial.

Consulte os logs se a recusa persistir

A partir do console Linux, escolha a unidade realmente presente e examine uma janela recente em torno da hora anotada no PuTTY:

sudo journalctl -u ssh.service -n 50 --no-pager
sudo journalctl -u sshd.service -n 50 --no-pager
sudo journalctl -u ssh.socket -n 50 --no-pager

Execute apenas o comando correspondente à unidade existente. Procure por um erro de configuração, um endereço indisponível ou uma porta já ocupada. Dependendo da distribuição e de sua configuração de logs, arquivos como /var/log/auth.log ou /var/log/secure podem complementar o log; eles não estão presentes em todos os lugares. Uma recusa antes do estabelecimento do SSH pode não deixar nenhuma entrada de autenticação. Da mesma forma, um rejeição por um roteador ou firewall na nuvem pode não aparecer no journalctl: a ausência de linha não prova a ausência de tentativa.

Se você administra o servidor e tem acesso ao tcpdump, uma captura muito curta pode ajudar a localizar a rejeição. Substitua o endereço de documentação pelo endereço de origem realmente visto pelo servidor, que pode diferir após o NAT; não capture apenas em uma máquina e rede que você está autorizado a diagnosticar.

sudo timeout 10 tcpdump -ni any -c 20 'tcp port 22 and host 192.0.2.10'

timeout 10 limita a captura a dez segundos; -c 20 a para após vinte pacotes no máximo; -n evita a resolução de nomes e -i any escuta as interfaces disponíveis. O exemplo visa a porta interna 22: adapte o filtro à porta observada. Um SYN de entrada seguido de um RST nesse ponto de captura suporta uma rejeição nesse ponto, sem identificar automaticamente o equipamento responsável. Nenhum pacote capturado também pode resultar de uma interface errada, de um filtro incorreto ou de outro caminho de rede. Não capture o conteúdo com opções de decodificação de carga útil, não mantenha um arquivo de captura permanente e oculte endereços e horários antes de compartilhar os resultados.

Se você não tiver console independente ou permissão para inspecionar o firewall, não prossiga com as alterações remotamente. Transmita ao administrador o host e a porta visados, a hora, a mensagem exata do PuTTY e os testes realizados, após ter expurgado as informações internas.