sshd é encerrado com o erro "Nenhum algoritmo de troca de chave suportada"

7

sshd

$ /usr/sbin/sshd -f testconfig -p 22025 -d

debug1: sshd version OpenSSH_5.2p1
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: setgroups() failed: Operation not permitted
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-f'
debug1: rexec_argv[2]='testconfig'
debug1: rexec_argv[3]='-p'
debug1: rexec_argv[4]='22025'
debug1: rexec_argv[5]='-d'
debug1: Bind to port 22025 on 127.0.0.1.
Server listening on 127.0.0.1 port 22025.
Generating 1024 bit RSA key.
RSA key generation complete.
debug1: fd 4 clearing O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from 127.0.0.1 port 58477
debug1: Client protocol version 2.0; client software version OpenSSH_5.5
debug1: match: OpenSSH_5.5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug1: privsep_preauth: successfully loaded Seatbelt profile for unprivileged child
debug1: list_hostkey_types: 
No supported key exchange algorithms
debug1: do_cleanup
debug1: do_cleanup
debug1: audit_event: unhandled event 12

ssh

$ ssh [email protected] -p 22025 -i ./id_rsa.pub -v
OpenSSH_5.5p1, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /Users/dgl/.ssh/config
debug1: Reading configuration data /opt/local/etc/ssh/ssh_config
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 22025.
debug1: Connection established.
debug1: identity file ./id_rsa.pub type 1
debug1: identity file ./id_rsa.pub-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2
debug1: match: OpenSSH_5.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5
debug1: SSH2_MSG_KEXINIT sent
Connection closed by 127.0.0.1

ssh_config

Protocol 1,2
ListenAddress 127.0.0.1
HostKey ./ssh_host_key
HostKey ./ssh_host_rsa_key
HostKey ./ssh_host_dsa_key
RSAAuthentication yes
PubkeyAuthentication yes
    
por Dmitry Gladkov 07.07.2010 / 13:08

9 respostas

6

Acabei de acertar o mesmo problema, resolvi-o transformando meu caminho relativo da HostKey em um caminho absoluto, ou seja, em vez de

HostKey ./ssh_host_key

colocar:

HostKey /home/dmitry/ssh_host_key

ou onde quer que esteja.

Esse erro não é muito útil, não é?

    
por 17.02.2011 / 03:06
14

Eu encontrei este problema no Fedora. Eventualmente, notei:

root@wisdom:/etc/ssh# ll
total 268K
drwxr-xr-x.   2 root root     4.0K Jun 30 06:06 ./
drwxr-xr-x. 128 root root      12K Jun 30 05:15 ../
-rw-r--r--.   1 root root     237K Jun  8 23:30 moduli
-rw-r--r--.   1 root root     2.2K Jun  8 23:30 ssh_config
-rw-------.   1 root root     4.3K Jun 30 06:03 sshd_config
-rw-r-----.   1 root ssh_keys    0 Jun 27 00:46 ssh_host_ecdsa_key
-rw-r--r--.   1 root root        0 Jun 27 00:46 ssh_host_ecdsa_key.pub
-rw-r-----.   1 root ssh_keys    0 Jun 27 00:46 ssh_host_ed25519_key
-rw-r--r--.   1 root root        0 Jun 27 00:46 ssh_host_ed25519_key.pub
-rw-r-----.   1 root ssh_keys    0 Jun 27 00:46 ssh_host_rsa_key
-rw-r--r--.   1 root root        0 Jun 27 00:46 ssh_host_rsa_key.pub

Os arquivos principais são de tamanho zero! Geramos novos pares de chaves e resolvemos o problema:

ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key
    
por 29.06.2015 / 22:26
4

FWIW, acabei de encontrar a mesma mensagem de erro, mas com uma causa diferente. No meu caso, o problema era que meus arquivos de chave privada do host eram o modo 640 em vez de 600. Um rápido chmod e o sshd restart resolveram o problema. Eu acho que o tema comum aqui é o sshd não carregar as chaves do host por uma razão ou outra.

    
por 11.10.2011 / 19:32
2

Eu realmente me deparei com esse problema ... e foi nosso bom e velho amigo SELinux.

A execução de setenforce 0 prova que funcionou, mas essa não é uma boa solução. No entanto, assim que isso ajudou a tornar a solução final mais clara.

$ cd /etc/ssh
$ restorecon -Rv *

Reativando o SELinux ( setenforce 1 ) ... e tudo está bem.

    
por 09.08.2013 / 13:14
1

Acabei de ter este problema com o cloud-init . No meu caso, a causa foi que as chaves do host não tinham sido geradas, e dpkg-reconfigure openssh-server (Debian / Ubuntu-specific) corrigiu isso.

    
por 19.02.2012 / 21:12
1

Eu encontrei essa mensagem de erro e resolvi isso:

UsePAM yes

Isso aconteceu apenas com contas sem senha (como o root).

    
por 07.03.2013 / 21:43
0

Para mim, o que foi corrigido foi adicionar estas linhas do / etc / ssh / sshd_config:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192
-cbc,aes256-cbc,arcfour,[email protected]

KexAlgorithms [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exch
ange-sha1,diffie-hellman-group1-sha1

HostkeyAlgorithms +ssh-dss
    
por 22.08.2016 / 20:13
0

No meu caso, a questão era um perfil excessivamente entusiasta.

Também recebi a seguinte mensagem no meu arquivo /var/log/auth.log:

fatal: linux_audit_write_entry failed: Permission denied

Resolvido pela execução:

aa-complain /etc/apparmor.d/usr.sbin.sshd
    
por 18.09.2016 / 04:37
0

Eu perdi 6 horas com isso! Eu tentei todas as soluções aqui e muito mais! sem sucesso! Em seguida, purged openssh-server e reinstalado e funcionou muito bem e eu reconfigurou tudo o que levou cerca de 15 minutos! E aprendi uma ótima lição!

Nunca perca tempo com a depuração de algo que você possa voltar a trabalhar, redefini-lo!

Não há nenhum ganho em lidar com cada bit de cada arquivo de configuração e informações de depuração de cada aplicativo!

    
por 12.02.2018 / 17:51

Tags