Significado de "Conexão fechada por xxx [preauth]" nos logs sshd

54

Temos um script em lote do Windows, que se conecta automaticamente a um servidor Linux via PLINK (putty). Não há autenticação de chave privada pública, o usuário e a senha estão no script.

Em nosso servidor linux, temos várias entradas de log sshd (/ var / log / messages):

sshd[7645]: Connection closed by xxx [preauth]

Qual poderia ser a causa dessa mensagem?
"preauth" supostamente significa "pré autenticação"?

Às vezes, na entrada "fechado por" há o endereço IP do cliente Windows, outra vez há o endereço IP do servidor Linux em "fechado por". Alguém sabe a diferença entre o endereço IP do cliente e o endereço IP do host na mensagem?

ssh logs authentication

— Wolfgang Adamec
fonte

Quando observado em /usr/local/sbin/sshd -D -e, possível solução alternativa: serverfault.com/a/211176

— Ivan Chau

Estou enfrentando o mesmo problema e, no meu caso, reduzi-o ao fato de que a mesma chave funciona em um shell do ubuntu em um ubuntu real executando como uma VM e não no ubuntu incorporado ao Windows 10 (AKA Windows Linux Subsystem) . Já não descobri porque ainda, mas talvez isso ainda ajuda alguém

— Jens Kisters

Check /var/log/secure- LogLevel DEBUG3in/etc/ssh/sshd_config

— Ivan Chau

24

O sshdservidor será desconectado se o cliente não tentar se autenticar em um determinado período de tempo, conforme documentado na -gopção.

 -g login_grace_time
         Gives the grace time for clients to authenticate themselves
         (default 120 seconds).  If the client fails to authenticate
         the user within this many seconds, the server disconnects
         and exits.  A value of zero indicates no limit.

Portanto, suspeito que, se você vir o IP do servidor nos logs com esta mensagem, a conexão foi fechada porque nenhuma tentativa de autenticação ocorreu dentro desse período de cortesia. Quando você vê o IP do cliente, significa que o usuário fechou o cliente (ou o script foi finalizado) sem fazer uma tentativa de autenticação.

— oeuftete
fonte

Pode ser causado por, por exemplo, digitalização nmap?

— QBack

Isso geralmente é tentativas de invasão. Eu vejo um monte de China, Rússia, Japão, etc.

— jjxtra

3

Se o endereço IP na mensagem for o endereço IP do cliente, isso pode indicar que o cliente está tentando se autenticar com a senha incorreta da chave privada. Seu cliente então falha ao decodificar a chave e desconecta sem tentar a autenticação.

— Code Commander

7

No meu caso, essas mensagens apareceram em / var / log / secure quando eu estava tendo Host key verification failed.erros no lado do cliente ssh. Este é um dos casos que resultaria em uma conexão sem uma tentativa de login.

— pcronina
fonte

4

Eu tive um problema muito semelhante ao seu (embora eu estivesse usando chave pública).

Acontece que meu problema, e possivelmente o seu, foi causado porque meu diretório pessoal era uma montagem NFS e o selinux (no CentOS 7) estava apresentando alguns erros (que eram bastante difíceis de rastrear). A correção foi simples.

setsebool -P use_nfs_home_dirs 1

— Simon
fonte

2

Outra fonte desse tipo de mensagem é ssh-keyscan. Ele apenas pega as chaves do host do servidor e desconecta sem fazer nenhuma autenticação.

— x-yuri
fonte

2

Uma fonte dessas mensagens é https://sshcheck.com/, que exibe possíveis fraquezas no seu servidor ssh.

Faz com que cerca de 4 dessas mensagens sequencialmente.

— Daniel F
fonte

1

Eu tive o mesmo problema, resolvi-o assim:

No servidor ssh, tirei o comentário e coloquei em yes os seguintes valores em / etc / ssh / sshd_config

 RSAAuthentication yes
 PubkeyAuthentication yes

E depois:

sudo service sshd restart

— mate
fonte

0

Eu conheci a mesma situação, por causa da iptablesregra INPUT foi DROP, mas ACEITO o host ansible, mas não há a regraiptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

O log de erros "Nov 3 01:34:50 debian sshd[29378]: Connection closed by 10.17.64.13 [preauth]"foi gravado na "/var/log/auth.log"máquina do cliente após ansible all -m pinga execução do comando no host ansible.

Porque o pacote ping foi recebido pelo cliente, mas não retornou ao host ansible.

— VictorLee
fonte