Description of problem: A stable update introduced into Fedora 25 has broken existing, working, connections with older SSH servers. Client: Fedora 25 Host: SLES SP3, OpenSSH_6.2p2 Version-Release number of selected component (if applicable): crypto-policies-20160921-3.gitf3018dd.fc25 Downgrading to crypto-policies-20160921-2.git75b9b04.fc25 and removing /etc/crypto-policies/back-ends/openssh.config allows me to connect to these servers again. The SLES servers cannot be updated (yet) because the systems do not have a support subscription. The SLES systems only support the aes128-ctr cipher during key exchange. With the new crypto-policies file the OpenSSH server/client attempt a aes256-gcm cipher with more Dillie-Hellman bits required and the exchange fails. This is due to a change in the cipher order with the new policy. The old order had "aes128-ctr" first and the server/client negotiated with this cipher and connect successfully. Old order: debug2: ciphers ctos: chacha20-poly1305,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm,aes256-gcm,aes128-cbc,aes192-cbc,aes256-cbc New order: debug2: ciphers ctos: aes256-gcm,chacha20-poly1305,aes256-ctr,aes256-cbc,aes128-gcm,aes128-ctr,aes128-cbc,3des-cbc After noticing this change I investigated the key-exchange and cipher default order (without the crypto-policies file) and the new order with a SSH session between two Fedora systems. Old order: debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1305 MAC: <implicit> compression: zlib debug1: kex: client->server cipher: chacha20-poly1305 MAC: <implicit> compression: zlib debug1: kex: curve25519-sha256 need=64 dh_need=64 debug1: kex: curve25519-sha256 need=64 dh_need=64 New order: debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: aes256-gcm MAC: <implicit> compression: zlib debug1: kex: client->server cipher: aes256-gcm MAC: <implicit> compression: zlib debug1: kex: curve25519-sha256 need=32 dh_need=32 debug1: kex: curve25519-sha256 need=32 dh_need=32 The new policy uses AES vs ChaCha, which some people argue that ChaCha provides faster performance, but I don't have any benchmarks to back that claim up. The update is pretty disruptive for a stable Fedora update. Can we improve compatibility or regain the "old" default order?
OpenSSH in Fedora25 shouldn't use the crypto policies so I am reassigning to openssh (it was an F26 feature). The discussion on chacha vs aes, is a good one and maybe we should bring to the mailing lists. AES-gcm is typically faster on stock hardware (x86/x86_64) than anything else because of the instruction acceleration. Chacha20-poly1305 provides better performance in hardware without that acceleration.
Thanks, Nikos. openssh-clients-7.4p1-2.fc25 /etc/ssh/ssh_config.d/05-redhat.conf: # Follow system-wide Crypto Poliicy, if defined: Include /etc/crypto-policies/back-ends/openssh.config
> The SLES systems only support the aes128-ctr cipher during key exchange. That is weird. You say that it does not allow you to connect, but the cipher is in the offered list: > debug2: ciphers ctos: aes256-gcm,chacha20-poly1305,aes256-ctr,aes256-cbc,aes128-gcm,aes128-ctr,aes128-cbc,3des-cbc Can you provide the full log what is going on there before we will hit that hard in Fedora 26? The policy should not have been generated in Fedora 25. But yes, once we are already here and I will update soon, I will remote this line from the configuration for Fedora 25.
Created attachment 1256209 [details] debug output without crypto-policy This is the debug (ssh -vv) output from a working connection. Sensitive information was removed/obfuscated.
Created attachment 1256210 [details] debug output with crypto-policy Debug output when the crypto-policy is used. A few typos in my original comment. "SLES SP3" => "SLES 11 SP3", "Dille" => "Diffe"...
That is weird. Why do you say that your server supports only aes128-ctr, when even you can see that the server offers aes256-gcm in your log: > debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm,aes256-gcm,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc.se Even weirder is that after selecting this mechanism, the server fails. It will be some bug in SLES. Can you see what errors are in that server when it closes the connection (more out of curiosity)?
crypto-policies-20160921-4.gitf3018dd.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4b60affa45
I've submitted the above fix to remove any openssh policy from F25. It is good practice however for openssh not to include it in F25, so we avoid regressions of backports like this.
crypto-policies-20160921-4.gitf3018dd.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-4b60affa45
(In reply to Jakub Jelen from comment #6) > That is weird. Why do you say that your server supports only aes128-ctr, > when even you can see that the server offers aes256-gcm in your > log: Sure, but the server doesn't support it. Here's an excerpt from the server-side: matching cipher is not supported: aes256-gcm [preauth] > Even weirder is that after selecting this mechanism, the server fails. It > will be some bug in SLES. Can you see what errors are in that server when it > closes the connection (more out of curiosity)? Yes, it could be a bug in SLES. SLES 11 SP4 systems, fully updated, do not have connection issues with the crypto-policies policy. Here's another case of a different software breaking against these servers: https://trac.filezilla-project.org/ticket/10962 Based on FileZilla's investigation the underlying OpenSSL version may not support using the cipher and should not even offer the cipher. I guess it is up to Niko if he would prefer a cipher order that is compatible with these "broken" servers, and similar to the default OpenSSH order, or stay with his current order.
crypto-policies-20160921-4.gitf3018dd.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This was fixed ages ago.