Conexão SSH recusada

2

Eu estava logado no meu servidor hoje cedo, e agora quando eu vou para o SSH eu recebo o erro "SSH Connection Refused" eu estou executando o Ubuntu Hardy. O servidor ainda está funcionando e servindo páginas da web que eu simplesmente não consigo acessar. Da última vez que estive no servidor, não mudei nenhum dos iptables. Existe alguma maneira de solucionar esse problema? Atualização: Eu tenho acesso a um console baseado em navegador para o servidor. Embora seja dolorosamente lento, eu posso investigar mais.

Atualização: Parece que o ssh não está sendo executado na minha porta quando eu uso o lsof. Eu corri sudo /etc/init.d/ssh restart e nada acontece, e ainda nada está sendo executado na minha porta ssh. Quando eu verificar /var/log/auth.log eu recebo:

sudo: pam_unix(sudo:session): session opened for xxxx root by yyyy(uid=0)
sudo: pam_unix(sudo:session): session closed for user xxxx by yyyy(uid=0)

que parece estar abrindo e fechando imediatamente a sessão.

    
por Schneems 22.03.2010 / 05:50

5 respostas

4

Eu sugeriria o seguinte além das respostas já presentes. Certifique-se de que você tenha alguma maneira de restaurar seu firewall após verificar cuidadosamente o conjunto de regras.

Disclaimer : se este dispositivo for uma máquina voltada para a Internet, isso eliminará toda a proteção do firewall de todas as interfaces e poderá fazer com que sua caixa seja adquirida.

# iptables --flush
# iptables -P INPUT ACCEPT
# iptables -P FORWARD ACCEPT
# iptables -P OUTPUT ACCEPT
# /etc/init.d/openssh-server restart

Em seguida, tente novamente a conexão via ssh, se isso falhar, verifique /var/log/auth.log.

Você também pode usar

# lsof -i TCP:22 

para ver se a porta ssh está aberta e qual endereço IP está escutando.

edite: re: update, que parece não estar relacionado com o ssh (parece estar relacionado com a elevação do privilégio do sudo.

tente tail -f /var/log/auth.log ao tentar se conectar via ssh.

A conexão recusada significa que a conexão foi explicitamente rejeitada por um firewall ou pelo daemon que é seu.

Uma conexão normal seria algo como isto:

Mar 23 13:32:32 <hostname> sshd[20100]: Accepted password for <user> from xxx.xxx.xxx.xxx port xxxxx ssh2
Mar 23 13:32:32 <hostname> sshd[20102]: (pam_unix) session opened for user <user> by (uid=0)

Enquanto uma falha de autenticação ficará assim:

Mar 23 13:35:54 <hostname> sshd[20177]: Failed password for <user> from xxx.xxx.xxx.xxx port xxxxx ssh2

Se ele foi bloqueado pelo sshd por algum motivo, será excluído no log de autenticação, se ele foi bloqueado pelo firewall (note que o firewall pode estar no host, no cliente ou em algum lugar no meio). nada.

Volte para nós se for esse o caso, a partir daí será o tcp dump no cliente, servidor e quaisquer roteadores intermediários.

    
por 22.03.2010 / 09:36
1

Bem, pode ser que o servidor ssh esteja desativado por qualquer motivo - uma forma de verificar se está usando o netcat - o netcat deve gerar algum tipo de resposta. Eu também daria um tiro de outro endereço IP para ser seguro.

    
por 22.03.2010 / 06:04
0

Dê uma olhada no seu arquivo hosts.deny! Talvez de alguma forma seu IP tenha entrado lá.

    
por 22.03.2010 / 09:19
0

CHeck o arquivo / var / log / syslog deve ter mais alguma informação sobre o motivo pelo qual o daemon ssh não é capaz de inicializar, apenas verificando também que você não tem um daemon zumbi ssh rodando na sua máquina que pode estar causando alguns problemas (verifique a saída de ps -ef | grep ssh )?

    
por 22.03.2010 / 19:47
-1

Acesso ao console - > Verificar logs para SSHd - > Corrigir.

    
por 22.03.2010 / 10:30