SSH a cessé de fonctionner après une mise à jour du server? Qu'est-il arrivé?

J'utilise des connections SSH basées sur PKI depuis plus de 10 ans. Soudain, après une mise à jour du server – certaines connections ont cessé de fonctionner. J'utilise les mêmes keys PKI que j'ai utilisées depuis des années (chaque server a ses propres keys, j'ai un petit jeu de keys personnelles).

Travailler – ressemble à ceci:

C:\Users\michael>ssh2 -p 2222 root@192.168.129.64 date Authentication successful. Fri Nov 25 10:30:42 2016 

Ne fonctionne pas ressemble à:

 C:\Users\michael>ssh2 root@192.168.129.64 date warning: Authentication failed. Disconnected; key exchange or algorithm negotiation failed (Algorithm negotiation failed.). 

Qu'est ce qui a changé?

FYI: c'est un Q & A – où je réponds à la question, d'autres sont les bienvenus – j'aime apprendre (ce que j'ai manqué)! J'espère que cela augmentera votre compréhension de la façon dont openssh se connecte et / ou comment déboguer les problèmes de connection openssh

Après une mise à jour – les effets secondaires peuvent entrer en jeu. Avec OpenSSH – les valeurs par défaut changent fréquemment. OpenBSD (qui maintient / développe OpenSSH) a une politique d'OpenBSD pour ne pas se préoccuper de la rétrocompatibilité. Cela peut «casser» les choses qui sont, lire étaient, fonctionnaient bien.

Il y a un indice énorme – que je n'ai pas remarqué quand cela m'est arrivé pour la première fois (en utilisant l'interface graphique, je l'ai simplement cliqué et «fâché» avec «mise à jour stupide – nouvelle version est cassée». n'était pas cassé – mais OpenBSH / OpenSSH commençant à changer les valeurs par défaut de l'échange de keys en commençant par OpenSSH-6.7p1 voir: http://www.openssh.com/txt/release-6.7 , notablement:

Changements depuis OpenSSH 6.6

Changements potentiellement incompatibles

  • sshd (8): L'set de numbers et de MAC par défaut a été modifié pour
    supprimer les algorithms dangereux. En particulier, CBC chiffre et arcfour *
    sont désactivés par défaut.

    L'set complet des algorithms rest disponible si configuré
    explicitement via les options sshd_config de Ciphers et MACs.

Mon problème est que j'ai un vieux client qui n'a pas les nouvelles valeurs par défaut, donc il ne peut pas se connecter.

Deux paths de solution: réparer / patcher le server ou – réparer / patcher le client.

Solution server: ramener les anciens parameters afin que les clients «anciens» puissent continuer à se connecter, c'est-à-dire, amicaux avec les clients existants – éditer le file sshd_config et append (assez) les anciens chiffrements.

Les lignes keys à modifier / append dans sshd_config étant:

 ciphers aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305@openssh.com,aes256-cbc KexAlgorithms curve25519-sha256@libssh.org,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 

Ajoutez simplement:

 # Ciphers # The dafaults starting with OpenSSH 6.7 are: # aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305@openssh.com # older clients may need an older cipher, eg # 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,chacha20-poly1305@openssh.com,aes256-cbc # KEX Key Exchange algorithms # default from openssh 6.7 are: # curve25519-sha256@libssh.org,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 curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 # MAC message authentification code # the new defaults are: # umac-64-etm@openssh.com,umac-128-etm@openssh.com, # hmac-sha2-256-etm@openssh.com,hmac-sha2-512- # etm@openssh.com, # umac-64@openssh.com,umac-128@openssh.com, # 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 

Solution # 2 – réparer / replace le client

Un moyen simple de voir ce que vous pouvez utiliser pour le client actuel (en supposant que CLI) est ssh -h et voyez si cela fournit quelque chose comme:

 Supported ciphers: 3des-cbc,aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,twofish-cbc,twofish256-cbc,twofish192-cbc,twofish128-cbc,des-cbc@ssh.com,cast128-cbc,rc2-cbc@ssh.com,arcfour,none Supported MAC algorithms: hmac-md5,hmac-md5-96,hmac-sha1,hmac-sha1-96,hmac-sha256@ssh.com,hmac-sha256-96@ssh.com,hmac-ripemd160@ssh.com,hmac-ripemd160-96@ssh.com,hmac-tiger128@ssh.com,hmac-tiger128-96@ssh.com,hmac-tiger160@ssh.com,hmac-tiger160-96@ssh.com,hmac-tiger192@ssh.com,hmac-tiger192-96@ssh.com,none 

Une autre command utile est: ssh -V

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

Mine – était – un très vieux client – pour mon bureau. En regardant au-dessus, vous pouvez voir qu'il ne supporte aucun des – 15 ans plus tard – algorithms préférés, même pas un -cbr (rotation), seulement -cbc (bloc-copy).

Si votre client n'a pas l'option de fournir les keys, etc. supporté (OpenSSH devrait avoir l'option -Q ), commencez simplement une connection à vous-même, par exemple, ssh -v localhost et il y a des lignes comme ça pour vous dire que wat est connu:

 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: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,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,rijndael-cbc@lysatiu.se ... 

Et ce qui a été trouvé (et utilisé):

 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: informations de debugging d'un échec de connection – plus de détails

Ou, ce qui a été essayé, mais manqué.

 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 : chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com 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 : chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com 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. 

Edit: ajouté 02-jan-2017

Nouvelle section – qu'en est-il des keys qui cessent de fonctionner?

Sur mon server, j'ai un ancien client et le dernier client installé – et j'ai un comportement différent en me connectant à un server. Ici, le problème n'est pas le chiffrage des correspondances erronées – mais l'utilisation d'une paire PKI archaïque – basée sur DSA.

Bref, openssh-7 (.3) n'émet plus (par défaut, peut-être pas du tout) de keys publiques DSA.

Ci-dessous, je compare la sortie de deux versions de openssh
/ usr / bin / ssh (ancienne version, côté gauche) et
/ opt / bin / ssh (nouvelle version, à droite) – la command est:

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

Lorsque vous parcourez la sortie ci-dessous, j'espère que vous remarquerez que les étapes et les messages sont généralement les mêmes. La différence key vient après la string SSH2_MSG_SERVICE_ACCEPT

Ce que je veux que vous remarquiez est que l'ancienne version offre (et est acceptée par le «vieux» server – la paire de keys basée sur DSA alors que le nouveau server n'offre jamais la key basée sur DSA.

Remarque: la solution consiste à append (au less l'une des) les paires PKI basées sur 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 ssortingng SSH-2.0-OpenSSH_6.0 | debug1: Local version ssortingng 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 no-more-sessions@openssh.com | padmin@x061's password: debug1: Entering interactive session. |