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

9

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

Fonctionne - ressemble à ceci:

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

Ne fonctionne pas ressemble à:

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

Qu'est ce qui a changé?

openssh Michael Felt
la source
2
Chaque fois que je mets à niveau ou reconfigure SSH, j'essaye généralement d'ouvrir immédiatement une autre connexion SSH tout en laissant la connexion actuelle ouverte pour le débogage. Cette approche aiderait au débogage dans des scénarios comme le vôtre. Avez-vous toujours accès au serveur? Ou essayez-vous de déboguer cela du côté client sans accès pour consulter les journaux côté serveur jusqu'à ce que vous ayez résolu le problème?
kasperd
1
Heureusement, j'ai toujours eu accès au serveur. Généralement, lorsque j'applique des mises à jour, j'essaie d'être «sur la console» - pour des raisons comme vous le mentionnez. Ce que j'ai essayé de montrer ici, c'est comment déboguer quand cela fonctionne pour certains (par exemple, un mastic récent), mais pas pour d'autres (par exemple, un client ssh de 14 ans qui ne connaît pas des algorithmes de chiffrement, kex et mac améliorés.
Michael Felt

Réponses:

14

Après une mise à jour - des 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 de ne pas se soucier de la compatibilité descendante. Cela peut «casser» des choses qui, selon ce que l'on lit, fonctionnent bien.

Il y a un indice massif - que je n'ai pas remarqué quand cela m'est arrivé pour la première fois (en utilisant l'interface graphique, et je l'ai juste cliqué et 'j'étais en colère' avec 'mise à jour stupide - la nouvelle version est cassée'. Il s'avère que la nouvelle version n'a pas été cassé - mais OpenBSD / OpenSSH a commencé à changer les valeurs par défaut d'échange de clés à partir d'OpenSSH-6.7p1 voir: http://www.openssh.com/txt/release-6.7 , notamment:

Changements depuis OpenSSH 6.6

Modifications potentiellement incompatibles

  • sshd (8): l'ensemble de chiffrements et MAC par défaut a été modifié pour
    supprimer les algorithmes dangereux. En particulier, les chiffres CBC et arcfour *
    sont désactivés par défaut.

    L'ensemble complet d'algorithmes reste disponible s'il est configuré de manière
    explicite via les options de chiffrement et MAC sshd_config.

Mon problème est que j'ai un ancien client qui n'a aucun des nouveaux paramètres par défaut, donc il ne peut pas se connecter.

Deux chemins de solution: réparer / patcher le serveur ou - réparer / patcher le client.

Solution serveur: restaurez les "anciens" paramètres pour que les "anciens" clients puissent continuer à se connecter, c'est-à-dire - conviviaux pour les clients existants - modifiez le fichier sshd_config et rajoutez (suffisamment) des anciens chiffrements.

Les lignes clés à modifier / ajouter dans sshd_config étant:

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

Ajoutez simplement:

# 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

Solution # 2 - Réparer / remplacer le client

Un moyen facile de voir quels chiffrements votre client actuel prend en charge (en supposant que CLI) est ssh -het de voir 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,[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

Une autre commande utile est: ssh -V

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

Le mien - était - un très vieux client - pour mon bureau. En regardant ci-dessus, vous pouvez voir qu'il ne prend en charge aucun des algorithmes préférés - 15 ans plus tard, pas même un -cbr (rotation), seulement -cbc (copie de bloc).

Si votre client n'a pas d'option pour fournir les clés, etc. pris en charge (OpenSSH devrait avoir l'option -Q), il suffit de démarrer une connexion avec vous-même, par exemple, ssh -v localhostet il y a des lignes comme celle-ci 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: [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]
...

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 débogage d'une connexion ayant échoué - 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 : [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.

Modifier: ajouté le 2 janvier 2017

Nouvelle section - qu'en est-il des touches qui ne fonctionnent plus?

Sur mon serveur, j'ai un «ancien» client et le «dernier» client installé - et j'ai un comportement différent lors de la connexion à un serveur. Ici, le problème n'est pas lié aux erreurs de chiffrement - mais à l'utilisation d'une paire PKI archaïque - basée sur DSA.

En bref, openssh-7 (.3) n'envoie plus (par défaut, peut-être pas du tout) de clés 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, côté droit) - la commande est:

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

En parcourant la sortie ci-dessous, j'espère que vous remarquerez que les étapes et les messages sont généralement les mêmes. La principale différence vient après la chaîne SSH2_MSG_SERVICE_ACCEPT

Ce que je veux que vous remarquiez, c'est que l'ancienne version offre (et est acceptée par l '«ancien» serveur - la paire de clés basée sur DSA tandis que le nouveau serveur n'offre jamais la clé basée sur DSA.

Remarque: la `` solution '' consiste à ajouter (au moins une des) 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 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.                         |
Michael Felt
la source
J'avais aussi des utilisateurs ici qui se plaignaient de clés avec des protocoles obsolètes au moment où je suis passé à Debian 8.
Rui F Ribeiro
1
J'ai oublié de mentionner - que pour mes fenêtres, je suis passé au mastic (ssh.com ne vend qu'aux entreprises) - serait resté ssh2s'ils m'auraient accepté - principalement pour la facilité de faire des scptransferts à partir de la même fenêtre quessh
Michael Felt
1
Mettez à jour votre client au lieu d'utiliser des clients anciens et d'activer des algorithmes éventuellement cassés.
Jakuje
1
Voir Mettre à niveau vos clés SSH! pour plus de détails, mais comme le dit @Jakuje, c'est une mauvaise idée de conserver les anciennes clés, les anciens clients et les anciens algorithmes.
Stephen Kitt
l'âge de la clé n'est pas un problème, à mon humble avis - mais le type et la taille. "DSA" est sorti, "RSA" au moins 2048 bits. «Mieux» est ecdsa. Comme @Jakuje le mentionne - et de quoi traite cette Q&R - mettre à jour les clients - mais aussi mettre à jour les valeurs par défaut. En tant que client, vous pouvez «exiger» qu'un serveur utilise de meilleurs algorithmes en n'en proposant pas de plus faibles (moins bons).
Michael Felt,