jtesta
Deprecation of ssh-rsa in OpenSSH
In February 2020, OpenSSH issued a "Future Deprecation Notice" of the ssh-rsa algorithm, see https://www.openssh.com/txt/release-8.2.
Then in August 2021, OpenSSH raised this to an "Imminent Deprecation Notice", see https://www.openssh.com/txt/release-8.7.
Finally in September 2021, OpenSSH disabled the use of ssh-rsa by default, see https://www.openssh.com/txt/release-8.8.
@jtesta - I can submit a PR to replace the existing INFO_OPENSSH82_FUTURE_DEPRECATION in kexdb.py but should I also raise the severity from information to warning or failure, or just leave it as information?
@jtesta Hi Joe, sorry to chase...
I'm happy to submit the PR for this myself but before doing so just wanted to get your opinion on this:
should I also raise the severity from information to warning or failure, or just leave it as information?
@thecliguy : correct me if I'm wrong, but I think the driving factor for deprecating ssh-rsa is solely because it is built around SHA-1. SHA-1 is exploitable in host keys, hence we already mark it as a failure (see here).
Marking algorithms as failing simply because it has another failing reason doesn't seem to make sense. I'd be happy to add another real failure reason if it exists, though.
@jtesta: That's correct, the reason ssh-rsa (as a signature algorithm) was gradually phased out and then eventually disabled in OpenSSH is due to its dependence on sha-1. So I take your point, treating the OpenSSH stance on ssh-rsa as a failure isn't needed since the rationale behind that decision is already covered by the failure message "using weak hashing algorithm".
We need to replace INFO_OPENSSH82_FUTURE_DEPRECATION with some updated text explaning that ssh-rsa is now disabled by default in OpenSSH 8.8.
All existing algorithm commentary where an algorithm has been disabled is currently treated as either a failure or a warning (never as information). So, once the text has been rewritten, should it be raised from information to warning, to be consistent?
@thecliguy: yes, replacing INFO_OPENSSH82_FUTURE_DEPRECATION with something like INFO_DEPRECATED_IN_OPENSSH88 would be a good idea.
Replacing the indirect failures messages (like FAIL_OPENSSH61_REMOVE) with the direct reasons for failure (like FAIL_HASH_WEAK or something specific) would also be a good idea. Then the current failures can be downgraded to informational (i.e.: FAIL_OPENSSH61_REMOVE -> INFO_REMOVED_FROM_OPENSSH61).
@jtesta Thanks for accepting PR #171 to replace INFO_OPENSSH82_FUTURE_DEPRECATION with INFO_DEPRECATED_IN_OPENSSH88.
You suggested updating all indirect failure messages to acheive consistency...
Replacing the indirect failures messages (like FAIL_OPENSSH61_REMOVE) with the direct reasons for failure (like FAIL_HASH_WEAK or something specific) would also be a good idea. Then the current failures can be downgraded to informational (i.e.: FAIL_OPENSSH61_REMOVE -> INFO_REMOVED_FROM_OPENSSH61).
... I'm not going to have time to work on this myself (not anyime soon), so do you want to want to leave this ticket open, or are you happy for it to be closed since the original intent has now been actioned?
@thecliguy : I finished the rest of the updates in https://github.com/jtesta/ssh-audit/commit/cc9e4fbc4ab06a90e1763e20dd3b4571e2934bb6. Thanks again for helping with this!