ssh conexões para o Ubuntu são intermitentes

2

Estou tentando usar o ssh para conectar de um Mac ao Ubuntu 12.04. Eu recebo "Conexão redefinida pelo peer." Tente novamente e recebo "porta 22: Conexão recusada". Continue tentando e recebo uma solicitação de senha. Digite a senha e faça o login com sucesso. Faça alguns comandos e, em seguida, "Falha na gravação: cano quebrado" e a conexão será interrompida.

A rede é Ethernet com fio. Tanto o servidor Ubuntu quanto o cliente Mac na mesma sub-rede conectada ao mesmo switch. Outras redes de ambos parecem estar funcionando bem, ou seja, posso usar o navegador da Web.

Eu fiz apt-get install openssh-server

Eu entrei no console e verifiquei se o sshd está em execução.

ps -ef | grep sshd
root 1003 1 0 Nov29 ? 00:00:00 /usr/sbin/sshd -D

eu corri ufw allow ssh

Em seguida, no Mac, tente de novo e de novo:

Kens-MacBook-Pro-44% ssh 10.1.10.197
ssh: connect to host 10.1.10.197 port 22: Connection reset by peer
Kens-MacBook-Pro-44% ssh 10.1.10.197
ssh: connect to host 10.1.10.197 port 22: Connection refused
Kens-MacBook-Pro-44% ssh 10.1.10.197
ssh: connect to host 10.1.10.197 port 22: Connection refused
Kens-MacBook-Pro-44% ssh 10.1.10.197
[email protected]'s password: '

De repente, funciona. Coloque a senha e

Welcome to Ubuntu 12.04.5 LTS (GNU/Linux 3.2.0-72-generic-pae i686)...

Para que eu possa fazer algumas coisas, como mostrar o log:

garges@oxfordhouse:~$ cd /var/log
garges@oxfordhouse:/var/log$ tail auth.log
Nov 30 00:06:00 oxfordhouse sshd[3392]: pam_unix(sshd:session): session closed for user garges
Nov 30 00:08:49 oxfordhouse sshd[3647]: Set /proc/self/oom_score_adj to 0
Nov 30 00:08:49 oxfordhouse sshd[3647]: Connection from 10.1.10.14 port 55453
Nov 30 00:08:49 oxfordhouse sshd[3647]: Failed publickey for garges from 10.1.10.14 port 55453 ssh2
Nov 30 00:08:49 oxfordhouse sshd[3647]: Failed publickey for garges from 10.1.10.14 port 55453 ssh2
Nov 30 00:08:57 oxfordhouse sshd[3647]: Accepted password for garges from 10.1.10.14 port 55453 ssh2
Nov 30 00:08:57 oxfordhouse sshd[3647]: pam_unix(sshd:session): session opened for user garges by (uid=0)
Nov 30 00:08:57 oxfordhouse sshd[3647]: User child is on pid 3773
Nov 30 00:09:01 oxfordhouse CRON[3876]: pam_unix(cron:session): session opened for user root by (uid=0)
Nov 30 00:09:02 oxfordhouse CRON[3876]: pam_unix(cron:session): session closed for user root'

E mostre meu arquivo de configuração:

garges@oxfordhouse:/var/log$ cd /etc/ssh
garges@oxfordhouse:/etc/ssh$ cat sshd_config
# Package generated configuration file

# See the sshd_config(5) manpage for details'

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel VERBOSE

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

Alguns outros comandos ls sem sentido e depois bang, a conexão é fechada:

garges@oxfordhouse:/etc/ssh$ ls
moduli       sshd_config.bak       ssh_host_ecdsa_key      ssh_host_rsa_key.pub
ssh_config   ssh_host_dsa_key      ssh_host_ecdsa_key.pub  ssh_import_id
sshd_config  ssh_host_dsa_key.pub  ssh_host_rsa_key
garges@oxfordhouse:/etc/ssh$  Write failed: Broken pipe
Kens-MacBook-Pro-44% 

Todo esse cenário é muito repetitivo. Acontece mesmo depois de uma reinicialização do Mac e do Ubuntu. Outras conexões de rede no Mac e no Ubuntu funcionam bem.

Alguma ideia?

    
por Kenneth Garges 30.11.2014 / 09:49

1 resposta

0

Muito estranho mesmo. Você poderia tentar várias alternativas:

  • sudo ping -f 10.1.10.197 para enviar muitos pacotes ICMPs. Isto escreve um ponto enquanto envia um pacote e o remove quando recebe uma resposta (pong). Se a tela começar a escrever muitos pontos, é porque os pacotes caem em algum lugar no meio.
  • mtr 10.1.10.197 é traceroute com esteróides.
  • arp-scan -t 200 -l -I eth0 para descobrir se alguém também tem o mesmo IP (como diz Rmano). Você pode tentar o endereço IP estático para evitar este.
  • Defina a preferência keep alive no cliente ssh (adicionando a quantidade de segundos antes do servidor enviar o código no-op):
    • globalmente em /etc/ssh/ssh_config adicionando: ServerAliveInterval 60
    • ou para o usuário atual adicionando ~/.ssh/config :
        

      Anfitrião *

           

      ServerAliveInterval 60

    •   
  •   
por Pablo Bianchi 06.12.2014 / 19:08