I’ve been using the SSH Connector out of the Basic File System Connectors package for many months now. Suddenly today I’m getting an error:
Execute failed: ObjectIdentifier mismatch: 2.16.8188.8.131.52.4.2.3 (IOException)
This error is presenting on two separate systems all of a sudden, on Mac and one Windows. They are both running Knime 4.6.1, I removed and reinstalled Knime from the windows machine, same error comes back.
I’m not really sure where to go from here.
Confirmed with another colleague, they are getting the same error. None of us actively updated anything before this error started, so not really sure what the cause could be here.
Firstly, I would like to ask you to clarify whether it worked on 4.6.1 previously without this issue?
Secondly, I would like to suggest to write an email direct to our Support department email@example.com as far as we need logs and they could contain sensitive information.
The log files you can find:
- KNIME logs:
- Program logs:
Looking forward to your email!
Thanks, I will email in a moment. We had several people using this node across a few versions 4.6.0 and 4.6.2, I also reverted back to 4.5.2 where I had it running previously as well to test that out.
I should also say it’s likely the ssh server is the common denominator here, but I’m not sure what the issue there would be as we are using files.com and no other connections are failing to it. So just not sure what the disconnect would be.
It’s possible that your SSH server changed its certificate and it uses an algorithm that is not supported by the SSH node (yet). In case it’s a public SSH server we could have a look at the certificate if you send me its address.
Thanks - I’m asking internally if there were any changes to the server certificate. I don’t have CLI access to the server, but I did send the info I could find in the support ticket email as well.
The server address is versifit.files.com
I checked I can connect to the SSH server until it fails at the authentication. Part the connection itself works. I searched a bit and there were similar reports from other software projects in the past and the recommendation was to remove the server’s host keys from the known_hosts file and the re-attempt the connection. Apparently a host key in an older format in that file may cause issues. By deleting the old host key you should get the key in the new format upon the next connection and everything should be fine.
In any case it’s likely a change on the server side that caused the issue.
Thanks for the detail and assistance -
So far removing the host record didn’t fix the issue.
The advanced settings of the SSH Connector Node do not have the “Use known hosts file” option checked, it never was checked.
I attempted checking this box to point to the hosts file specifically, no change.
I added a known good hosts entry to that file, with the box checked, no change.
I also used the global Knime preferences to remove the hosts entry, which doesn’t actually remove the entry from the known_hosts file, so I’m not sure which hosts file the knime preferences is looking at? But removing it from Knime preferences also had no change.
A successful connection with WinSCP on the same machine gives this info:
File transfer protocol = SFTP-3
Cryptographic protocol = SSH-2
Encryption algorithm = AES-256 SDCTR (AES-NI accelerated)
Our setup has been with username/password, but I’ve also tried with key pairs with the same results.
The legacy SSH node does work, so I’m going to look at redoing the workflows with that process next.
For anyone that looks up this error - this issue still appears to exist with files.com, but I was able to successfully use an HTTPS connection rather than the legacy SSH connection (since the legacy file port doesn’t connect to the latest IO nodes)
Hey, thanks for the update, I’m still having the issue with files.com, I moved everything to legacy workflows, which isn’t great. Curious about your setup though, are you able to share a workflow?
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.