O SSH parou de funcionar após uma atualização do servidor? O que aconteceu?

7

Eu tenho usado conexões SSH baseadas em PKI há mais de 10 anos. De repente, após uma atualização do servidor - algumas das conexões pararam de funcionar. Eu estou usando as mesmas chaves PKI que tenho usado há anos (cada servidor tem suas próprias chaves, eu tenho um pequeno conjunto de chaves pessoais).

Trabalhando - é assim:

C:\Users\michael>ssh2 -p 2222 [email protected] date
Authentication successful.
Fri Nov 25 10:30:42  2016

Não funciona:

C:\Users\michael>ssh2 [email protected] date
warning: Authentication failed.
Disconnected; key exchange or algorithm negotiation failed (Algorithm negotiation failed.).

O que mudou?

    
por Michael Felt 25.11.2016 / 13:21

1 resposta

12

FYI: este é um Q & A - onde eu forneço a minha resposta à pergunta, mais são bem-vindos - eu gosto de aprender (o que eu perdi)! Espero que aumente sua compreensão de como o openssh se conecta e / ou como depurar problemas de conexão openssh

Após uma atualização - efeitos colaterais podem entrar em jogo. Com o OpenSSH - os padrões mudam com freqüência. O OpenBSD (que mantém / desenvolve o OpenSSH) tem uma política do OpenBSD de não se preocupar com compatibilidade com versões anteriores. Isso pode 'quebrar' coisas que são, leia estavam, funcionando bem.

Há uma dica massiva - que eu não notei quando isso aconteceu comigo (usando a interface GUI, e eu apenas cliquei e fiquei 'bravo' com 'atualização estúpida - a nova versão está quebrada'. Acontece que a nova versão não foi quebrada - mas o OpenBSD / OpenSSH começando a mudar os padrões de troca de chaves começando com o OpenSSH-6.7p1 veja: link , notadamente:

Changes since OpenSSH 6.6

Potentially-incompatible changes

  • sshd(8): The default set of ciphers and MACs has been altered to
    remove unsafe algorithms. In particular, CBC ciphers and arcfour*
    are disabled by default.

    The full set of algorithms remains available if configured
    explicitly via the Ciphers and MACs sshd_config options.

Meu problema é que eu tenho um cliente antigo que não possui nenhum dos novos padrões, por isso não pode se conectar.

Dois caminhos de solução: corrigir / corrigir o servidor ou - corrigir / corrigir o cliente.

Solução de servidor: traga de volta as configurações "antigas" para que os clientes "antigos" possam continuar a se conectar, seja amigável aos clientes existentes, edite o arquivo sshd_config e adicione de volta (o suficiente) as cifras antigas.

As linhas chave para alterar / adicionar no sshd_config são:

ciphers aes128-ctr,aes192-ctr,aes256-ctr,[email protected],aes256-cbc
KexAlgorithms  [email protected],diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
macs hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-sha1

Basta adicionar:

# Ciphers
# The dafaults starting with OpenSSH 6.7 are:
# aes128-ctr,aes192-ctr,aes256-ctr,[email protected]
# older clients may need an older cipher, e.g.
# ciphers aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,arcfour
# only adding aes256-cbc as an "old" cipher

ciphers aes128-ctr,aes192-ctr,aes256-ctr,[email protected],aes256-cbc

# KEX Key Exchange algorithms
# default from openssh 6.7 are:
# [email protected],diffie-hellman-group-exchange-sha256,\
#  diffie-hellman-group14-sha1
# an older kex are: none,KexAlgorithms diffie-hellman-group1-sha1

# only adding diffie-hellman-group-sha1  as an "old" KEX
# and this should be deleted ASAP as it is clearly "one of the problems" with SSL based encryption
KexAlgorithms  [email protected],diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

# MAC message authentification code
# the new defaults are:
# [email protected],[email protected],
# [email protected],hmac-sha2-512-
# [email protected],
# [email protected],[email protected],
# hmac-sha2-256,hmac-sha2-512

# older defaults (still supported) are:
# macs hmac-sha1,hmac-md5

# consider removing hmac-sha1-96,hmac-sha1,hmac-md5 "Soon!"
macs hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-sha1

Solução # 2 - corrija / substitua o cliente

Uma maneira fácil de ver quais cifras você suporta o cliente atual (assumindo a CLI) é ssh -h e ver se isso fornece algo como:

Supported ciphers:
  3des-cbc,aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,twofish-cbc,twofish256-cbc,twofish192-cbc,twofish128-cbc,[email protected],cast128-cbc,[email protected],arcfour,none
Supported MAC algorithms:
  hmac-md5,hmac-md5-96,hmac-sha1,hmac-sha1-96,[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],none

Outro comando útil é: ssh -V

ssh2: SSH Secure Shell 3.2.9 Windows Client
Product: SSH Secure Shell for Workstations
License type: none (non-commercial)

Meu - era - um cliente muito antigo - para o meu desktop. Olhando acima, você pode ver que ele não suporta nenhum dos algoritmos preferidos - 15 anos depois -, nem mesmo um -cbr (rotativo), apenas -cbc (block-copy).

Se o seu cliente não tem a opção de fornecer as chaves, etc. suportadas (o OpenSSH deve ter a opção -Q ) apenas inicie uma conexão consigo mesmo, por exemplo, ssh -v localhost e existem linhas como esta para contar você é conhecido:

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-grousha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected]@openssh.com,[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
...

E o que foi encontrado (e usado):

debug2: mac_setup: found hmac-sha1
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug2: mac_setup: found hmac-sha1
debug1: kex: client->server aes128-ctr hmac-sha1 none

Extra: informações de depuração de uma conexão com falha - mais detalhes

Ou o que foi tentado, mas perdeu.

debug: OpenSSH: Major: 7 Minor: 3 Revision: 0
debug: Ssh2Transport: All versions of OpenSSH handle kex guesses incorrectly.
debug: Ssh2Transport: Algorithm negotiation failed for c_to_s_cipher: client list: aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour vs. server list : [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug: Ssh2Transport: Algorithm negotiation failed for s_to_c_cipher: client list: aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour vs. server list : [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug: Ssh2Transport: lang s to c: '', lang c to s: ''
debug: Ssh2Transport: Couldn't agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host_key = ssh-rsa)
debug: Ssh2Common: DISCONNECT received: Algorithm negotiation failed.

Editar: adicionado 02-jan-2017

Nova seção - e as teclas que param de funcionar?

No meu servidor, tenho um cliente 'antigo' e o cliente 'mais recente' instalado - e obtenho um comportamento diferente na conexão com um servidor. Aqui, o problema não é a correspondência incorreta de cifras - mas o uso de um par PKI arcaico - baseado em DSA.

Em resumo, o openssh-7 (.3) não envia mais (por padrão, talvez nem um pouco) chaves públicas DSA.

Abaixo, comparo a saída de duas versões do openssh
/ usr / bin / ssh (versão antiga, lado esquerdo) e
/ opt / bin / ssh (nova versão, lado direito) - o comando é:

${version}/ssh -v user@host date

Conforme você analisa a saída abaixo, espero que você observe que as etapas e as mensagens são geralmente as mesmas. A principal diferença vem depois da string SSH2_MSG_SERVICE_ACCEPT

O que eu quero que você note é que a versão antiga oferece (e é aceita pelo servidor "antigo" - o par de chaves baseado em DSA, enquanto o novo servidor nunca oferece a chave baseada em DSA.

Nota: a 'solução' para isso é adicionar (pelo menos um dos) pares de PKI baseados em rsa, ecdsa ou ed25519.

OpenSSH_6.0p1, OpenSSL 1.0.2h  3 May 2016                     | OpenSSH_7.3p1, OpenSSL 1.0.2h  3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config        | debug1: Reading configuration data /var/openssh/etc/ssh_confi
debug1: Failed dlopen: /usr/krb5/lib/libkrb5.a(libkrb5.a.so): <
        0509-026 System error: A file or directory in the pat <
                                                              <
debug1: Error loading Kerberos, disabling Kerberos auth.      <
debug1: Connecting to x061 [192.168.129.61] port 22.            debug1: Connecting to x061 [192.168.129.61] port 22.
debug1: Connection established.                                 debug1: Connection established.
debug1: identity file /home/michael/.ssh/id_rsa type 1          debug1: identity file /home/michael/.ssh/id_rsa type 1
                                                              > debug1: key_load_public: No such file or directory
debug1: identity file /home/michael/.ssh/id_rsa-cert type -1    debug1: identity file /home/michael/.ssh/id_rsa-cert type -1
debug1: identity file /home/michael/.ssh/id_dsa type 2          debug1: identity file /home/michael/.ssh/id_dsa type 2
                                                              > debug1: key_load_public: No such file or directory
debug1: identity file /home/michael/.ssh/id_dsa-cert type -1    debug1: identity file /home/michael/.ssh/id_dsa-cert type -1
debug1: identity file /home/michael/.ssh/id_ecdsa type 3        debug1: identity file /home/michael/.ssh/id_ecdsa type 3
                                                              > debug1: key_load_public: No such file or directory
debug1: identity file /home/michael/.ssh/id_ecdsa-cert type -   debug1: identity file /home/michael/.ssh/id_ecdsa-cert type -
debug1: Remote protocol version 2.0, remote software version  | debug1: key_load_public: No such file or directory
debug1: match: OpenSSH_6.0 pat OpenSSH*                       | debug1: identity file /home/michael/.ssh/id_ed25519 type -1
                                                              > debug1: key_load_public: No such file or directory
                                                              > debug1: identity file /home/michael/.ssh/id_ed25519-cert type
debug1: Enabling compatibility mode for protocol 2.0            debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0              | debug1: Local version string SSH-2.0-OpenSSH_7.3
                                                              > debug1: Remote protocol version 2.0, remote software version
                                                              > debug1: match: OpenSSH_6.0 pat OpenSSH* compat 0x04000000
                                                              > debug1: Authenticating to x061:22 as 'padmin'
debug1: SSH2_MSG_KEXINIT sent                                   debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received                               debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none          | debug1: kex: algorithm: ecdh-sha2-nistp256
debug1: kex: client->server aes128-ctr hmac-md5 none          | debug1: kex: host key algorithm: ssh-rsa
                                                              > debug1: kex: server->client cipher: aes128-ctr MAC: umac-64@o
                                                              > debug1: kex: client->server cipher: aes128-ctr MAC: umac-64@o
debug1: sending SSH2_MSG_KEX_ECDH_INIT                          debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY                       debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA 9f:0a:4d:a8:1b:ba:e6:d4:1a:b2:cd | debug1: Server host key: ssh-rsa SHA256:ORf5UVI7mRm/9MthM2qXM
debug1: Host 'x061' is known and matches the RSA host key.      debug1: Host 'x061' is known and matches the RSA host key.
debug1: Found key in /home/michael/.ssh/known_hosts:57          debug1: Found key in /home/michael/.ssh/known_hosts:57
debug1: ssh_rsa_verify: signature correct                     | debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent                                   debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS                              debug1: expecting SSH2_MSG_NEWKEYS
                                                              > debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS received                               debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server                         | debug1: Skipping ssh-dss key /home/michael/.ssh/id_dsa - not
debug1: SSH2_MSG_SERVICE_REQUEST sent                         <
debug1: SSH2_MSG_SERVICE_ACCEPT received                        debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password   debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey                   debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/michael/.ssh/id_rsa      debug1: Offering RSA public key: /home/michael/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password   debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: /home/michael/.ssh/id_dsa    | debug1: Offering ECDSA public key: /home/michael/.ssh/id_ecds
debug1: Server accepts key: pkalg ssh-dss blen 433            | debug1: Authentications that can continue: publickey,password
debug1: read PEM private key done: type DSA                   | debug1: Trying private key: /home/michael/.ssh/id_ed25519
debug1: Authentication succeeded (publickey).                 | debug1: Next authentication method: keyboard-interactive
Authenticated to x061 ([192.168.129.61]:22).                  | debug1: Authentications that can continue: publickey,password
debug1: channel 0: new [client-session]                       | debug1: Next authentication method: password
debug1: Requesting [email protected]               | padmin@x061's password:
debug1: Entering interactive session.                         |
    
por 25.11.2016 / 13:21

Tags