Bonjour Tous,
Est-ce quelqu’un a remarqué qu’une mise à jour récente d’OpenSSH sur Debian 12 (durant les 2/3 derniers mois) a littéralement torpillé les connexions depuis des vieux SSH (Debian 4, oui je sais, mais on fait pas toujours ce qu’on veut sur du legacy) et a torpillé les connexions avec auth par pubkey depuis Debian8 ?
J’ai un peu de mal à comprendre ce qui bloque pour Debian8, qqun a compris ?
Pour Debian4, je crois que je vais m’assoir dessus, ça semble être la négociation du kex alg qui foire, mais les messages sont peu lisibles (mais si qqun a une idée, je suis preneur).
Merci
PS: je précise que je n’ai pas la main sur le serveur qui a mis à jour la Debian 12, il s’agit de serveurs de backup chez Ikoula.
David
Bonjour,
David Ponzone, le mar. 03 sept. 2024 14:13:11 +0200, a ecrit:
Est-ce quelqu’un a remarqué qu’une mise à jour récente d’OpenSSH sur Debian 12 (durant les 2/3 derniers mois) a littéralement torpillé les connexions depuis des vieux SSH (Debian 4, oui je sais, mais on fait pas toujours ce qu’on veut sur du legacy) et a torpillé les connexions avec auth par pubkey depuis Debian8 ?
Oui, c'est documenté dans le fichier /usr/share/doc/openssh-client/NEWS.Debian.gz
OpenSSH 8.8 includes a number of changes that may affect existing configurations:
* This release disables RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for <USD$50K.
For most users, this change should be invisible and there is no need to replace ssh-rsa keys. OpenSSH has supported RFC8332 RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys will automatically use the stronger algorithm where possible.
Incompatibility is more likely when connecting to older SSH implementations that have not been upgraded or have not closely tracked improvements in the SSH protocol. For these cases, it may be necessary to selectively re-enable RSA/SHA1 to allow connection and/or user authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms options. For example, the following stanza in ~/.ssh/config will enable RSA/SHA1 for host and user authentication for a single destination host:
Host old-host HostkeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa
We recommend enabling RSA/SHA1 only as a stopgap measure until legacy implementations can be upgraded or reconfigured with another key type (such as ECDSA or Ed25519).
OpenSSH 9.8p1 includes a number of changes that may affect existing configurations:
* DSA keys, as specified in the SSH protocol, are inherently weak: they are limited to 160-bit private keys and the SHA-1 digest. The SSH implementation provided by the openssh-client and openssh-server packages has disabled support for DSA keys by default since OpenSSH 7.0p1 in 2015, released with Debian 9 ("stretch"), although it could still be enabled using the HostKeyAlgorithms and PubkeyAcceptedAlgorithms configuration options for host and user keys respectively.
The only remaining uses of DSA at this point should be connecting to some very old devices. For all other purposes, the other key types supported by OpenSSH (RSA, ECDSA, and Ed25519) are superior.
As of OpenSSH 9.8p1, DSA keys are no longer supported even with the above configuration options. If you have a device that you can only connect to using DSA, then you can use the ssh1 command provided by the openssh-client-ssh1 package to do so.
Samuel
Ca colle pas: le serveur est en OpenSSH_9.2p1 Debian-2+deb12u3. OpenSSH 9.8p1 est dans testing, donc Debian13. Et Debian 11 a fini en OpenSSH 8.4. Ou alors ils ont fait une mise à jour 11->12 y a une semaine, et donc OpenSSH a passé la 8.8
Ceci dit, ça remarche depuis la Debian8 (OpenSSH 6.7p1-5), soit à cause de mon ticket au support soit à cause de mon post ici.
Merci pour le retour en tout cas
David
Le 3 sept. 2024 à 14:25, Samuel Thibault samuel.thibault@ens-lyon.org a écrit :
Bonjour,
David Ponzone, le mar. 03 sept. 2024 14:13:11 +0200, a ecrit:
Est-ce quelqu’un a remarqué qu’une mise à jour récente d’OpenSSH sur Debian 12 (durant les 2/3 derniers mois) a littéralement torpillé les connexions depuis des vieux SSH (Debian 4, oui je sais, mais on fait pas toujours ce qu’on veut sur du legacy) et a torpillé les connexions avec auth par pubkey depuis Debian8 ?
Oui, c'est documenté dans le fichier /usr/share/doc/openssh-client/NEWS.Debian.gz
OpenSSH 8.8 includes a number of changes that may affect existing configurations:
This release disables RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for <USD$50K.
For most users, this change should be invisible and there is no need to replace ssh-rsa keys. OpenSSH has supported RFC8332 RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys will automatically use the stronger algorithm where possible.
Incompatibility is more likely when connecting to older SSH implementations that have not been upgraded or have not closely tracked improvements in the SSH protocol. For these cases, it may be necessary to selectively re-enable RSA/SHA1 to allow connection and/or user authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms options. For example, the following stanza in ~/.ssh/config will enable RSA/SHA1 for host and user authentication for a single destination host:
Host old-host HostkeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsaWe recommend enabling RSA/SHA1 only as a stopgap measure until legacy implementations can be upgraded or reconfigured with another key type (such as ECDSA or Ed25519).
OpenSSH 9.8p1 includes a number of changes that may affect existing configurations:
DSA keys, as specified in the SSH protocol, are inherently weak: they are limited to 160-bit private keys and the SHA-1 digest. The SSH implementation provided by the openssh-client and openssh-server packages has disabled support for DSA keys by default since OpenSSH 7.0p1 in 2015, released with Debian 9 ("stretch"), although it could still be enabled using the HostKeyAlgorithms and PubkeyAcceptedAlgorithms configuration options for host and user keys respectively.
The only remaining uses of DSA at this point should be connecting to some very old devices. For all other purposes, the other key types supported by OpenSSH (RSA, ECDSA, and Ed25519) are superior.
As of OpenSSH 9.8p1, DSA keys are no longer supported even with the above configuration options. If you have a device that you can only connect to using DSA, then you can use the ssh1 command provided by the openssh-client-ssh1 package to do so.
Samuel
Cela me fait penser à un classique lors de connexions à des switch cisco ou à des BMC.
Pour une BMC HP (ilo3).
kexalgorithms diffie-hellman-group1-sha1,diffie-hellman-group14-sha1 hostkeyalgorithms +ssh-dss
Pour d'anciens switch cisco il faut carrément activer DES
ciphers=+3des-cbc
Même pour se connecter à une RHEL6 il faut autoriser les signatures DSA du côté client.
hostkeyalgorithms +ssh-dss
C'est probablement quelque chose de comparable, n'est-ce pas ?
Oui, si c’était le client en version supérieure, mais là, c’est l’inverse: je maitrise le client qui est outdated, et ils ont dû mettre à jour le serveur sans trop réfléchir (=anticiper les vieux clients qui se baladent et qui sont pas simples à mettre à jour).
David
Le 3 sept. 2024 à 14:32, Pierre-Philipp Braun pbraun@nethence.com a écrit :
Cela me fait penser à un classique lors de connexions à des switch cisco ou à des BMC.
Pour une BMC HP (ilo3).
kexalgorithms diffie-hellman-group1-sha1,diffie-hellman-group14-sha1 hostkeyalgorithms +ssh-dssPour d'anciens switch cisco il faut carrément activer DES
ciphers=+3des-cbc
Même pour se connecter à une RHEL6 il faut autoriser les signatures DSA du côté client.
hostkeyalgorithms +ssh-dss
C'est probablement quelque chose de comparable, n'est-ce pas ?
-- Pierre-Philipp Braun
On 9/3/24 15:13, David Ponzone wrote:
Bonjour Tous, Est-ce quelqu’un a remarqué qu’une mise à jour récente d’OpenSSH sur Debian 12 (durant les 2/3 derniers mois) a littéralement torpillé les connexions depuis des vieux SSH (Debian 4, oui je sais, mais on fait pas toujours ce qu’on veut sur du legacy) et a torpillé les connexions avec auth par pubkey depuis Debian8 ? J’ai un peu de mal à comprendre ce qui bloque pour Debian8, qqun a compris ? Pour Debian4, je crois que je vais m’assoir dessus, ça semble être la négociation du kex alg qui foire, mais les messages sont peu lisibles (mais si qqun a une idée, je suis preneur). Merci PS: je précise que je n’ai pas la main sur le serveur qui a mis à jour la Debian 12, il s’agit de serveurs de backup chez Ikoula. David _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
ça me rappelle le problème que j'ai eu l'année dernière sur ubuntu.
Je ne pouvais plus me loguer sur de vieux serveurs parce que la clé rsa (qui reste sécure, pas d'inquietude) était hashée en sha1.
une confusion viens de ce que l'algo sha1 utilisé s'appelle "ssh-rsa"dans les fichiers de conf.
désormais le client n'accepte plus les vieux host qui signent comme ça.
Le mieux serait de mettre à jour tes vieux serveurs. Mais sinon, met ça dans ta conf client :
PubkeyAcceptedKeyTypes +ssh-rsa HostKeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa
my 2 cents....
Le 03/09/2024 à 15:02, David Ponzone a écrit :
Oui, si c’était le client en version supérieure, mais là, c’est l’inverse: je maitrise le client qui est outdated, et ils ont dû mettre à jour le serveur sans trop réfléchir (=anticiper les vieux clients qui se baladent et qui sont pas simples à mettre à jour).
David
Le 3 sept. 2024 à 14:32, Pierre-Philipp Braunpbraun@nethence.com a écrit :
Cela me fait penser à un classique lors de connexions à des switch cisco ou à des BMC.
Pour une BMC HP (ilo3).
kexalgorithms diffie-hellman-group1-sha1,diffie-hellman-group14-sha1 hostkeyalgorithms +ssh-dssPour d'anciens switch cisco il faut carrément activer DES
ciphers=+3des-cbc
Même pour se connecter à une RHEL6 il faut autoriser les signatures DSA du côté client.
hostkeyalgorithms +ssh-dss
C'est probablement quelque chose de comparable, n'est-ce pas ?
-- Pierre-Philipp Braun
On 9/3/24 15:13, David Ponzone wrote:
Bonjour Tous, Est-ce quelqu’un a remarqué qu’une mise à jour récente d’OpenSSH sur Debian 12 (durant les 2/3 derniers mois) a littéralement torpillé les connexions depuis des vieux SSH (Debian 4, oui je sais, mais on fait pas toujours ce qu’on veut sur du legacy) et a torpillé les connexions avec auth par pubkey depuis Debian8 ? J’ai un peu de mal à comprendre ce qui bloque pour Debian8, qqun a compris ? Pour Debian4, je crois que je vais m’assoir dessus, ça semble être la négociation du kex alg qui foire, mais les messages sont peu lisibles (mais si qqun a une idée, je suis preneur). Merci PS: je précise que je n’ai pas la main sur le serveur qui a mis à jour la Debian 12, il s’agit de serveurs de backup chez Ikoula. David _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Liste de diffusion du %(real_name)s http://www.frsag.org/
Je complète mon poste précédent avec un article à lire
https://levelup.gitconnected.com/demystifying-ssh-rsa-in-openssh-deprecation...
Le 03/09/2024 à 15:23, Pierre Colombier via FRsAG a écrit :
ça me rappelle le problème que j'ai eu l'année dernière sur ubuntu.
Je ne pouvais plus me loguer sur de vieux serveurs parce que la clé rsa (qui reste sécure, pas d'inquietude) était hashée en sha1.
une confusion viens de ce que l'algo sha1 utilisé s'appelle "ssh-rsa"dans les fichiers de conf.
désormais le client n'accepte plus les vieux host qui signent comme ça.
Le mieux serait de mettre à jour tes vieux serveurs. Mais sinon, met ça dans ta conf client :
PubkeyAcceptedKeyTypes +ssh-rsa HostKeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa
my 2 cents....
Le 03/09/2024 à 15:02, David Ponzone a écrit :
Oui, si c’était le client en version supérieure, mais là, c’est l’inverse: je maitrise le client qui est outdated, et ils ont dû mettre à jour le serveur sans trop réfléchir (=anticiper les vieux clients qui se baladent et qui sont pas simples à mettre à jour).
David
Le 3 sept. 2024 à 14:32, Pierre-Philipp Braunpbraun@nethence.com a écrit :
Cela me fait penser à un classique lors de connexions à des switch cisco ou à des BMC.
Pour une BMC HP (ilo3).
kexalgorithms diffie-hellman-group1-sha1,diffie-hellman-group14-sha1 hostkeyalgorithms +ssh-dssPour d'anciens switch cisco il faut carrément activer DES
ciphers=+3des-cbc
Même pour se connecter à une RHEL6 il faut autoriser les signatures DSA du côté client.
hostkeyalgorithms +ssh-dss
C'est probablement quelque chose de comparable, n'est-ce pas ?
-- Pierre-Philipp Braun
On 9/3/24 15:13, David Ponzone wrote:
Bonjour Tous, Est-ce quelqu’un a remarqué qu’une mise à jour récente d’OpenSSH sur Debian 12 (durant les 2/3 derniers mois) a littéralement torpillé les connexions depuis des vieux SSH (Debian 4, oui je sais, mais on fait pas toujours ce qu’on veut sur du legacy) et a torpillé les connexions avec auth par pubkey depuis Debian8 ? J’ai un peu de mal à comprendre ce qui bloque pour Debian8, qqun a compris ? Pour Debian4, je crois que je vais m’assoir dessus, ça semble être la négociation du kex alg qui foire, mais les messages sont peu lisibles (mais si qqun a une idée, je suis preneur). Merci PS: je précise que je n’ai pas la main sur le serveur qui a mis à jour la Debian 12, il s’agit de serveurs de backup chez Ikoula. David _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Liste de diffusion du %(real_name)s http://www.frsag.org/
Liste de diffusion du %(real_name)s http://www.frsag.org/
Je reprends tes 2 cents, parce que moi c’est le serveur qui est trop à jour. Mon client n’a pas changé et supporte toujours sha1 :) Ceci dit, sur ma Debian8, le problème était plus complexe car mes clés (pubkey et host) étaient déjà en SHA256. Et ça s’est mis à marcher toute à l’heure, donc Ikoula a modifié un truc. Ma hostkey était de 2048 bits, ils avaient peut-être forcé à 4096 minimum.
Je crois que je n’aurais jamais le fin mot de l’histoire….
David
Le 3 sept. 2024 à 15:23, Pierre Colombier via FRsAG frsag@frsag.org a écrit :
ça me rappelle le problème que j'ai eu l'année dernière sur ubuntu.
Je ne pouvais plus me loguer sur de vieux serveurs parce que la clé rsa (qui reste sécure, pas d'inquietude) était hashée en sha1.
une confusion viens de ce que l'algo sha1 utilisé s'appelle "ssh-rsa"dans les fichiers de conf.
désormais le client n'accepte plus les vieux host qui signent comme ça.
Le mieux serait de mettre à jour tes vieux serveurs. Mais sinon, met ça dans ta conf client :
PubkeyAcceptedKeyTypes +ssh-rsa HostKeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa
my 2 cents....
Le 03/09/2024 à 15:02, David Ponzone a écrit :
Oui, si c’était le client en version supérieure, mais là, c’est l’inverse: je maitrise le client qui est outdated, et ils ont dû mettre à jour le serveur sans trop réfléchir (=anticiper les vieux clients qui se baladent et qui sont pas simples à mettre à jour).
David
Le 3 sept. 2024 à 14:32, Pierre-Philipp Braun pbraun@nethence.com mailto:pbraun@nethence.com a écrit :
Cela me fait penser à un classique lors de connexions à des switch cisco ou à des BMC.
Pour une BMC HP (ilo3).
kexalgorithms diffie-hellman-group1-sha1,diffie-hellman-group14-sha1 hostkeyalgorithms +ssh-dssPour d'anciens switch cisco il faut carrément activer DES
ciphers=+3des-cbc
Même pour se connecter à une RHEL6 il faut autoriser les signatures DSA du côté client.
hostkeyalgorithms +ssh-dss
C'est probablement quelque chose de comparable, n'est-ce pas ?
-- Pierre-Philipp Braun
On 9/3/24 15:13, David Ponzone wrote:
Bonjour Tous, Est-ce quelqu’un a remarqué qu’une mise à jour récente d’OpenSSH sur Debian 12 (durant les 2/3 derniers mois) a littéralement torpillé les connexions depuis des vieux SSH (Debian 4, oui je sais, mais on fait pas toujours ce qu’on veut sur du legacy) et a torpillé les connexions avec auth par pubkey depuis Debian8 ? J’ai un peu de mal à comprendre ce qui bloque pour Debian8, qqun a compris ? Pour Debian4, je crois que je vais m’assoir dessus, ça semble être la négociation du kex alg qui foire, mais les messages sont peu lisibles (mais si qqun a une idée, je suis preneur). Merci PS: je précise que je n’ai pas la main sur le serveur qui a mis à jour la Debian 12, il s’agit de serveurs de backup chez Ikoula. David _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ http://www.frsag.org/
Liste de diffusion du %(real_name)s http://www.frsag.org/ http://www.frsag.org/_______________________________________________
Liste de diffusion du %(real_name)s http://www.frsag.org/
David Ponzone david.ponzone@gmail.com wrote on 03/09/2024 at 14:13:11+0200:
(Debian 4, oui je sais, mais on fait pas toujours ce qu’on veut sur du legacy)
Oui, effectivement, si Debian 4 est critique, il faudra sans doute renoncer aux backups à un moment.
Ben je vais je pense monter un serveur interne en Debian 9 ou 10, qui fera l’intermédiaire…
David
Le 3 sept. 2024 à 15:31, Pierre-Elliott Bécue becue@crans.org a écrit :
David Ponzone david.ponzone@gmail.com wrote on 03/09/2024 at 14:13:11+0200:
(Debian 4, oui je sais, mais on fait pas toujours ce qu’on veut sur du legacy)
Oui, effectivement, si Debian 4 est critique, il faudra sans doute renoncer aux backups à un moment.
-- PEB _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
David Ponzone david.ponzone@gmail.com wrote on 03/09/2024 at 16:14:28+0200:
Ben je vais je pense monter un serveur interne en Debian 9 ou 10, qui fera l’intermédiaire…
Si tu as le sto pour utiliser un serveur intermédiaire, c'est en effet une option.
-
David Ponzone -
Pierre Colombier -
Pierre-Elliott Bécue -
Pierre-Philipp Braun -
Samuel Thibault