Gnome-shell-extension-gsconnect: Can't mount, error "Gio.IOErrorEnum: Host key verification failed"

[svcer]

Hi,

I have been using GSConnect successfully for around a month with no problems. Yesterday I tried to mount my filesystem and nothing happened. I noticed the following error in the journal log:

Nov 19 11:26:38 debian gjs[4074]: JS ERROR: Galaxy S9: Gio.IOErrorEnum: Host key verification failed
_mount/[email protected]/service/plugins/sftp.js:178:33
@/(...)/gnome-shell/extensions/[email protected]/service/daemon.js:1149:2

Steps to troubleshoot:

1. I uninstalled, reinstalled the app including removing all of the directories:

gnome-shell-extension-tool -d [email protected]
rm -rf ~/.local/share/gnome-shell/extensions/[email protected]
rm -rf ~/.cache/gsconnect
rm -rf ~/.config/gsconnect
dconf reset -f /org/gnome/shell/extensions/gsconnect/

1. I reinstalled KDC Connect

2. I ran adb logcat --pid=$(adb shell pidof -s org.kde.kdeconnect_tp) on my phone and inspected the logs

11-19 12:17:27.149 22303 22414 I KDE/LanLinkProvider: Broadcast identity package received from debian
11-19 12:17:27.307 22303 22414 I KDE/LanLinkProvider: Starting SSL handshake with debian trusted:true
11-19 12:17:27.407 22303 30108 I KDE/LanLinkProvider: Handshake as server successful with debian secured with TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
11-19 12:17:27.407 22303 30108 I KDE/LanLinkProvider: Creating a new link for device f984ee58-56bf-4e6c-9c47-3d5f36577539
11-19 12:17:27.408 22303 30108 I KDE/BackgroundService: addLink, known device: <GUID>
11-19 12:17:27.411 22303 30108 I KDE/Device: Got certificate 
11-19 12:17:27.411 22303 30108 I KDE/Device: addLink LanLinkProvider -> debian active links: 1
11-19 12:17:27.413 22303 30108 I KDE/addPlugin: Permissions OK SftpPlugin

Everything looks fine in this log, I inspected the rest of it, no errors at all.

1. I generated a support log, here is the result:

GSConnect Version: 28
GSConnect Install: user
GJS: 15403
XDG_SESSION_TYPE: wayland

GDMSESSION: gnome

-- Logs begin at Tue 2019-11-19 11:22:34 EST, end at Tue 2019-11-19 11:50:23 EST. --
Nov 19 11:50:00 gjs[5850]: JS ERROR: Galaxy S9+: Gio.IOErrorEnum: Host key verification failed
_mount/[email protected]/service/plugins/sftp.js:178:33
@/home/(...)/[email protected]/service/daemon.js:1149:2
Nov 19 11:50:20 org.gnome.Shell.Extensions.GSConnect[5850]: [/service/protocol/core.js:send:321]: Galaxy S9: {
"id": 1574182220804,
"type": "kdeconnect.sftp.request",
"body": {
"startBrowsing": true
}
}
Nov 19 11:50:21 org.gnome.Shell.Extensions.GSConnect[5850]: [/service/protocol/core.js:receive/<:275]: Galaxy S9: {
"id": 1574182220122,
"type": "kdeconnect.sftp",
"body": {
"ip": "x.x.x.x",
"port": 1747,
"user": "kdeconnect",
"password": "xxx",
"path": "/",
"multiPaths": [
"/9C33-6BBD",
"/primary"
],
"pathNames": [
"9C33-6BBD",
"primary"
]
}
}

...but nothing happens. The Mount window doesn't open.

1. I have verified that i have configured multiple storage locations under File expose settings.

2. I checked the firewall port ranges are all open. I can verify with netstat -lntup that gjs is listening on ports tpc/upd 1716. Everything else works great, I can send files from Android to gsconnect. Unfortunately the one thing I use gsconnect for is to easily transfer files between the phone and computer and this is not working.

Any idea why all of a sudden the host key verification is failing and even after a complete reinstall I still can't mount the filesystem? Google suggests it could be an SSH error. There is an RSA key and ceritifcate under ~/.config/gsconnect and they both look valid, the KDE log shows the handshaking and setting up the connection without errors.

Nothing else on the phone or computer have changed recently.

Thanks.

[svcer]

I have an update: I created a new use account on my host and installed gsconnect. I paired my phone and can open the mount as expected. The kde app on my phone did not need to be changed so this rules out kde as the problem. Would this suggest it is a configuration issue or something in my profile? I did uninstall the app completely a few times and clear out all of the directories (including the certificates in .config as per the instructions), are there some files that remain that I need to delete?

[andyholmes]

Contrary to what you might think, uninstalling GSConnect or the Android or app will usually make things worse in this case.

GSConnect and kdeconnect-android pair by exchanging TLS certificates and relying on the user to confirm identity. Once that is done the same certificate is used to associate an IP address with a host key for SFTP connections.

So what's happened is that your phone started reporting a different host key with a same IP and GSConnect is refusing to mount it, which is what it should do. Usually GSConnect will wipe all host keys it knows about when this happens, but it's unclear if that's happening or not. You can try doing this manually in a terminal:

$ for i in `seq 1739 1764`; do ssh-keygen -R [PHONE_IP]:$i; done

Since you've reset all your settings and reinstalled a couple times, it's hard to say what's happening now though.

[didierga]

Hi,

I had same problem since weeks - unable to browse phone storage - and I did the same mistake, I removed-reinstalled GSConnect on Linux and KDE Connect on Android many times with no success.

Removing phone ssh keys on Linux fixes my problem and I can now browse phone storage.

To help to prevent this problem, it will be useful to have a GS Connect message when there is many ssh keys defined for the phone IP on Linux.

[andyholmes]

To help to prevent this problem, it will be useful to have a GS Connect message when there is many ssh keys defined for the phone IP on Linux.

It's pretty hard to know what your "phone IP" is, because it's only reported by your phone during run time and can change arbitrarily. But as I said, GSConnect will automatically remove all old host keys for the phone when one of these errors occurs.

So the real cause here is probably that when the host key error occurs, removing the faulty host keys fails, but I don't see any errors about that in the logs here.

My "I Told You So"

In terms of notifying of errors like this, we're really coming full-circle from about 6-12 months ago. Many users complained about too many error notifications, warnings logged in the journal and so on.

At that time I pointed out that muting these errors was a bad idea and that if I did it, it would become their responsibility to do the hard work of debugging those silent errors. Unfortunately, I'm not really the kind of developer that will argue endlessly for the "right thing", so if enough people ask for something I'll just do it.

[ferdnyc]

My "I Told You So"

Please say there's even a little dance? Dance!

[svcer]

Thanks for the update. Unfortunately, the mount only worked for one day and I am back to the same problem now with the same Host key verification failed error.

I tried running the command for i inseq 1739 1764; do ssh-keygen -R [PHONE_IP]:$i; done and got the following message:

Host [PHONE_IP]:1739 not found in /home/oem/.ssh/known_hosts

When i look at the known_hosts file I only see what looks like encrypted strings all starting with |1|

I have not uninstalled since you informed us that it makes the issue worse. Any ideas on next steps?

[svcer]

So I have continued to try to get it working without success. I do have a change to report. After running the for i in seq 1739 1764; do ssh-keygen -R [PHONE_IP]:$i; done command, I do not get the Host key verification failed error any longer. Before I would see it reliably every time. Now I don't see any errors, it just doesn't work... nothing happens. I can restart, connect, disconnect etc but no luck.

[andyholmes]

At this point if you've uninstalled GSConnect, it won't make much difference since your certificate has already changed. If you've uninstalled KDE Connect both it's certificate and the host key have changed. However, it's worth pointing out that uninstalling GSConnect or the Android app and wiping all settings will rarely fix anything.

I'm assuming you replaced PHONE_IP with the actual IP address of your phone, since there is no way for us to know what it is except during run-time. If not, you should re-run this command with the proper IP or hostname. The keys in known_hosts are hashed for security reasons, so they are not meant to be human-readable or inspectable.

[svcer]

Okay, I think I did have the syntax wrong when I tried the command before, I may have omitted the [ ] characters around the IP address. I tried it again and I got the following:

> # Host [x.x.x.x]:1739 found: line 2
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1740 found: line 2
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1741 found: line 2
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1742 found: line 2
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1743 found: line 2
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1744 found: line 2
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1745 found: line 2
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1746 found: line 2
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1747 found: line 2
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1748 found: line 2
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1749 found: line 2
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1750 found: line 2
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1751 found: line 2
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1752 found: line 1
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> Host [x.x.x.x]:1753 not found in /home/oem/.ssh/known_hosts
> # Host [x.x.x.x]:1754 found: line 7
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1755 found: line 7
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1756 found: line 7
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1757 found: line 7
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1758 found: line 1
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1759 found: line 1
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1760 found: line 1
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1761 found: line 1
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1762 found: line 1
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> # Host [x.x.x.x]:1763 found: line 1
> /home/oem/.ssh/known_hosts updated.
> Original contents retained as /home/oem/.ssh/known_hosts.old
> Host [x.x.x.x]:1764 not found in /home/oem/.ssh/known_hosts

so this looks hopeful. I closed both gsconnect and kde connect, reboted and tried to connect again... nothing. No error in the log it just doesn't do anything when mount is selected.

Support log gives me this:

Nov 21 11:56:08 org.gnome.Shell.Extensions.GSConnect[30680]: [/service/protocol/core.js:send:321]: Galaxy S9+: {
"id": 1574355368786,
"type": "kdeconnect.sftp.request",
"body": {
"startBrowsing": true
}
}

any ideas on next steps?

[ioogithub]

Same problem here! A while ago I really tried to get the feature working. It seemed like it worked for a few days and then stopped working. I was never able to get it working again. I tried the steps in this thread without success.

When it worked it would have a Files entry on the menu but when it stopped working it would have a mount option so I always knew right away it wasn't working. Clicking on mount doesn't produce any error.

Could it be network related? I thought it might have been that getting a new IP address from a DHCP server or connection to a new network is what breaks it but I was never able to recover and get it working again.

[andyholmes]

@svcer If the android app is simply not responding, then it's probably a problem in the Android app and you'll probably have to debug that with:

adb logcat --pid=$(adb shell pidof -s org.kde.kdeconnect_tp)

@ioogithub The first thing you should do is Generate a Support Log as described in the Wiki.

[ferdnyc]

So what's happened is that your phone started reporting a different host key with a same IP and GSConnect is refusing to mount it, which is what it should do. Usually GSConnect will wipe all host keys it knows about when this happens, but it's unclear if that's happening or not. You can try doing this manually in a terminal:

$ for i in `seq 1739 1764`; do ssh-keygen -R [PHONE_IP]:$i; done

Here's one last, more-radical option people might try, after removing all of the stored host data with the above command: You can fill in the _correct_ data "manually", using ssh-keyscan. Basically if you do this:

$ # For a theoretical phone with IP address 1.2.3.4
$ for i in $(seq 1739 1764); do ssh-keyscan -p $i 1.2.3.4 |tee -a /tmp/android_key; done

You'll end up with a file that probably contains only one entry, since the phone is probably only listening on one port, but it's _guaranteed_ to have the correct key. (The other messages you see are output on STDERR, they don't end up in the file.)

So if the file's contents are:

[1.2.3.4]:1740 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDK01morekeystuffthatisreallyboring
totypeoutlikethisandithinkiwanttostopnowAAAAAAXX

Then you can either:

1. Add just that to known_hosts (cat /tmp/android_key >> ~/.ssh/known_hosts) and know that for that port, at least, you've got the correct entry.
2. Or, duplicate the key for all possible ports:
   sh rm /tmp/android_port_keys for i in $(seq 1739 1764); do \ sed -Ee "s/\]:[0-9]+ ssh-rsa/\]:${i} ssh-rsa/;q" \ < /tmp/android_key >> /tmp/android_port_keys; done # Since /tmp/android_port_keys now contains the correct entries for each port: cat /tmp/android_port_keys >> ~/.ssh/known_hosts
   (The sed command doesn't look at the actual IP address or port number in the file, so it's universal. The ;q on the end forces it to only process the first line, so it's safe even if you have multiple entries in /tmp/android_key — as long as the _first_ entry is the correct key. Meaning, you should still delete any old /tmp/android_key data whenever you want to start the whole keyscan process over again.)

If _nothing_ else is working, it's worth a try, though honestly if you're at that point there's probably some deeper problem than just key management.

(Edit: My first ssh-keyscan command accidentally had 1754 as the high end of the seq range. Corrected to the proper range of 1739–1764.)

[ferdnyc]

(Oh, yes, and if ssh-keyscan doesn't produce _any_ valid host entries, then the problem is with basic SSH connectivity to the device, which means it's nothing to do with GSConnect at all.)

[andyholmes]

Sorry, I got an e-mail for this issue, but it doesn't seem to be showing up in Github. Might be some downtime in Github...

[ferdnyc]

Sorry, I got an e-mail for this issue, but it doesn't seem to be showing up in Github. Might be some downtime in Github...

I had the same thing happen earlier with a query from this morning about a user's Mi5 phone. I figured it was just a since-deleted message.

But I posted a much-longer message an hour ago, so if you can't see that (and a short followup) maybe there is something going on. In which case, you probably can't see this either...

[andyholmes]

Nope, I still can't see the e-mail one, but as soon as I posted the above comment two of yours magically appeared :confused:

[ferdnyc]

#MAGIC

[ferdnyc]

I suppose it's possible my first comment got hung up in some security process along the way, because it included something that looked enough like a valid SSH key to set off alarms. ¯\_(ツ)_/¯

(It was this, now in PNG form for obfuscation purposes:)

---

[andyholmes]

As far I know, it should be under the same PID, but I guess it's possible the Sftp server is secretly forking into the background.

It's pretty hard to figure out what's going wrong here, because I can't reproduce this problem myself. Running adb logcat with no filtering doesn't get me much of anything about SFTP, but that's kind of to be expected if nothing's going wrong. Strictly speaking, the only KDE Connect level error possible is if all ports between 1739-1764 are already bound to a socket.

Of course, it's hard to know everything our reporters here have tried, and if they've uninstalled GSConnect, wiped it's settings, uninstalled the app or cleared the data that makes it harder to find out what's gone wrong. It might even be that the issue happening now is not the original issue.

In the rare case the SFTP plugin has stopped working for me (which hasn't happened in months), the first thing I do is force-quit the app and re-open it. If that doesn't work, I force-quit the app and clear the cache, but never the data.

If that's not solving the problem here, then someone experiencing this bug is probably going to have to dig a little to find the problem. I'd expect that to involve restarting Gvfs with debugging turned on as well as inserting debug messages for each step of the app's SimpleSftpServer.java and probably the SftpPlugin.java. You'd then have to build an APK and install it on your phone.

This not actually all that difficult, given that Android Studio lets you just plug in a Git repo and press "Play" to run it on your phone, but this might not even be a problem with GSConnect or Android given the giant stack of libraries being used to accomplish this. Another reason why I'm happy we're not doing releases for older versions of GNOME anymore :)

[ferdnyc]

^ ...That's actually a response to my latest comment on #706, I'm guessing? (I hope so, because if not then I'm _really_ confused!) #NonSequiturSaysWut?

[andyholmes]

Oh whoops, I thought it was another ghost comment :P

[ioogithub]

So what's happened is that your phone started reporting a different host key with a same IP and GSConnect is refusing to mount it, which is what it should do. Usually GSConnect will wipe all host keys it knows about when this happens, but it's unclear if that's happening or not. You can try doing this manually in a terminal:

$ for i in seq 1739 1764; do ssh-keygen -R [PHONE_IP]:$i; done

So yesterday for some reason the mount worked all day! I didn't do anything and I thought the issue was solved on its own. Then this afternoon it stopped working again. I ran the commend and it did solve the issue, I was able to connect right away. When it stops working again I will run it right away. Maybe I can put it into a script that runs every x minutes and clears the host keys. Any ideas on why the phone would suddenly start reporting a different host key. Could another app by interfering somehow?

Also, if the host key is different then how can gsconnect and the phone do all the handshaking and set up the connection successfully? It looks like like the other functions work, its just the mount that stops working. Is this the only one that is reliant on the SSH host key?

[andyholmes]

Could another app by interfering somehow?

It's possible if you have another SSH server on your phone, but as far as I know KDE Connect runs its own instance.

Also, if the host key is different then how can gsconnect and the phone do all the handshaking and set up the connection successfully? It looks like like the other functions work, its just the mount that stops working. Is this the only one that is reliant on the SSH host key?

These are two different types of keys. KDE Connect uses a TLS certificate, generated with a private key to identify and encrypt device traffic. The SSH host key is a key the SFTP server uses to identify the host, for a connection entirely separate from the device connection.

Generally, the host key is trust-on-first-use, which makes sense given that the connection information for SFTP is transmitted over a TLS encrypted connected already. However, if the host key changes that's usually a bad sign so we consider it fatal.

[ferdnyc]

Could another app by interfering somehow?

It's possible if you have another SSH server on your phone,

Is it? The key should be requested from the app's (non-standard) port, right? So even if another SSH server is running, it _shouldn't_ clash with KDE Connect... theoretically.

@ioogithub One thing you might try, next time this happens: instead of clearing the keys with ssh-keygen -R (or before doing that), use the ssh-keyscan command I mentioned a few comments back to pick up the phone's current key and compare it to the one stored in $HOME/.ssh/known_hosts. If we conclusively determine that they _are_ different, and that's what's causing the failures, then we can try to figure out how and why keys would be changing.

Comparing ssh keys is easy enough to do visually, they're not going to differ by just one or two characters. When two keys don't match, it's going to be pretty obvious.

[andyholmes]

Is it? The key should be requested from the app's (non-standard) port, right? So even if another SSH server is running, it shouldn't clash with KDE Connect... theoretically.

It really depends if it's actually another server. I'm not about to go digging around in the internals of the apache mina server (again), but I wouldn't be totally shocked if it just used worker threads instead of spawning a whole new server process.

[ioogithub]

Okay so this happens once a day at least. It worked all yesterday, I checked it several times but I didn't actually need it.

Today I need to quickly swap a picture to my PC and of course.... it doesn't work.

ferdnyc: I have done what you suggested, I ran ssh-keyscan from your previous comment and I got this key:

when I compare it to the current key in the file $HOME/.ssh/known_hosts:

1|m6EU...yenE= ssh-rsa AAAAB3NzaC...CRWCq/udiD6T

The key is in this file 16 times, it looks like once for each port. I've redacted the middle characters but assuming 1740 is the port, then the part after ssh-rsa is identical. There are preceding characters before the = sha-rsa key in the file that are not present in the output from the command but... aren't these these same keys?

For me this feature is only valuable if it takes less time to use than grabbing a cable and manually transferring the files, unfortunately we aren't there yet. I would like to fix it and have a reliable solution.

So I ran the key clearing command:

# Host [x.x.x.x]:1739 found: line 4
/home/me/.ssh/known_hosts updated.
.. repeat for each port

and this time it did not work. The phone connects, all the functions are there but no Mount. I know for sure this key clearing trick it has worked the last few times I tried it. No messages in the journalctl at all and here is the output from the debug window:

Nov 28 23:43:20 org.gnome.Shell.Extensions.GSConnect[51519]: [/service/protocol/core.js:send:321]: Phone: {
"id": 1575002600044,
"type": "kdeconnect.sftp.request",
"body": {
"startBrowsing": true
}
}

No error messages from kde connect on the phone just a bunch of Permission OKs from the adb logcat --pid=$(adb shell pidof -s org.kde.kdeconnect_tp):

11-28 23:46:07.631 9185 9252 I KDE/LanLinkProvider: Broadcast identity package received from pc
11-28 23:46:07.644 9185 9252 I KDE/LanLinkProvider: Starting SSL handshake with pc trusted:true
11-28 23:46:07.761 9185 29387 I KDE/LanLinkProvider handshake as server successful with pc secured with TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
11-28 23:46:07.761 9185 29387 I KDE/LanLinkProvider: Creating a new link for device e1b2dee9-8fef-4388-b6eb-4b665ecb0913
11-28 23:46:07.762 9185 29387 I KDE/BackgroundService: addLink, known device: e1b2dee9-8fef-4388-b6eb-4b665ecb0913
11-28 23:46:07.767 9185 29387 I KDE/Device: Got certificate
11-28 23:46:07.768 9185 29387 I KDE/Device: addLink LanLinkProvider -> debian active links: 1
11-28 23:46:07.770 9185 29387 I KDE/addPlugin: Permissions OK SftpPlugin
11-28 23:46:07.772 9185 29387 I KDE/addPlugin: Optional Permissions OK SftpPlugin

[andyholmes]

If the app is not responding, then it's definitely a problem on the app-side. Have you tried force stopping the app and reopening it like I suggested?

Ultimately, like I said someone experiencing this is going to have knuckle down and debug the sftp plugin/server to find out where it's failing. Otherwise it's just going to be taking random shots in the dark.

[ioogithub]

Do you mean the sftp part of the app isn't responding? The app does respond when I turn on GSConnect for example, I can observe the app going from the "This paired device is not reachable." screen to the screen with all the functions... Send files, Slideshow remote, Multimedia control, Remote input, Run command etc. When I look at the adb log I can see all the handshaking and it all the Permission OKs, no errors in that log.

I just tried your suggestion. I forced stopped the "This paired device is not reachable." screen for a fraction of a second then it connects.

Do you suspect it is a KDE connect issue at this point or a GSConnect issue? There aren't any errors so its hard to tell.

[andyholmes]

When a client, like GSConnect, sends this packet:

{
"id": 1575002600044,
"type": "kdeconnect.sftp.request",
  "body": {
    "startBrowsing": true
  }
}

The remove device is expected to start an SFTP server and respond with a packet like this:

{
"id": 1574182220122,
"type": "kdeconnect.sftp",
"body": {
  "ip": "x.x.x.x",
  "port": 1747,
  "user": "kdeconnect",
  "password": "xxx",
  "path": "/",
  "multiPaths": [
    "/9C33-6BBD",
    "/primary"
  ],
  "pathNames": [
    "9C33-6BBD",
    "primary"
  ]
  }
}

So if that's not happening, there is nothing more that GSConnect can do. Without that information, it can't mount the remote device.

Since there aren't any errors being printed by the app, either some return value is not being checked or its just failing quietly for some reason. The easiest way to start debugging that is by printing a log message at each step of the app's process that is supposed to start the server, to at least find out where it's failing.

[ferdnyc]

ferdnyc: I have done what you suggested, I ran ssh-keyscan from your previous comment and I got this key:

[x.x.x.x]:1740 ssh-rsa AAAAB3NzaC...CRWCq/udiD6T

when I compare it to the current key in the file $HOME/.ssh/known_hosts:

1|m6EU...yenE= ssh-rsa AAAAB3NzaC...CRWCq/udiD6T

The key is in this file 16 times, it looks like once for each port. I've redacted the middle characters but assuming 1740 is the port, then the part after ssh-rsa is identical. There are preceding characters before the = sha-rsa key in the file that are not present in the output from the command but... aren't these these same keys?

They are, it looks like the .ssh/known_hosts entries are using hashed names — you can add a -H to the ssh-keyscan command to hash the output. e.g.
```sh
$ for i in $(seq 1739 1764); do ssh-keyscan -H -p $i 1.2.3.4; done
````
And then you'd probably find that the entire line is identical down to the last character.

Which means, ultimately, that the keys _aren't_ getting reset or out of sync, and using ssh-keygen -R is either "fixing" the problem only by _coincidence_ (meaning, it's really a timing or repetition issue that has nothing to do with the keys at all), or the act of re-obtaining the host key from the Android server somehow fixes its ssh connectability.

[andyholmes]

...or the act of re-obtaining the host key from the Android server somehow fixes its ssh connectability.

That's an interesting thought, actually. In #706 and another issue, both users reported that as soon as they setup adbto debug the problem solved itself. IIRC, adb does do some host key exchange the first time you set it up.

[ioogithub]

I have a new report. I formatted my phone, setup everything again and tried to get gsconnect running. Just as before, I can pair and connect but the mount doesn't work.

The errors in the log is the first one I originally reported "Host key verification failed". I haven't see this error since the original report. I ran the command:
for i in $(seq 1739 1764); do ssh-keyscan -H -p $i 1.2.3.4; done, no luck.

The phone is answering with this:

Dec 09 12:35:14 org.gnome.Shell.Extensions.GSConnect[31246]: [/service/protocol/core.js:receive/<:275]: Galaxy S8: {
"id": 12345
"type": "kdeconnect.sftp",
"body": {
"ip": "x.x.x.x",
"port": 1742,
"user": "kdeconnect",
"password": "...",
"path": "/",
"multiPaths": [
"/primary"
],
"pathNames": [
"primary"
]
}
}

and it still didn't connect, same errror "Host key verification failed". Tried the command again, no luck.

Next I tried connecting a a cable and running adb. After I ran the command, it cleared out all the entries on each port and I was able to connect.

So maybe running adb is the key to success. Unfortunately, if I have to grab a cable and run adb every time I want to share a file it defeats the utility of this app entirely.

[ioogithub]

After I got the mount working, I also tried the clipboard sync, in both directions. It doesn't work, no errors.

Then I tried the share function. I can share a file from Android to PC but I can't share from PC to Android, same as mount, no errors, nothing happens.

Edit: I tried disconnecting and trying again and now I am able to share both directions. The clipboard sync still isn't working however.

[ferdnyc]

Next I tried connecting a a cable and running adb. After I ran the command, it cleared out all the entries on each port and I was able to connect.

Yeah, as @andyholmes mentioned in https://github.com/andyholmes/gnome-shell-extension-gsconnect/issues/711#issuecomment-559900913 we've had reports of the same thing from other users. We're just still not sure _why_.

So maybe running adb is the key to success. Unfortunately, if I have to grab a cable and run adb every time I want to share a file it defeats the utility of this app entirely.

Agreed, that's not a tenable situation, and certainly not how it's _intended_ to function. The core problem is a bug, and running adb to avoid the bug doesn't even qualify as a workaround, it's merely a (potentially major) piece of evidence regarding the nature of the bug.

[andyholmes]

I have a new report. I formatted my phone, setup everything again and tried to get gsconnect running. Just as before, I can pair and connect but the mount doesn't work.

To clarify, in case it is still not obvious, this is why the Host Key verification fails. Clearing the app data, re-installing the app or formatting your phone will cause Host Key failures. Under no circumstances will re-installing the app or erasing the app data fix this problem.

The host key is the first step to establishing the identity of the remote SSH connection, followed by private key or password authentication. If the host key authentication fails, we bail on purpose.

[ferdnyc]

I tried to find any indication that the adb tool would mess with the SSH credentials handling in _any_ way, even going so far as to strace the process in a variety of different scenarios, and I can't find any signs that happens. The $HOME/.ssh/known_hosts file was untouched from a backup I made of it before I started, and it never gave any indications of having anything to do with the .ssh directory.

Not from the _Linux_ side, anyway. What the Android end could be doing is of course another matter. And, it's worth noting, I _wasn't_ having any SSH connectivity problems even before starting these tests. But it does seem more likely that the issue, whatever it is, is occurring — and thus, subsequently being solved (accidentally or deliberately) — on the Android end of things.

[andyholmes]

Is the original bug here still valid? It's unclear at this point if the host key failures are being caused by the Android client repeatedly being re-installed, or if there's a genuine bug being experienced on our end.

[andyholmes]

Closing due to inactivity, and probably this as not our fault anyways :)