The original problem is some smart cards can not sign with SHA2-512.
The release notes OpenSSH_7.3p1 point to:
https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-03
https://tools.ietf.org/html/draft-ssh-ext-info-00
The current drafts (expiring Feb 17, 2017 and March 5, 2017) are:
https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-02
https://tools.ietf.org/html/draft-ietf-curdle-ssh-ext-info-01
The drafts have:
rsa-sha2-256 RECOMMENDED sign Raw RSA key
rsa-sha2-512 OPTIONAL sign Raw RSA key
If some services will only negotiate rsa-sha2-512 that is not in the
spirit if the drafts, that make it optional.
"2.2. Use for client authentication" defines"
"3. Discovery of signature algorithms supported by servers"
and draft-ietf-curdle-ssh-ext-info-01
discuss how a client can negotiate rsa-sha2-256.
Your situation is a perfect example of why rsa-sha2-512
should be optional, and negotiation should be implemented.
It may well be negotiation is implemented but not well tested,
or documented because very few people could support rsa-sha2-256
but not rsa-sha2-512.
Hopefully the drafts may help you determine if OpenSSH implemented
the negotiation.
Have you looked at the ssh_config HostKeyAlgorithms?
It looks like the last entry is ssh-rsa, but the way I read the drafts
this includes all the hashs. You could try and replace with
rsa-sha2-256 or place rsa-sha2-256 before ssh-rsa.
On 1/30/2017 3:58 AM, Jakub Jelen wrote:
On 01/26/2017 09:01 PM, Nuno Gonçalves wrote:
Hi,
I'm doing some test with a pkcs11 token that can only sign short messages.
When connecting to one server, that reports pkalg rsa-sha2-512 blen
151, it fails to sign the pubkey because it is 83 bytes long. (sshd:
OpenSSH_7.3p1)
A older server that reports pkalg ssh-rsa blen 151, works perfectly as
the pubkey signature required is only 35 bytes long. (sshd:
OpenSSH_6.7p1)
I am not sure where does this pkalg fit in the process, and all my
attempts to downgrade the algorithm have failed. Even looking at
identity_sign_encode at sshconnect2.c, doesn't help me at all, as
ssh-rsa is not one option.
So very simply, was this deprecated completely, does the new
implementation not allow the client to downgrade it, or is there any
option for it?
Thanks,
Nuno
This is part of deprecation SHA1 for signatures, which were hardcoded into the core RFCs. The different hashes were introduced in OpenSSH 7.2 [1] and are negotiated using the protocol extension. I
don't think there are configuration options to control this behavior, but the new algorithms have higher priority for new OpenSSH versions.
[1] http://www.openssh.com/txt/release-7.2
Regards,
--
Douglas E. Engert <DEEngert@xxxxxxxxx>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
