-
Notifications
You must be signed in to change notification settings - Fork 601
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PKCS#8 support #437
Comments
I'm having the same issue. |
@Kamil-Cumulocity I could workaround the bug by converting my PKCS#8 private key into a PKCS#1 private key, if that helps you.
That should yield a PKCS#1 key with the necessary |
I'm encountering the same issue. The openssl conversion above initially didn't work for me. Then I realized my openssl is in FIPS mode. I used openssl on a non-fips system and it worked as expected. |
1. From the sshj source code, it seems support the PKCS8 key format. (VERSION 0.26.0)
2. When to apply PKCS8 format, reference:
When my key format is
3. How to use PKCS8 and the format of Public and Priviate key
I followed this guaid, just use RSA format key. |
@tancolo In this context, I'm referring to parsing an existing PKCS#8 encoded key pair created through openssl as opposed to creating the key through this library. It does indeed look like the library supports the PKCS#8 encoding, but I think the implementation runs into an issue when trying to parse the key pair based on the heading. As I said, the bouncycastle openssl library returns a different type of object than sshj expects for a PKCS#8 file; the header that sshj ties to the PKCS#8 format is actually associated with PKCS#1 files. You can find the definition of the header for PKCS#8 files in RFC 5958, which simply uses |
Indeed as @j4ns8i mentioned there is an issue with PKCS#8 support. I have met the same problem and it is not with SFTP. |
Fixed with #708 and #713. Thanks @exceptionfactory! |
yes, thank you both @hierynomus and @exceptionfactory! i haven’t worked on this since roughly around the time i submitted the issue, but i want to express my appreciation for your contributions to and maintenance of this library. you rock |
I'm debugging an application that uses sshj for connecting to other machines when given an ssh key pair. I uploaded a PKCS#8 encoded private key to this application, with which I verified I could manually authenticate to the other machines it manages through ssh (
ssh -i ~/.ssh/mykey.pem node
). However, the sshj library failed to authenticate with this key with the following stacktrace:Right before that stacktrace is a debug message (which I believe should be a warning instead):
This happens because my PKCS#8 private key contains the standard header of
-----BEGIN PRIVATE KEY-----
, which bouncycastle's openssl library parses into a PrivateKeyInfo object. As it is currently, sshj will only properly construct aPKCS8KeyFile
from aPEMEncryptedKeyPair
orPEMKeyPair
(as explained in the debug/warning message), which will only be returned from files with the-----BEGIN RSA PRIVATE KEY-----
header and correspond to PKCS#1 encoded files. Thus, it appears like thePKCS8KeyFile
will actually only work with PKCS#1 keys.I believe it should still be possible to construct the PKCS#8 object from the
PrivateKeyInfo
object that the openssl library returns. The object should contain the modulus and public exponent needed to reconstruct the public key for the key pair.The text was updated successfully, but these errors were encountered: