Compatibilidade de cifra entre o cliente OpenSSH_3.1 e o servidor ssh OpenSSH_7.3p1

Question

Eu tenho que mudar meu antigo servidor ssh.

O sshd antigo era o OpenSSH_4.7p1, enquanto o novo é o OpenSSH_7.3p1.

Eu também tenho muitos clientes antigos baseados no Slackware 8.1 (2002) com um cliente ssh muito antigo OpenSSH_3.1p1

FROM : Linux P0101222 2.4.37.9_20130117
       sshd: OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f

TO   : Linux LinuxServer1 4.8.10-300.fc25.i686
       sshd: OpenSSH_7.3p1, OpenSSL 1.0.2j-fips  26 Sep 2016

       old sshd: OpenSSH_4.7p1, OpenSSL 0.9.8b 04 May 2006

Meu problema agora é que o cliente antigo não pôde se conectar ao novo servidor ssh devido à codificação diferente usada.

[enzo@P0101222 enzo]$ ssh 192.168.200.37
no matching cipher found: 
client aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,
aes192-cbc,aes256-cbc server [email protected],
aes128-ctr,aes192-ctr,aes256-ctr,[email protected],
[email protected]

e aqui o log detalhado

[enzo@P0101222 enzo]$ ssh -v 192.168.200.37
OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, 
        originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 500 geteuid 0 anon 1
debug1: Connecting to 192.168.200.37 [192.168.200.37] port 22.
debug1: temporarily_use_uid: 500/500 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 500/500 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /home/enzo/.ssh/identity type -1
debug1: identity file /home/enzo/.ssh/id_rsa type 1
debug1: identity file /home/enzo/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, 
        remote software version OpenSSH_7.3
debug1: match: OpenSSH_7.3 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.1p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
no matching cipher found: client aes128-cbc,
3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,
aes256-cbc server [email protected],aes128-ctr,
aes192-ctr,aes256-ctr,[email protected],
[email protected]
debug1: Calling cleanup 0x80634c0(0x0)

Minha pergunta é se é possível gerenciar os clientes antigos ou talvez o servidor sshd para permitir que o cliente se conecte ao novo servidor sshd

ssh openssh

por enzo2 14.12.2016 / 08:43

Answer 1

A partir da saída, o cliente está oferecendo esta lista de códigos:

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc

e servidor este:

debug2: kex_parse_kexinit: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]

Você pode perceber que não há interseção.

O openssh atual não oferece *-cbc de cifras por padrão, mas você pode configurá-lo para aceitá-los usando (o ataque real é muito complicado)

Match Host IP_of_the_legacy_client #can be omited
  Ciphers +aes128-cbc,aes192-cbc,aes256-cbc

bloqueia no final do seu sshd_config .

Problema semelhante que você terá com os métodos de troca de chaves. O cliente oferece apenas

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

mas o servidor tem um conjunto diferente:

debug2: kex_parse_kexinit: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1

Mas, novamente, esses métodos ainda existem no OpenSSH atual e podem ser ativados em sshd_config :

KexAlgorithms +diffie-hellman-group-exchange-sha1

A última coisa é MAC e você pode encontrar o hmac-sha1 comum, então não há problema.

Para mais informações, consulte a página Legacy do OpenSSH .