There is no way to verify whether a certificate matches a public/private key pair

[AlainKnaff]

• Attempting to do JSch.addIdentity() with non-matching private key and certificate appears to succeed (simply ignoring the certificate), and only fails late when attempting to actually connect to a server that needs the certificate.

• attempting to create a keypair once with the private key and null, and once with null and the certificate leads to the keypair derived from the certificate to return a bogus publicKeyBlob and fingerprint. For the certificate, the fingerprint doesn't match what ssh-keygen -l -f says, whereas it does match for the primary key.

[AlainKnaff]

I think I found the reason why an Identity made from an OpenSsh certificate returns a bad publicKeyBlob: the following constructor invocation at the end of OpenSshCertificateAwareIdentityFile.newInstance() :

return new OpenSshCertificateAwareIdentityFile(name, declaredKeyType, keyData, cert, kpair,
comment);

The keyData should really be cert.getCertificatePublicKey()

indeed, keyData is the byte data representing the certificate, and not the byte data representing the public key.

Unfortunately, all involved classes are package private, so any application using the library cannot easily work around this.

Thanks

[norrisjeremy]

Hi @AlainKnaff,

For the issue with non-matching private key and certificate, have you verified if this behavior differs from the non-cert usage?
I.e., if you pass a non-matching private key & public key, does JSch behave differently than if you provide a non-matching private key & cert.

For the second item, can you provide more details? I.e., example code illustrating the problem you are encountering?

Thanks,
Jeremy

[AlainKnaff]

For non-cert usage, compatibility of public and private key is not checked either. In that case, getPublicKeyBlob() will return the public key blob as contained in the private key.

getPublicKeyBlob() seems to be the entire base64 encoded sequence of the public key, including the key type (such as "ssh-ed25519"). This is also present in its entirety as part of the private key.

For the the certificate, it (wrongly) is the base64 encored sequence of the entire certificate.

I was however mistaken in suggesting to use cert.getCertificatePublicKey() for the OpenSshCertificateAwareIdentityFile. That would only be the 32 bytes (in case of ed25519) of the actual public key, without the key type. The key type of the signed key is not included as such in the certificate, but probably it could be derived from the certificate's own type ("ssh-ed25519-cert-v01@openssh.com") by stripping the end? I didn't check however whether that works out for rsa or ecdsa.

Appended is a test program. It takes as parameters the name of a file with the private key, and another file with the public key (or certificate). Supply empty strings to construct identities without that part.
It outputs a hexdump of the publicKeyBlob of the identity constructed with those parts.

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Paths;
import com.jcraft.jsch.JSch;
import com.jcraft.jsch.Identity;


public class Test {
    public static byte[] readFile(String file) throws IOException {
	if(file.length() == 0)
	    return null;
	return Files.readAllBytes(Paths.get(file));
    }

    public static void hexdump(byte[] b) {
	int i=0;
	while(i < b.length) {
	    if(i % 16 == 0)
		System.out.print(String.format("%04x", i));
	    System.out.print(String.format(" %02x", b[i] & 0xff));
	    if(i % 16 == 15)
		System.out.println();
	    i++;
	}
	System.out.println();
    }

    public static void main(String[] args) throws Exception {
	var jsch=new JSch() {
		public void addIdentity(Identity identity, byte[] passphrase) {
		    System.out.println("Identity="+identity);
		    byte[] b = identity.getPublicKeyBlob();
		    hexdump(b);
		}
	    };
	jsch.addIdentity("test", readFile(args[0]), readFile(args[1]), null);
	System.out.println("Done");
    }
}

[AlainKnaff]

I've had a couple of minutes to dig a bit deeper into this.
The correct publicKeyBlob (correct for fingerprinting and comparing purposes) is indeed available in OpenSshCertificateAwareIdentityFile's constructor, it's the certPublicKey local variable, which ends up as the public part of the kpair. However, there it is not available to application programs in a normal way, as the OpenSshCertificateAwareIdentityFile class is not public and the getKpair() is not part of the Identity interface.

"Fixing" the getPublicKeyBlob() method to return getKpair().getPublicKeyBlob() does not work unfortunately, as callers within Jsch itself use it for a different purpose, which is getting the certificate's own byte sequence for presenting to the server. Such an "easy" fix would break certificate authentication.

So maybe the proper fix to get validation would be if OpenSshCertificateAwareIdentityFile's constructor itself would do the comparison between private and public key's actual publicKeyBlob, and throw an exception on mismatch. Exceptions are already thrown for other conditions such as the outer key type (in the ASCII representation of key) does not match inner (in the binary representation). So there should be no harm on being more picky here.