[
https://issues.apache.org/jira/browse/SSHD-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15143338#comment-15143338
]
Eugene Petrenko commented on SSHD-642:
--------------------------------------
This is quite hard to reproduce. As you may see from the code, it only fails if
first byte of a signature from a public key authentication is zero. The
signature itself is SHA1RSA that depends on public key, user id, and session
random bytes. The only way I see is to brute force to find the combination of a
key and a session id that yields zero at first byte.
Currently I was not sure the bug is in SSHD. This could also be an issue in
Trilead. The probability to have the issue is at least 1/256, which is quite
small to be detected from a local or unit tests.
My idea of a fix was to add leading zeroes to the signature buffer if it size
is not equal to a size of public key (as I see from the RSASignature.java)
{code}
if (sigBytes.length != RSACore.getByteLength(publicKey)) {
throw new SignatureException("Signature length not correct: got " +
sigBytes.length + " but was expecting " +
RSACore.getByteLength(publicKey));
}{code}
I will share my patch once it is ready
> Authentication failed: Signature length not correct: got 255 but was
> expecting 256
> ----------------------------------------------------------------------------------
>
> 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
>
> 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.4#6332)
