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
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, > NunoThis 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, -- Jakub Jelen Software Engineer Security Technologies Red Hat
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>
Nuno Gonçalves
2017-Feb-12 14:46 UTC
Fwd: Server accepts key: pkalg rsa-sha2-512 vs ssh-rsa
On 1/30/2017 3:58 AM, Jakub Jelen wrote:> 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,In that case this is converted to a bug report: Deprecation of SHA1 is not being enforced since 7.4p1. The side effect of this bug is that my "problem" originally reported disappeared from 7.3p1 to 7.4p1. It was fixed by properly supporting rsa-sha2-256 from OpenSC (my pkcs11 lib) side, but during tests we found out that 7.4p1 was not using rsa-sha2-256 anymore. Bug was introduced with commit: https://github.com/openssh/openssh-portable/commit/130f5df4fa37cace8c079dccb690e5cafbf00751. Due to: https://bugzilla.mindrot.org/show_bug.cgi?id=2547>From this commit rsa-sha2-256 and rsa-sha2-512 are no longer offeredso all is downgraded to rsa-sha. A fix applied at current master could be: diff --git a/kex.c b/kex.c index a30dabe..13bb9aa 100644 --- a/kex.c +++ b/kex.c @@ -348,7 +348,7 @@ kex_send_ext_info(struct ssh *ssh) int r; char *algs; - if ((algs = sshkey_alg_list(0, 1, ',')) == NULL) + if ((algs = sshkey_alg_list(0, 1, 1, ',')) == NULL) return SSH_ERR_ALLOC_FAIL; if ((r = sshpkt_start(ssh, SSH2_MSG_EXT_INFO)) != 0 || (r = sshpkt_put_u32(ssh, 1)) != 0 || diff --git a/ssh.c b/ssh.c index ee0b16d..edef335 100644 --- a/ssh.c +++ b/ssh.c @@ -684,11 +684,11 @@ main(int ac, char **av) else if (strcmp(optarg, "kex") == 0) cp = kex_alg_list('\n'); else if (strcmp(optarg, "key") == 0) - cp = sshkey_alg_list(0, 0, '\n'); + cp = sshkey_alg_list(0, 0, 0, '\n'); else if (strcmp(optarg, "key-cert") == 0) - cp = sshkey_alg_list(1, 0, '\n'); + cp = sshkey_alg_list(1, 0, 0, '\n'); else if (strcmp(optarg, "key-plain") == 0) - cp = sshkey_alg_list(0, 1, '\n'); + cp = sshkey_alg_list(0, 1, 0, '\n'); else if (strcmp(optarg, "protocol-version") == 0) { #ifdef WITH_SSH1 cp = xstrdup("1\n2"); diff --git a/sshkey.c b/sshkey.c index 31710e5..1c5dfdb 100644 --- a/sshkey.c +++ b/sshkey.c @@ -195,14 +195,16 @@ sshkey_ecdsa_nid_from_name(const char *name) } char * -sshkey_alg_list(int certs_only, int plain_only, char sep) +sshkey_alg_list(int certs_only, int plain_only, int sigonly_also, char sep) { char *tmp, *ret = NULL; size_t nlen, rlen = 0; const struct keytype *kt; for (kt = keytypes; kt->type != -1; kt++) { - if (kt->name == NULL || kt->sigonly) + if (kt->name == NULL) + continue; + if (!sigonly_also && kt->sigonly) continue; if ((certs_only && !kt->cert) || (plain_only && kt->cert)) continue; diff --git a/sshkey.h b/sshkey.h index f393638..6a3ff2f 100644 --- a/sshkey.h +++ b/sshkey.h @@ -156,7 +156,7 @@ int sshkey_ec_validate_private(const EC_KEY *); const char *sshkey_ssh_name(const struct sshkey *); const char *sshkey_ssh_name_plain(const struct sshkey *); int sshkey_names_valid2(const char *, int); -char *sshkey_alg_list(int, int, char); +char *sshkey_alg_list(int, int, int, char); int sshkey_from_blob(const u_char *, size_t, struct sshkey **); int sshkey_fromb(struct sshbuf *, struct sshkey **); Thanks, Nuno
On 02/12/2017 03:46 PM, Nuno Gon?alves wrote:> On 1/30/2017 3:58 AM, Jakub Jelen wrote: >> 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, > > In that case this is converted to a bug report: Deprecation of SHA1 is > not being enforced since 7.4p1.Hello. Thank you for wide investigation. I filled a bug #2680 [1] to get it more attention. This is something we would really like to see fixed and the patch passed probably unseen by the developers. Damien, Darren, can we get it fixed? Thanks, -- Jakub Jelen Software Engineer Security Technologies Red Hat [1] https://bugzilla.mindrot.org/show_bug.cgi?id=2680