Conexão SSH recusada - Depurar usando o Console de Recuperação

Question

Eu encontrei uma tonelada de perguntas respondidas sobre depuração porque não se pode conectar via SSH, mas todas elas parecem exigir que você ainda possa acessar o sistema - ou dizer que sem que nada possa ser feito. No meu caso, não consigo acessar o sistema diretamente, mas tenho acesso ao sistema de arquivos usando um console de recuperação.

Portanto, esta é a situação: Meu provedor fez algumas atualizações do kernel hoje e, no processo, também reinicializou meu servidor. Por alguma razão, não consigo mais me conectar via SSH, mas em vez disso, ssh: conecta-se ao host mydomain.de porta 22: Conexão recusada

Eu não sei se o sshd simplesmente não está rodando, ou se algo (por exemplo, iptables) bloqueia minhas tentativas de conexão ssh. Eu olhei para os arquivos de log, nenhum dos arquivos em / var / log contém qualquer menção em ssh e /var/log/auth.log está vazio. Antes da atualização do kernel, eu podia logar muito bem e usar certificados para que eu não precisasse de uma senha toda vez que eu conectasse da minha máquina local.

O que eu tentei até agora:

1. Eu olhei em /etc/rc*.d/ para um link para o script /etc/init.d/ssh e não encontrei nenhum. Então, estou esperando que o sshd não seja iniciado corretamente na inicialização. Como não consigo executar nenhum programa no meu sistema, não posso usar o update-rc para alterar isso. Eu tentei fazer um link manualmente usando ln -s /etc/init.d/ssh /etc/rc6.d/K09sshd e reiniciei o servidor - isso não resolveu o problema. Eu não sei se é de todo possível fazer assim e se é correto criá-lo no rc6.d e se o K09 está correto. Acabei de copiar isso do apache.

2. Eu também tentei alterar meu arquivo /etc/iptables.rules para permitir tudo:

# Generated by iptables-save v1.4.0 on Thu Dec 10 18:05:32 2009
*mangle
:PREROUTING ACCEPT [7468813:1758703692]
:INPUT ACCEPT [7468810:1758703548]
:FORWARD ACCEPT [3:144]
:OUTPUT ACCEPT [7935930:3682829426]
:POSTROUTING ACCEPT [7935933:3682829570]
COMMIT
# Completed on Thu Dec 10 18:05:32 2009
# Generated by iptables-save v1.4.0 on Thu Dec 10 18:05:32 2009
*filter
:INPUT ACCEPT [7339662:1665166559]
:FORWARD ACCEPT [3:144]
:OUTPUT ACCEPT [7935930:3682829426]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 143 -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 8080 -s localhost -j ACCEPT
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
-A INPUT -j ACCEPT
-A FORWARD -j ACCEPT
-A OUTPUT -j ACCEPT
COMMIT
# Completed on Thu Dec 10 18:05:32 2009
# Generated by iptables-save v1.4.0 on Thu Dec 10 18:05:32 2009
*nat
:PREROUTING ACCEPT [101662:5379853]
:POSTROUTING ACCEPT [393275:25394346]
:OUTPUT ACCEPT [393273:25394250]
COMMIT
# Completed on Thu Dec 10 18:05:32 2009

Não tenho certeza se isso é feito corretamente ou se tem algum efeito. Eu também não encontrei nenhuma menção de iptables em qualquer arquivo em / var / log.

Então, o que mais eu posso fazer? Obrigado pela sua ajuda.

p.s .: Depois de adicionar a linha crontab como sugerido por lain, posso encontrar o seguinte no arquivo /var/logauth.log

Mar  7 21:13:58 mysubdomain sshd[64900]: debug1: sshd version OpenSSH_5.3p1 Debian-3ubuntu5
Mar  7 21:13:58 mysubdomain sshd[64900]: debug1: read PEM private key done: type RSA
Mar  7 21:13:58 mysubdomain sshd[64900]: debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
Mar  7 21:13:58 mysubdomain sshd[64900]: debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
Mar  7 21:13:58 mysubdomain sshd[64900]: debug1: private host key: #0 type 1 RSA
Mar  7 21:13:58 mysubdomain sshd[64900]: debug1: read PEM private key done: type DSA
Mar  7 21:13:58 mysubdomain sshd[64900]: debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
Mar  7 21:13:58 mysubdomain sshd[64900]: debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
Mar  7 21:13:58 mysubdomain sshd[64900]: debug1: private host key: #1 type 2 DSA

    

Answer 1

A conexão recusada sugere que o sshd não esteja em execução. Tente executar o sshd no modo de depuração a partir da linha de comando para ver se há alguma mensagem de erro.

/usr/sbin/sshd -f /etc/ssh/sshd_config -D -d

EDITAR:

Como você não tem acesso para executar o acima, tente colocá-lo em uma tarefa do @reboot cron

Adicionar

@reboot root /bin/mkdir -p -m0755 /var/run/sshd && /usr/sbin/sshd -f /etc/ssh/sshd_config -d &>/var/log/sshd_debug

em /etc/crontab

O Ubuntu sshd requer que o diretório / var / run / sshd exista.

    

Answer 2

Você pode tentar adicionar log (tráfego SSH) às regras do firewall e reiniciar a máquina. Desta forma, você deve ser capaz de verificar se os seus pacotes chegam ao destino (portanto, o sshd não está funcionando).

Sobre esta parte:

I tried to make a link manually using ln -s /etc/init.d/ssh /etc/rc6.d/K09sshd and restarted the server - this did not fix the problem.

Runlevel 6 é para reiniciar, então não é isso que você está interessado. E K no K09sshd é para matar. ;-) Tente usar a solução mencionada por odk e veja o que acontece.

    

Answer 3

I tried to make a link manually using ln -s /etc/init.d/ssh /etc/rc6.d/K09sshd and restarted the server - this did not fix the problem

Você quase acertou. Os nomes K * fazem com que um serviço seja interrompido. Os nomes S * fazem com que o serviço seja iniciado.

rc6.d é para controlar subsistemas ao entrar no nível de execução 6, o que significa "reinicializar".

Você deseja que o serviço seja iniciado nos runlevels 3 (multiusuário normal) e 5 (multiusuário + X). Torne os links simbólicos /etc/rc.3d/S90sshd e /etc/rc5.d/S90sshd para /etc/init.d/sshd Isso deve fazer com que o sshd seja iniciado na inicialização do sistema.

    

Answer 4

Eu entendi. Primeiro de tudo, muito obrigado a todos que estavam tentando ajudar!

Para aqueles que estão navegando nos arquivos com um problema similar: O problema inicial era que os links /etc/rc*.d/ não estavam definidos, este sshd não foi executado na inicialização. Minhas numerosas tentativas de consertar isso foram estragadas por causa da maneira como funciona: Quando eu crio os links fazendo

$ cd /repair/etc/rc3.d/
$ ln -s ../init.d/ssh S20sshd

e similar para todos os runlevels, os links criados pareciam totalmente perfeitos no modo de recuperação. No entanto, quando finalmente consegui fazer o login usando o hack descrito acima, pude ver que todos os links estavam quebrados, por exemplo

$ ls /etc/rc3.d/
...
lrwxrwxrwx 1 root root  10 2011-03-08 09:51 S20sshd -> init.d/ssh
...

então o link relativo agora aponta para algum lugar errado.

Para consertar isso, adicionei ao topo de outro script de inicialização a linha (ATENÇÃO: HACK !!!)

/etc/init.d/ssh start

que funcionou bem e me permitiu entrar novamente. Eu removi todos os links quebrados e criei novos, usando update.rc.

Mais uma vez muito obrigado por toda a ajuda!

    

Answer 5

I tried to make a link manually using ln -s /etc/init.d/ssh /etc/rc6.d/K09sshd and restarted the server - this did not fix the problem

Tente adicionar o link não ao /etc/rc6.d mas ao rc3.d (ln -s /etc/init.d/ssh /etc/rc3.d/S99sshd)

    

Answer 6

Você escreveu que tem acesso de gravação ao sistema de arquivos e pode alterar arquivos e modificar regras de firewall.

Eu suponho que você também pode executar uma reinicialização do seu sistema no modo de operação normal.

Nesse caso, sugiro, a princípio, omitir a tentativa de fazer o servidor SSH funcionar corretamente e expor um shell remoto simples em uma porta alta, usando o Utilitário NetCat .

Você deve:

1. verificar se o seu sistema tem o netcat instalado e qual versão (por exemplo, as distribuições derivadas do Fedora têm uma versão completamente diferente da Debian, e elas diferem significativamente nas opções de linha de comando)
2. Se não, compile estaticamente a partir de fontes (um binário estático não requer nenhuma biblioteca adicional) e faça o upload para o seu sistema de arquivos. Compile com a opção de compilação GAPING_SECURITY_HOLE para que a opção "-e" esteja disponível
3. escolha um número de porta que ele deve ouvir (por exemplo, 1234) e adicione uma regra de firewall que permita acesso somente a essa porta do IP do cliente (caso contrário, você estaria abrindo uma lacuna de segurança)
4. faz com que ele comece a partir de um script de inicialização (rc.local?) e seja executado em segundo plano, expondo o shell Bash, por exemplo: nohup nc -l -p 1234 -e '/bin/bash' &

Dessa forma, você obterá um shell root simples e remoto sem nenhuma autenticação (perigosa!), ao qual você pode se conectar remotamente usando netcat ou telnet ( nc your.server.address 1234 ).

Lembre-se de matá-lo e removê-lo dos scripts de inicialização do sistema assim que o seu servidor SSH estiver funcionando!