Não é possível iniciar, parar ou interagir com o serviço SSH

Question

Ter um comportamento realmente bizarro com ssh . Eu tenho o servidor ssh funcionando bem, configurei ufw (firewall) bem também. No entanto, parece que não consigo gerenciar ssh como um serviço ou através de /etc/init.d/ssh .

Eu re-instalei openssh-server especificamente para garantir que meus pequenos ajustes na configuração de /etc/ssh/sshd_config não fossem o problema.

Ubuntu:~/$ sudo /etc/init.d/ssh status

Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service ssh status

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the status(8) utility, e.g. status ssh
ssh stop/waiting

e

Ubuntu:~/$ sudo service ssh status
ssh stop/waiting

mas eu posso ssh fine (seja do Ubuntu [localhost] ou outro computador [remotamente], presumindo que o nome do comp é o Ubuntu)

otherComputer:~/$ ssh me@Ubuntu
me@Ubuntu's password:
me@Ubuntu:~/$

Muito frustrante, sem saber qual é o problema. Estou executando gnome-keyring para gerenciar minhas ssh-agent e chaves, mas isso não deve interferir no ssh-server como um serviço.

    

Answer 1

O que se segue assume que o computador no qual você reinstalou o openssh-server e do qual você é ssh ing é NÃO "Ubuntu", a máquina que você acessa por meio de ssh me@Ubuntu .

Eu acho que o seu problema é a confusão sobre a diferença entre o daemon ssh e o cliente ssh. O daemon ssh ( sshd ) é o programa que permite que você ou outros usuários usem ssh na máquina em que o daemon está sendo executado. Quando você executa sudo service ssh <whatever> , está dando comandos para sshd , ou seja, para iniciar ou parar ou o que quer que seja.

A outra parte do ssh é o cliente ssh. Isso é o que você inicia sempre que executa ssh [email protected] em um terminal. Este é um programa auto-contido que se conecta com o daemon ssh em execução no computador chamado " host.name ". Para que ssh funcione, deve haver um daemon ssh em execução no computador ao qual ele deseja se conectar, mas não precisa estar em execução em seu próprio computador.

O que isto tudo significa é que o seu computador está funcionando perfeitamente bem. Você pode ssh out para um servidor remoto contanto que você tenha uma rede.

Na verdade, você provavelmente deve remover o pacote openssh-server do seu computador como se ele não estivesse sendo usado. Tudo o que ele faria seria ser um risco de segurança.

    

Answer 2

@ alex-l resposta para mim está certo:

(como root)

 service ssh status
service ssh stop

verifique se a porta está ativa (22)

netstat -nat

é tudo

outra coisa que você pode fazer para verificar se ereytinh está ok é fazer de outra máquina e

ssh -v user@ubuntu-machine

    

O

Answer 3

Vale a pena saber que, até onde sei, o comando 'service ssh [stop | status]' aplica-se ao processo identificado em /var/run/sshd.pid, mas o processo real de escuta pode ser identificado executando ' sudo netstat -lpn | grep ssh 'se eles não corresponderem, será por isso que a confusão está lá.

Na minha máquina, isso é o que eu vejo: -

root@babypuss:/var/www/middletier# ls /var/run/sshd.pid
/var/run/sshd.pid
root@babypuss:/var/www/middletier# cat /var/run/sshd.pid
10959
root@babypuss:/var/www/middletier# ps ax |grep sshd
10959 ?        Ss     0:00 /usr/sbin/sshd -D

Se o pid não corresponder, então (como root) mate o processo sshd em execução e inicie-o novamente com 'service ssh start' para ver o que acontece.

Mas como foi dito anteriormente, se na máquina Ubuntu, você pode rodar 'ps ax | grep sshd' e não ver nada rodando, então verifique se não há algum tipo de serviço xinet afirmando via 'netstat -lpn | grep 22 'que nada está escutando na porta 22. Se nada estiver realmente escutando, então o problema mais provável é que a máquina que você está conectando, de algum outro lugar, não é a que você está olhando (então verifique o arquivo / etc / hosts no @outroComputador).

Se você tem 90% de certeza de que está se conectando à máquina que você pensa que é, então verifique com 'netstat -n | grep -v ^ unix' em cada máquina, para identificar a conexão real, e o shell executando no @Ubuntu quando estiver conectado.

Se você realmente não consegue ver o serviço de escuta, tenha medo. Pode ser um rootkit. Tente desligar o computador e tentar se reconectar, para ter certeza absoluta de que você está se conectando à máquina que está preocupando.