Skip to content
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

ED25519 keys with passphrase generated by Juice SSH cannot be decrypted to create SSH connection #2976

Closed
TranceLove opened this issue Nov 1, 2021 · 3 comments
Assignees
Labels
Area-Ssh/Scp/Sftp From-telegram Issue reported through telegram channel Issue-Bug Related unexpected behavior or something worth investigating.

Comments

@TranceLove
Copy link
Collaborator

To Reproduce
Steps to reproduce the behavior:

  1. Generate a key pair in Juice SSH, using ED25519 as key type, and enter a passphrase
  2. Export the key pair
  3. Copy the public key to target SSH server
  4. Create a new SSH connection in Amaze, using the private key exported in 2
  5. Enter passphrase in 1 when prompted
  6. Amaze complained incorrect passphrase even when correctly entered

Expected behavior
The key should decrypt, hence create the SSH connection without problem

Smartphone (please complete the following information):

  • Device: Pixel 2 emulator
  • OS: Android 11
  • Rooted: yes, but should not matter
  • Version: 3.6.5

Additional context
The key pair generated above can be used in Solid Explorer without problems.

And when the key went through PemToKeyPairTask, such exception was seen

java.lang.IllegalStateException: Cipher 'aes128-cbc' not currently implemented for openssh-key-v1 format
	at com.hierynomus.sshj.userauth.keyprovider.OpenSSHKeyV1KeyFile.createCipher(OpenSSHKeyV1KeyFile.java:145)
	at com.hierynomus.sshj.userauth.keyprovider.OpenSSHKeyV1KeyFile.decryptBuffer(OpenSSHKeyV1KeyFile.java:117)
	at com.hierynomus.sshj.userauth.keyprovider.OpenSSHKeyV1KeyFile.readDecodedKeyPair(OpenSSHKeyV1KeyFile.java:110)
	at com.hierynomus.sshj.userauth.keyprovider.OpenSSHKeyV1KeyFile.readKeyPair(OpenSSHKeyV1KeyFile.java:79)
	at net.schmizz.sshj.userauth.keyprovider.BaseFileKeyProvider.getPublic(BaseFileKeyProvider.java:81)
	at com.amaze.filemanager.asynchronous.asynctasks.ssh.PemToKeyPairTask$OpenSshV1PemToKeyPairConverter.throwingConvert(PemToKeyPairTask.kt:221)

which looks quite true.

https://github.com/hierynomus/sshj/blob/3256f5336d46afd9a2524b12e8e4a9480a604b22/src/main/java/com/hierynomus/sshj/userauth/keyprovider/OpenSSHKeyV1KeyFile.java#L191-L198

Not sure if we should override it and add the cipher back though (if this is really the culprit).

@TranceLove TranceLove added Issue-Bug Related unexpected behavior or something worth investigating. Area-Ssh/Scp/Sftp From-telegram Issue reported through telegram channel labels Nov 1, 2021
@borisrunakov
Copy link

Also tried with RSA from JuiceSSH, but the private key can't be read by Amaze. The error message is "No converter available to parse selected PEM".
Additionally, it seems that key passphrase is requested even for keys without passphrase.

TranceLove added a commit to TranceLove/sshj that referenced this issue Mar 5, 2022
Reported from TeamAmaze/AmazeFileManager#2976, it was found the key uses aes-128-cbc which is currently not supported by sshj. This change adds support for it.

To enable support for this, also eliminated hardcoding byte array size for key and IV, as a result of BCrypt.pbkdf().
TranceLove added a commit to TranceLove/sshj that referenced this issue Mar 5, 2022
Reported from TeamAmaze/AmazeFileManager#2976, it was found the key uses aes-128-cbc which is currently not supported by sshj. This change adds support for it.

To enable support for this, also eliminated hardcoding byte array size for key and IV, as a result of BCrypt.pbkdf().
@TranceLove TranceLove self-assigned this Mar 5, 2022
@TranceLove
Copy link
Collaborator Author

Pending required changes to merge at upstream sshj library :)

hierynomus pushed a commit to hierynomus/sshj that referenced this issue Mar 7, 2022
Reported from TeamAmaze/AmazeFileManager#2976, it was found the key uses aes-128-cbc which is currently not supported by sshj. This change adds support for it.

To enable support for this, also eliminated hardcoding byte array size for key and IV, as a result of BCrypt.pbkdf().
@TranceLove
Copy link
Collaborator Author

With hierynomus/sshj#770 merged and we are using sshj 0.34.0 now, this should be considered fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Ssh/Scp/Sftp From-telegram Issue reported through telegram channel Issue-Bug Related unexpected behavior or something worth investigating.
Projects
None yet
Development

No branches or pull requests

2 participants