Server accepts key: pkalg rsa-sha2-512 vs ssh-rsa

[Douglas E Engert]

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 at gmail.com>