You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First issue that we ran into was in Class com.sshtools.client.PublicKeyAuthenticator (https://github.com/sshtools/maverick-synergy/blob/master/maverick-synergy-client/src/main/java/com/sshtools/client/PublicKeyAuthenticator.java) where method private boolean setupNextKey() throws IOException, SshException {}. It seems that currentKey is both instance of SshRsaPublicKey and instance of OpenSshRsaCertificate and first condition currentKey instanceof SshRsaPublicKey matches also in certificate use case and the else if block is never visited even when certificate is used. Client then connects to the server using normal public key instead of using a certificate.
if(currentKey instanceof SshRsaPublicKey && currentKey.getBitLength() >= 1024) {
//handling of public keys
}else if(currentKey instanceof OpenSshRsaCertificate && currentKey.getBitLength() >= 1024)
{
//handling of certificates
}
We think that the correction could be to swap the conditions, so that OpenSshRsaCertificate is checked first. Normal public keys shouldn't match OpenSshRsaCertificate condition.
if(currentKey instanceof OpenSshRsaCertificate && currentKey.getBitLength() >= 1024) {
//handling of certificates
}else if(currentKey instanceof SshRsaPublicKey && currentKey.getBitLength() >= 1024)
{
//handling of public keys
}
It seems to us that the code is trying to compare certificate type ([email protected]) to used algorithm ([email protected]) which can never match since only supported certificate type seems to be [email protected] (See cert creation above). We managed to get this work by bypassing this check completely.
Unlike ECDSA where certificate type contains the key length, there only seems to be one type for RSA certificates. SHA256 and SHA512 keys still use the [email protected] as certificate type.
I'm committing fixes for this in 3.1.3-SNAPSHOT shortly and will follow up in 3.2.0-SNAPSHOT next time I visit that branch.
I'll also expand the tests to cover these new types (hence the reason for the issues in the first place!)
Regarding encoding of RSA key algorithm name... the fix is not to ignore the check, but to check the getEncodingAlgorithm method as that contains the correct encoding name.
Hello,
We are using maverick-synergy version 3.1.1 with maverick-bc module.
We have been trying to get RSA SHA2 certificate authentication working but it's failing. ECDSA and ED25519 certificate authentication is working fine.
I have created certificates for server and client using following commands. My SSH version was OpenSSH_9.6p1, LibreSSL 3.3.6
This creates following certificates with certificate type of [email protected], we'll return to this later.
First issue that we ran into was in Class com.sshtools.client.PublicKeyAuthenticator (https://github.com/sshtools/maverick-synergy/blob/master/maverick-synergy-client/src/main/java/com/sshtools/client/PublicKeyAuthenticator.java) where method
private boolean setupNextKey() throws IOException, SshException {}
. It seems that currentKey is both instance of SshRsaPublicKey and instance of OpenSshRsaCertificate and first conditioncurrentKey instanceof SshRsaPublicKey
matches also in certificate use case and the else if block is never visited even when certificate is used. Client then connects to the server using normal public key instead of using a certificate.We think that the correction could be to swap the conditions, so that OpenSshRsaCertificate is checked first. Normal public keys shouldn't match OpenSshRsaCertificate condition.
Second issue was also in the Class com.sshtools.client.PublicKeyAuthenticator (https://github.com/sshtools/maverick-synergy/blob/master/maverick-synergy-client/src/main/java/com/sshtools/client/PublicKeyAuthenticator.java). Code checks if server supports SHA512 signatures but then currentKey is populated with new OpenSshRsaSha256Certificate and signed with SHA512. This will result in invalid signature which is rejected by SSH server.
This can be fixed buy using OpenSshRsaSha512Certificate for the SHA512 signature
Final issue was in class com.sshtools.common.publickey.OpenSshCertificate (https://github.com/sshtools/maverick-synergy/blob/master/maverick-base/src/main/java/com/sshtools/common/publickey/OpenSshCertificate.java). Method public SshPublicKey init(byte[] blob, int start, int len) throws SshException.
There is a following check which compares header to algorithm.
We made a debug print from the situation which returned following
It seems to us that the code is trying to compare certificate type ([email protected]) to used algorithm ([email protected]) which can never match since only supported certificate type seems to be [email protected] (See cert creation above). We managed to get this work by bypassing this check completely.
Unlike ECDSA where certificate type contains the key length, there only seems to be one type for RSA certificates. SHA256 and SHA512 keys still use the [email protected] as certificate type.
The text was updated successfully, but these errors were encountered: