Cannot connect to old OpenSSH server since version 0.1.57 #45
Comments
|
This is the debug log where the connection is broken using the current version 0.1.62: The issue can still be workarounded by modifying the |
|
The What type of SSH key are you attempting to use for authentication? Also, do you know what the setting of My suspicion as to what is happening is that the OpenSSH 5.3 server you are attempting to connect with has On a side note, all of the default crypto settings in this JSch fork were changed to align similarly to what is used in modern versions of OpenSSH, so that this JSch fork would only utilize secure crypto algorithms by default (skipping crypto algorithms generally accepted as no longer being secure). This has the unfortunate side effect in that attempting to connect to old servers will likely require some amount of custom tweaking of the various crypto algorithms (similar to what you have discovered with the |
|
Thank you for your quick reply! Unfortunately, the remote server is not under our control and I don't know its specific configuration. All I can say is that this server is part of a critical infrastructure and accessed by many corporations for critical "stuff", so I don't expect that someone will touch the configuration of the server in the foreseeable future. What you say makes a lot of sense. But still, the I just found out that Jsch parses the content of the
I don't know what exactly you are asking for, but the private key header looks like this: And the public key begins with |
|
FYI, the reason the It wasn't until OpenSSH 7.8 in which the RSA SHA-2 signature types (rsa-sha2-256 & rsa-sha2-512) started being preferred before RSA SHA-1 signature type (ssh-rsa). See the note about the change of semantics of the I'm reasonably certain that if you attempted to use the |
|
Just to correct myself: The file |
You're probably right about that und you make a really strong point for why this is actually not a bug in this JSch fork. I am not really happy with the workarounds, but these workarounds seem to become necessary in the near future anyway. So, shall we close this issue? :) |
|
Yes, I am mulling over ways in which we can improve the behavior of this JSch fork to better help users in situations similar to yours (you aren't the first user to report similar types of problems). I'm just not sure what we can do to help make scenarios like yours work out-of-the-box, whilst still enforcing some amount of integrity in having the crypto algorithm defaults avoid using the "unsecure" algorithms. |
If this is true, I don't have any ideas for more elegant solutions, either. |
FYI, there is an extension, named |
|
I will close this issue now. There is no need to clutter the issue list with an issue with no possible solution :) Thanks again! |
Hi,
we need to connect to a quite old sftp server running OpenSSH 5.3. This worked nicely with the original Jsch and also with this fork up to version 0.1.56. Unfortunately, it is broken with all versions since 0.1.57 up to the current version 0.1.62.
This is the debug log of a working connection using 0.1.56:
This is a debug log of version 0.1.57 where the connection is broken:
As you can see, only one line is different:
vs
Surprisingly, setting this in my code does not fix the issue, even though it makes the log look identical (except for the disconnect and the exception at the end):
Instead, I am able to workaround the issue by setting this:
This change moves
ssh-rsato the front of the value, compared to the default config.But I really do not want to do that, for multiple reasons:
PubkeyAcceptedKeyTypes.I can't find any documentation for
PubkeyAcceptedKeyTypes. I just found out about this by reading this commit: 045799eAgain, this worked with the original version of Jsch and broke with a minor version update. Also, the remote server uses a completely normal (but rather old) OpenSSH version without exotic settings. These are the reasons why I believe this to be a bug in this library.
The text was updated successfully, but these errors were encountered: