Bug 1053305

Attaching what looks to be upstream report.

That doesn't look specific to x2goclient, but really affects ALL libssh clients. The triggering factor is the keys the server is offering.

At least this bug has an easy workaround: just continue anyway or delete the offending key from known_hosts.

I haven't had time to fix that yet.

With libssh-0.6.0 and x2goclient-4.0.1.2 on Fedora 20 i had the same initial key issue.  But after that i also get a second popup:
Connection failed Can not create remote file
~[user]/.x2go/ssh/key.[xyz] - scp status code 1d not valid

The x2go session functions but x2goclient consistently uses 100% cpu:
16254 dopey     20   0  924956  37844  25976 S 108.1  0.1   3:03.03 x2goclient  

yum downgrade libssh down to 0.5.5 resolves all the issues for now

I also experience this bug, and the only workaround that worked for me was downgrading libssh.

Removing the key from ~/.ssh/known_hosts does not work around this.

Maybe because x2goclient uses the old API which doesn't support ECDSA and so we end up with a key mismatch anyway? I guess x2goclient needs to get updated to the new public key API.

Ok, so I downgraded libssh to the libssh-0.5.5-1 release and continue to --exclude=libssh but what ist he plan to fix this?  This bug is filed against libssh and if libssh isn't going to change because it isn't at fault, should this bug be filed against x2goclient?

x2go is a new advertised feature (in the release notes anyway) with the Fedora 20 release and it is broken now without user awareness and intervention.

The plan for how to fix it is given in the upstream report:
https://red.libssh.org/issues/138
(libssh should check if ONE of the keys the server offers is the known one. IMHO, it should still use the best key after that, once the server is identified as known, but it has to validate against the key it knows.)

Dropping ECDSA support again wouldn't really fix this, either: If you first connect to the machine with OpenSSH, it records the ECDSA key and so we would get a mismatch in libssh when trying to use any OTHER key. So reverting is no solution.

I did (now! I wasn't aware of this issue when I pushed the update to stable!) get this mismatch error with kio_sftp with one server because there was an ssh-rsa key in known_hosts, I deleted the offending line and now the ECDSA key is recorded. I'm not sure why it is not as easy as that with x2goclient, but I can only assume it is because of missing ECDSA support in x2goclient, which is an RFE you should file against x2goclient. For x2goclient, just saying "No" to "Do you want to terminate the connection?" is the best workaround.

The upstream bug report says that if keys are already preseent in ~/.ssh/known_hosts the problem occurs.  I have the problem when I remove all keys for the server from the ~/.ssh/known_hosts file and then try to initiate an x2go connection.

Does removing the keys and letting a key (or keys) get added back also cause the same conflict situation as the upstream report... or like you said in comment 8, "I guess x2goclient needs to get updated to the new public key API"?  Or perhaps both?

Oh, to clarify... the just say No approach in the x2goclient that you mention in comment #10 doesn't work for me.  I'll try to do some more testing to make sure I'm not imagining something.

(In reply to Andy Wang from comment #5)
> The x2go session functions but x2goclient consistently uses 100% cpu:
> 16254 dopey     20   0  924956  37844  25976 S 108.1  0.1   3:03.03
> x2goclient  

They key issues are one thing, and this is another one which is fixed by downgrading libssh to 0.5.5.

(In reply to Andy Wang from comment #5)
> With libssh-0.6.0 and x2goclient-4.0.1.2 on Fedora 20 i had the same initial
> key issue.  But after that i also get a second popup:
> Connection failed Can not create remote file
> ~[user]/.x2go/ssh/key.[xyz] - scp status code 1d not valid


This is bug 1056757 in libssh.

FYI - This update also broke password based connections in x2goclient:

With libssh 0.6.0, ssh_userauth_list() no longer populates the available
authentication methods automatically (by calling ssh_userauth_none()) if
needed.  You need to explicitly call ssh_userauth_none() yourself first.

This was dealt with in x2goclient in bug 1057871, update pending shortly.

Hey, we have patch for the known_hosts issue. It is a change in behavior we missed when it was changed in OpenSSH. However the patch needs testing. So if someone is experienced in compiling libraries and could test the libssh master tree, that would be really great. If we get positive feedback from several people we will backport it to 0.6.0.

The upstream bug is: https://red.libssh.org/issues/138

I've built libssh 0.6.0 with this upstream change here: https://copr.fedoraproject.org/coprs/orion/testing/

I've also reverted the change to ssh_scp_string_mode that breaks scp.  Everyone please test.

Created attachment 858871 [details]
Error dialog when trying to connect with new test build 20140203

@17 - I downloaded the updated package and installed it... and then I could no longer connect with the x2goclient.  I also removed the ssh key for the host I was trying to connect to... and I did NOT get a new key acceptance dialog.  In both cases, I just got a blank dialogue box... which you can see a screenshot of in attachment post.

Thanks for trying though.

Scott - can you confirm that you are testing with x2goclient-4.0.1.3-3 (which fixes an issue with password authentication)?  I just tested myself and it fixed the issue with it complaining about an unknown hostkey type.

However, if I clear out the old rsa key for the host, I cannot connect and get:

kex error : no match for method server host key algo: server [ssh-rsa,ecdsa-sha2-nistp256], client []

after saying it should add the unknown key.  I do have now a:

localhost ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBOp4hFYMMsfVzD+5NzL4ty3wvG3ElD15E9LIL5dJ7kEZ3QpJDL3Trczoys+gxERz5mTxwXSUl0pXzzeiK5QuW/Y=

entry in my known-hosts.

I've just submitted a libssh-0.6.0-3 build to my copr repo that worked for me in local testing.  Hopefully will complete soon.  Please test.

https://copr.fedoraproject.org/coprs/orion/testing/

Sorry for the delay.  No I didn't also upgrade x2goclient so that was probably the issue.  You didn't mention it in comment 17.  I'll give that a try.  Where do I find the updated x2goclient-4.0.1.3-3 package?

Found x2goclient-4.0.1.3-3 in updates testing and tried it with your new libssh package and it works great for me.  Thanks.  Do I need to add some karma somewhere?

karma for the x2goclient update is always appreciated.  If there are no objections from the libssh folks I'll build and submit a real update tomorrow.

Orion, I plan to release 0.6.1 soon, hopefully this week.

Please do not create an update with the known_hosts patches. We have memory leaks, see:

http://test.libssh.org/viewDynamicAnalysis.php?buildid=19286

I need a green dashboard first :)

libssh-0.6.1-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/libssh-0.6.1-1.fc19

libssh-0.6.1-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libssh-0.6.1-1.fc20

libssh-0.6.1-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

libssh-0.6.1-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.