Bug 398574 - KIO SFTP doesn't connect to some (ecdsa-sha2-nistp256 key) hosts with libssh 0.8
Summary: KIO SFTP doesn't connect to some (ecdsa-sha2-nistp256 key) hosts with libssh 0.8
Status: RESOLVED FIXED
Alias: None
Product: kio-extras
Classification: Frameworks and Libraries
Component: SFTP (show other bugs)
Version: 18.08.1
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Andreas Schneider
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-13 11:55 UTC by Mykola Krachkovsky
Modified: 2023-07-05 13:11 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mykola Krachkovsky 2018-09-13 11:55:41 UTC
After update of libssh to 0.8.2 KIO SFTP stopped to connect to hosts with known ecdsa-sha2-nistp256 keys, while `ssh` and KIO FISH work fine.

KIO SFTP fails with error
"The host key for this server was not found, but another type of key 
exists. An attacker might change the default server key to confuse your client 
into thinking the key does not exist. Please contact your system 
administrator."

One of servers has ecdsa-sha2-nistp256 key but still works.

I've looked into code and found that kio_sftp in sftpProtocol::openConnection() calls
```
  rc = ssh_get_publickey_hash(srv_pubkey,
                              SSH_PUBLICKEY_HASH_SHA1,
                              &hash,
                              &hlen);
```

I think that worked fine with 0.7.5 which had only SSH_PUBLICKEY_HASH_SHA1 and SSH_PUBLICKEY_HASH_MD5 cases in switch.
But 0.8.2 also has SSH_PUBLICKEY_HASH_SHA256.

BTW, called after that ssh_is_server_known is deprecated.
Comment 1 Nate Graham 2018-09-13 16:42:36 UTC
does this work if you delete the entry for the affected server in your .known_hosts file?

Since it seems like you've identified the relevant piece of code, would you like to try your hand at submitting a patch? The process is pretty simple, and it's well documented here: https://community.kde.org/Infrastructure/Phabricator
Comment 2 Mykola Krachkovsky 2018-09-14 10:05:47 UTC
(In reply to Nate Graham from comment #1)
> does this work if you delete the entry for the affected server in your
> .known_hosts file?
Oh, sorry, forgot to say, after `ssh-keygen -R ...` kio sftp connects fine and adds `ssh-ed25519` keys to known hosts.

> Since it seems like you've identified the relevant piece of code, would you
> like to try your hand at submitting a patch? The process is pretty simple,
> and it's well documented here:
> https://community.kde.org/Infrastructure/Phabricator
Ok, I'll try. I've used Phabricator already, just haven't worked with libssh directly before.
Comment 3 Nate Graham 2018-09-14 22:20:08 UTC
Thanks! Let me know if you need a hand, and please mention the URL for your patch here once you've submitted it.
Comment 5 Andreas Schneider 2018-09-19 15:03:47 UTC
Oh sorry, this is about known_hosts. However in libssh 0.8 the known_hosts API has been rewritten but kio_sftp is not using that yet. This will be fixed soon.

My WIP branch is:
https://gitlab.com/cryptomilk/kio-extras/commits/asn/master-sftp


I will finish it once libssh 0.8.3 is out.
Comment 6 Mykola Krachkovsky 2018-09-19 15:32:49 UTC
(In reply to Andreas Schneider from comment #5)
> Oh sorry, this is about known_hosts. However in libssh 0.8 the known_hosts
> API has been rewritten but kio_sftp is not using that yet. This will be
> fixed soon.
> 
> My WIP branch is:
> https://gitlab.com/cryptomilk/kio-extras/commits/asn/master-sftp
> 
> 
> I will finish it once libssh 0.8.3 is out.

Just curious. I've noticed that `knownhosts.c` was added which should replace old `known_hosts.c`, right? And functions like `ssh_is_server_known` were deprecated. But moving from `ssh_is_server_known` to `ssh_session_is_known_server` means loosing compatibility with libssh < 0.8? Is it ok? Well, that's not problem for openSUSE Tumbleweed, which I use, but KDE Neon still uses older packages, am I right?
Comment 7 Andreas Schneider 2018-09-19 16:07:18 UTC
If KDE Neon can update KDE packages to a newer version, they should be able to update libssh too!
Comment 8 Harald Sitter 2018-09-21 10:33:13 UTC
Still broken with new known_host API for me (libssh stable-0.8 and master alike).

me@ajax:~/src/git/libssh/build$ examples/samplesftp racnoss.kde.org
The host key for this server was not found but an other type of key exists.
An attacker might change the default server key to confuse your clientinto thinking the key does not exist
We advise you to rerun the client with -d or -r for more safety.

me@ajax:~/src/git/libssh/build$ ssh-keygen -F racnoss.kde.org
# Host racnoss.kde.org found: line 1 
|1|GpoMzlmsCkVxm2C2HN212nMxTUQ=|/m/8gVwXaSudoJAJEzhDIaKN8TI= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBMVxqMwduCPVFwPOwBo/bluVKgc2St6irQrnZ62PtxPa1vQZqVweX7mLCbbVc2hcFg8Itzf97D+IWZXW9VT6ado=

Same with kio_sftp using the new API.
Comment 9 Harald Sitter 2018-09-21 11:05:14 UTC
Oh, and wouldn't it constitute a runtime-incompatible change in libssh if the old API failed to correctly handle keys it handled fine in 0.7?
Comment 10 Andreas Schneider 2018-09-21 11:42:09 UTC
Harald, the error you get is about libssh negotiated a ed25519 key with the server but then found a ecdsa key in the known_hosts file. I guess it works if you use ed25519 which I really would recommend over ecdsa. However we need to check if we need to keep all keys sent by the server and cycle through them.
Comment 11 Andreas Schneider 2018-09-21 11:47:31 UTC
Ah, yes. libssh prefers ed25519 and OpenSSH prefers ecdsa.

Host *.kde.org
  HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-rsa

Will give you the same order as OpenSSH and it should work.
Comment 12 Andreas Schneider 2018-09-21 12:06:05 UTC
There is a feature in OpenSSH which we don't implement yet. They check the known_hosts file for the keytype to the server we want to connect to. If there is one, then they put that at first position of the preferred keys to negotiate with the server. This way the client and server settle on that key.

Workaround: Use the 'HostKeyAlgorithms' config option an select the key you want to use. ed25519 is better than ecdsa.
Comment 13 Andreas Schneider 2018-09-21 14:22:42 UTC
https://bugs.libssh.org/T105
Comment 14 Harald Sitter 2023-07-05 13:11:35 UTC
Guessing this is resolved now that newer libsshs spread throughout the universe.