TeamAmaze / AmazeFileManager

Material design file manager for Android
https://teamamaze.xyz
GNU General Public License v3.0
5.1k stars 1.54k forks source link

v3.10 breaks SSH connections #4081

Open Fmstrat opened 3 months ago

Fmstrat commented 3 months ago

Describe the bug When using SSH connections, either the system can't validate the host key, or the second folder deep shows no files.

To Reproduce Problem 1: Steps to reproduce the behavior:

  1. Connect to SSH server connection that goes direct to a path like /storage
  2. Get list of folders
  3. Choose any sub folder
  4. No files are displayed

Problem 2:

  1. Connect to another SSH server
  2. Get:
    ComposedException 1 :
    net.schmizz.sshj.transport.TransportException: [HOST_KEY_NOT_VERIFIABLE] Could not verify `ssh-ed25519` host key with fingerprint `...` for `...com` on port 1028

Expected behavior Functional SSH with existing connections after upgrade

Smartphone (please complete the following information):

VishalNehra commented 3 months ago

@TranceLove

Fmstrat commented 3 months ago

Any news on this? Trying to hold off on Google updates since this breaks a primary use case. Thanks!

TranceLove commented 3 months ago

Short answer: #4101 to the fix.

Longer answer: #4101 seems fix the problem, but this is to revert the change we did before to make other things work. Still running the regressions when I'm free, but not very satisfying. So I think for the time being the best workaround would be refrain from using SSH connections with default path to open, i.e. just browse from the root.

Even longer answer: deep down the classes, the culprit was the way lookup the connection parameters and connection instance from the connection pool, when the connection string in database has default path to open included, e.g.

ssh://user@127.0.0.1:22222/home/user

When the user opens /home/user/subfolder, current codebase has problem looking up connection with ssh://user@127.0.0.1:22222/home/user/subfolder.

I'm seeing some refactoring required to accommodate this, like separating the base URI and default path, so code can always lookup the connection using ssh://user@127.0.0.1:22222.

Otherwise, as a band-it solution, we deduct the path elements one by one, and try to match the connection string with database and connection pool until there is one; but this is inefficient and IMO not a good approach.

On the other hand, we may just drop the connection pool and use singletons to store the SSH/FTP connections instead. We have only 2 tabs, and perhaps 90% usecases we are copying files between device and remote server, but not between remote servers, so this might work as well. But this is refactoring equally expensive as the above "split URI to base path and default path" method.

Fmstrat commented 3 months ago

Thank you! The default path info is helpful as that allows me to upgrade, too.