[
https://issues.apache.org/jira/browse/SSHD-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16019903#comment-16019903
]
ASF GitHub Bot commented on SSHD-642:
-------------------------------------
Github user jonnyzzz closed the pull request at:
https://github.com/apache/mina-sshd/pull/24
> Pad RSA signatures with zeroes if necessary to complete the expected
> signature size
> -----------------------------------------------------------------------------------
>
> Key: SSHD-642
> URL: https://issues.apache.org/jira/browse/SSHD-642
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 1.0.0
> Reporter: Eugene Petrenko
> Fix For: 1.2.0
>
>
> This issue I observe with quite low probability. It turns out that RSA
> signature verification fails and thus SSH key authentication fails. (This is
> a bit strange that key verification is executed BEFORE signature is checked).
> In my cases it fails with Trilead SSH2 client.
> From the code it fails inside JCE where it is asserted message size if not
> trimmed. (Exception is not getting properly logged, but it is possible to
> find the message in sun/security/rsa/RSASignature.java file)
> In the sources of Trilead I see the code, that may trim leading zero byte
> from the signature. Signature here is encoded with type and data, so that
> org.apache.sshd.common.signature.AbstractSignature#extractEncodedSignature is
> executed and not-null is returned).
> https://github.com/JetBrains/intellij-community/blob/master/plugins/cvs/trilead-ssh2-build213/src/com/trilead/ssh2/signature/RSASHA1Verify.java#L98
> As you may see from the link this is the way they understand the standard.
> I checked JSch code, and there is not such a byte trim there.
> It may mean Mina SSHD should attempt to workaround it and add zero bites back
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
