Lean on Config.keyAlgorithms choosing between rsa-sha2-* and ssh-rsa #742
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ong if container exited
…-sha2-* and ssh-rsa Previously, there was a heuristic that was choosing rsa-sha2-512 after receiving a host key of type RSA. It didn't work well when a server doesn't have an RSA host key. OpenSSH 8.8 introduced a breaking change: it removed ssh-rsa from the default list of supported public key signature algorithms. SSHJ was unable to connect to OpenSSH 8.8 server if the server has an EcDSA or Ed25519 host key. Current behaviour behaves the same as OpenSSH 8.8 client does. SSHJ doesn't try to determine rsa-sha2-* support on the fly. Instead, it looks only on `Config.getKeyAlgorithms()`, which may or may not contain ssh-rsa and rsa-sha2-* in any order. Sorry, this commit mostly reverts changes from hierynomus#607.
|
Is there anything that should be modified to have it merged? |
|
No, nothing was blocking it, it more just escaped my attention that it wasn't merged yet. Come to think of your starting coimment on this MR, it might be a good idea to add a factory method on DefaultConfig that adds the SSHRSA algorithm above the rest. So that it would be easy to adapt to the change for people. What do you think? |
vladimirlagunov
force-pushed
the
fix-rsa-sha2
branch
from
13b4044 to
592b612
Compare
|
Added |
hierynomus
approved these changes
Dec 6, 2021
|
👍 Thanks! |
vladimirlagunov
added a commit
to vladimirlagunov/sshj
that referenced
this pull request
Jan 21, 2022
…ierynomus#742) * Improve SshdContainer: log `docker build` to stdout, don't wait too long if container exited * Fix hierynomus#740: Lean on Config.keyAlgorithms choosing between rsa-sha2-* and ssh-rsa Previously, there was a heuristic that was choosing rsa-sha2-512 after receiving a host key of type RSA. It didn't work well when a server doesn't have an RSA host key. OpenSSH 8.8 introduced a breaking change: it removed ssh-rsa from the default list of supported public key signature algorithms. SSHJ was unable to connect to OpenSSH 8.8 server if the server has an EcDSA or Ed25519 host key. Current behaviour behaves the same as OpenSSH 8.8 client does. SSHJ doesn't try to determine rsa-sha2-* support on the fly. Instead, it looks only on `Config.getKeyAlgorithms()`, which may or may not contain ssh-rsa and rsa-sha2-* in any order. Sorry, this commit mostly reverts changes from hierynomus#607. * Introduce ConfigImpl.prioritizeSshRsaKeyAlgorithm to deal with broken backward compatibility Co-authored-by: Jeroen van Erp <[email protected]> (cherry picked from commit 624747c)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, there was a heuristic that was choosing rsa-sha2-512 after receiving a host key of type RSA. It didn't work well when a server doesn't have an RSA host key.
OpenSSH 8.8 introduced a breaking change: it removed ssh-rsa from the default list of supported public key signature algorithms. SSHJ was unable to connect to OpenSSH 8.8 server if the server has an EcDSA or Ed25519 host key.
Current behaviour behaves the same as OpenSSH 8.8 client does. SSHJ doesn't try to determine rsa-sha2-* support on the fly. Instead, it looks only on
Config.getKeyAlgorithms(), which may or may not contain ssh-rsa and rsa-sha2-* in any order.Sorry, this commit mostly reverts changes from #607.
Apparently, I tried to find a way to determine if the server supports some key algorithm signature. I haven't found anything related in source code of OpenSSH. So, I decided to implement in SSHJ the same approach as OpenSSH client uses.
Also, if this patch is accepted, better to add a note to the changelog about a backward compatibility breakage. The default config stops working with old servers like Apache SSHD that doesn't support rsa-sha2-* signatures. It is still possible to connect to them, but an instance of DefaultConfig should be modified a bit:
KeyAlgorithms.SSHRSAshould have higher priority than other RSA-related algorithms, which can be done by callingConfig.setKeyAlgorithms.