Bug 1402029

Description of problem:

fedora clients running openssh 7.3p1-5 and above (which is I guess just fedora 24 and above) which connect to our ssh certificate authority fail to receive a valid certificate on their forwarded ssh-agent. the same clients running 7.3p1-4 and below receive the certificate just fine.

Version-Release number of selected component (if applicable):

fedora 24.
openssh 7.3p1 -4 and above

How reproducible:

client running the above connects to our ssh certificate authority and successfully authenticates.

Steps to Reproduce:
1. n/a
2. 
3.

Actual results:


Expected results:


Additional info:

ssh agent debug log from openssh-7.3p1-6.fc25.x86_64. the CA adds two keys, the first is just the rsa private key, the second is the private key and the certificate. Both are constrained (type 25).

debug2: fd 3 setting O_NONBLOCK
debug2: fd 4 setting O_NONBLOCK
debug1: type 11
debug1: type 11
debug2: fd 5 setting O_NONBLOCK
debug1: XXX shrink: 4 < 5
debug2: fd 5 setting O_NONBLOCK
debug1: type 11
debug1: type 25
debug1: type 25
process_add_identity: decode private key: error in libcrypto
debug1: XXX shrink: 4 < 5
debug1: XXX shrink: 3 < 4


emailed jjelen and he responded with

`
Hello,
if the issue is introduced by this change, there must be a bug in the compat changes for openssl-1.1.0. We tested the changes quite extensively to avoid such problems, but it is possible we missed something.

Having a look into the code, this is most probably the path [1] that was very questionable (agent does not provide N and E parameters and they are required in the new API when constructing RSA keys). So RSA_set0_key() or RSA_set0_factors() is probably failing for some reason. The only way to find out which is probably under GDB. I will try to reproduce the behavior and to see how I can fix it.

Thank you for letting me know about the problem. To properly track the problem, bug would be fine.

[1] http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/tree/openssh-7.3p1-openssl-1.1.0.patch#n3634
`

this is an in-house ssh ca that accepts an ssh connection and then directly adds keys/certificates to the ssh-agent that's forwarded by the client. I'll see if I can get my user to repro the issue by just doing something like running 'ssh-add ./path/to/cert' with a forwarded ssh-agent. If you're having any trouble reproducing, I can write a pretty minimal ssh-ca that should replicate the issue for you.