Skip to content
This repository has been archived by the owner on Mar 24, 2021. It is now read-only.

Unconditionally filters ciphers #17

Open
duck-rh opened this issue Jun 28, 2019 · 6 comments
Open

Unconditionally filters ciphers #17

duck-rh opened this issue Jun 28, 2019 · 6 comments

Comments

@duck-rh
Copy link
Contributor

duck-rh commented Jun 28, 2019

While I think the new feature is useful, having ciphers locked-up independently of openssh version changes while you did not request for such feature to be enabled, is IMHO a problem.

@mscherer
Copy link
Contributor

mscherer commented Jul 4, 2019

Mhh, i do not understand. Nothing is blocked by default.

@duck-rh
Copy link
Contributor Author

duck-rh commented Jul 4, 2019

generating a list of ciphers while filtering nothing (the default setting) is IMHO useless and means upgrading will never bring better ciphers unless this role is applied at the same time.

@duck-rh
Copy link
Contributor Author

duck-rh commented Sep 9, 2019

In fact upgrading just break the world:

Sep  9 07:33:28 Catton systemd[1]: Starting OpenBSD Secure Shell server...
Sep  9 07:33:28 Catton sshd[4663]: /etc/ssh/sshd_config line 125: Bad SSH2 cipher spec '3des-cbc,blowfish-cbc,cast128-cbc,arcfour,arcfour128,arcfour256,aes128-cbc,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],[email protected]'.
Sep  9 07:33:28 Catton systemd[1]: ssh.service: Control process exited, code=exited, status=255/EXCEPTION

I'd like to be able to disable this feature. As I already said the distro must be fixed and this is gonna be a pain to maintain.

@mscherer
Copy link
Contributor

so, what kind of upgrade was it ?

@mscherer
Copy link
Contributor

So, that's a upgrade from some debian version to another debian version, but so that mean there is a bug. The code is not supposed to change anything unless there is a filtered cipher, and by default, nothing is filtered. If this did result in filtering something (and so changing the configuration) while you didn't ask for it, that's not the behavior that was supposed to happen.

mscherer added a commit to mscherer/ansible-role-openssh that referenced this issue Sep 10, 2019
It seems that "0" != 0, so the configuration is also applied
even when people didn't asked, thus causing trouble on upgrade
(at least on debian, see OSAS#17).
mscherer added a commit to mscherer/ansible-role-openssh that referenced this issue Sep 10, 2019
It seems that "0" != 0, so the configuration is also applied
even when people didn't asked, thus causing trouble on upgrade
(at least on debian, see OSAS#17).
@mscherer mscherer mentioned this issue Sep 10, 2019
@mscherer
Copy link
Contributor

It seems indeed that this was a bug. I guess this broke after 2.8 upgrade, as it was fine when I tested.

duck-rh added a commit that referenced this issue Feb 5, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants