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

1,168 views
Skip to first unread message

Nuno Gonçalves

unread,
Jan 26, 2017, 3:16:26 PM1/26/17
to openssh-...@mindrot.org
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
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Jakub Jelen

unread,
Jan 30, 2017, 5:03:27 AM1/30/17
to openssh-...@mindrot.org
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,

--
Jakub Jelen
Software Engineer
Security Technologies
Red Hat

Douglas E Engert

unread,
Feb 2, 2017, 9:30:24 AM2/2/17
to openssh-...@mindrot.org
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 <DEEn...@gmail.com>

Nuno Gonçalves

unread,
Feb 12, 2017, 6:09:05 PM2/12/17
to openssh-...@mindrot.org, deen...@gmail.com
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 offered
so 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

Jakub Jelen

unread,
Feb 17, 2017, 11:24:28 AM2/17/17
to Nuno Gonçalves, openssh-...@mindrot.org, deen...@gmail.com
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
Reply all
Reply to author
Forward
0 new messages