Fix matching of pubkeys to key algorithms #607
Conversation
Allow all configured key algorithms for pubkey authentication, even if these algorithms are not supported as host key algorithms by the server. Preference is given to the modern rsa-sha2-* signature algorithms if the server indicates support for them as host keys signature algorithms.
|
Is this according to the RFC? This code was changed pretty recently and I think I then interpreted the RFC correctly. But I might be mistaken of course. |
I am quite sure that pubkey algorithms are not negotiated, only host key algorithms are. There is an extension with which the server can announce support for pubkey types though which could be more reliable than the rough feature detection implemented here based on the host key type. |
|
I face exactly this issue. Authentication happens over an ed25519 key but for signature the server only provides rsa, which will not work with the current implementation |
|
@moritz31 If possible, could you check whether the issue you are facing is resolved by my PR? |
src/main/java/net/schmizz/sshj/transport/NegotiatedAlgorithms.java
Outdated
Show resolved
Hide resolved
|
I'll make a minor improvement to the tests. |
Nvm, everything is fine. It should just be noted that the SSH server in the docker image should not add both |
|
The flaky part seems to be the build step, not the integration test step. But everything passed now. |
|
yes, the plugins repository was throwing 500 errors... |
…-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.
…742) * Improve SshdContainer: log `docker build` to stdout, don't wait too long if container exited * Fix #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 #607. * Introduce ConfigImpl.prioritizeSshRsaKeyAlgorithm to deal with broken backward compatibility Co-authored-by: Jeroen van Erp <[email protected]>
…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)
Allow all configured key algorithms for pubkey authentication, even if
these algorithms are not supported as host key algorithms by the
server.
Preference is given to the modern rsa-sha2-* signature algorithms if
the server indicates support for them as host keys signature
algorithms.
Should fix #600.