SFTP over OpenSSH server doesn't work about amazefilemanager HOT 16 OPEN

@TranceLove ping

from amazefilemanager.

Developer's self-note

From https://pastebin.com/RSz4EMUZ it seems you're using the OpenSSH server provided by Windows. The version string SSH-2.0-OpenSSH_for_Windows_8.6 suggested the repo https://github.com/PowerShell/Win32-OpenSSH

IIRC there were similar reports about using Amaze FM with OpenSSH server on Windows, though that was with 3rd party implementations, and seems problem was with "chrooting" specified directory. This error log seems not the same case 🤔

from amazefilemanager.

@TranceLove,

I'm using a password-protected, ed25519 SSH private key, which is stored locally on the phone's internal storage

from amazefilemanager.

Also, here's a speed comparison between SFTP in Termux, which basically saturates the wireless connection downloading a file

Then there's Amaze, performing 20x slower

from amazefilemanager.

My quick test with passphrase protected ed25519 keys against the same NixOS appliance and same OpenSSH server, even with conventional ssh command didn't work. I also tried using ssh-agent, I did got the passphrase prompt to decrypt the key, but upon connecting I ended up getting the password prompt, i.e. server isn't accepting the key.

Maybe it is only looking at the authorized_keys file in /etc/ssh/authorized_keys.d/$USER?

Maybe try this in your configuration.nix (and then rebuild-switch before testing again)

  users.users.demo = {
    description = "Demo User";
    openssh.authorizedKeys.keys = [
     # paste your SSH public key here, between double quotes, like this:
      "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICMDqtqzdBywVWHbIMv/rOGWHb0xBHisyqsa8ZbITxjY demo@nixos"
    ];
  };

from amazefilemanager.

Looking at the upstream SSHJ issue tracker, it seems others are also observing the same slowness symptoms: SSHJ issue 688

from amazefilemanager.

Hi,

I'm facing the same issue using a Linux OpenSSH daemon/sftp server. My client device is a Samsung Note 9 (Amaze v3.10, F-Droid), server is NixOS (OpenSSH_9.6p1, OpenSSL 3.0.13 30 Jan 2024).

from amazefilemanager.

On Amaze 3.8.2 it worked exactly once, was very slow (10Mbps download on a 300Mbps link) and then doesn't connect again or display the same error

from amazefilemanager.

For @KhalilSantana 's report, my quick test of listing files and copy file, using current release/4.0 codebase (which I worked on #3656) against the NixOS 23.11 VM appliance with the same version of OpenSSH server (9.6p1 with OpenSSL 3.0.13), seems working on my side.

I'm using password authentication. May perhaps more details on reproducing your symptom will be more helpful.

from amazefilemanager.

@TranceLove,

I'm using a password-protected, ed25519 SSH private key, which is stored locally on the phone's internal storage

My quick test with passphrase protected ed25519 keys against the same NixOS appliance and same OpenSSH server, even with conventional ssh command didn't work. I also tried using ssh-agent, I did got the passphrase prompt to decrypt the key, but upon connecting I ended up getting the password prompt, i.e. server isn't accepting the key.

Upstream sshj library does support passphrase protected ed25519 keys - I did wrote an unit test as well.

So I think it's more a protocol wise problem rather than Amaze's own.

Sorry but if there's a combination that will work, I'll be glad to look into it.

(Answer re: slow I/O problems in next comment)

from amazefilemanager.

Re @lensaj 's problem, I made a quick test with Windows's own OpenSSH installed via optional features in Windows 11. Copy/move files did worked for me with current release/4.0 codebase, even when there's a colon in the file path, like C:/Documents and Settings

So my next guess would be the code parsing the paths. No need to know what's in the file, but I would like to know the path of the file in question - possible that some special characters I'm unaware of 🥲

from amazefilemanager.

My quick test with passphrase protected ed25519 keys against the same NixOS appliance and same OpenSSH server, even with conventional ssh command didn't work. I also tried using ssh-agent, I did got the passphrase prompt to decrypt the key, but upon connecting I ended up getting the password prompt, i.e. server isn't accepting the key.

Maybe it is only looking at the authorized_keys file in /etc/ssh/authorized_keys.d/$USER?

Maybe try this in your configuration.nix (and then rebuild-switch before testing again)

  users.users.demo = {
    description = "Demo User";
    openssh.authorizedKeys.keys = [
     # paste your SSH public key here, between double quotes, like this:
      "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICMDqtqzdBywVWHbIMv/rOGWHb0xBHisyqsa8ZbITxjY demo@nixos"
    ];
  };

If according to https://nixos.wiki/wiki/SSH_public_key_authentication, NixOS does honour $HOME/.ssh/authorized_keys although doing this way would go against their idea of reproducible builds of the OS using centralized config.

I just also tried key-based authentication with ed25519 key without passphrase, and by pasting the public key to $HOME/.ssh/authorized_keys authentication did went through.

from amazefilemanager.

Re: slow file I/O over SSH, unfortunately I think this is the best we can do given the available resources and knowledge :/

With #3829 I made a few changes apart from fixing problems, also to prevent parallel file I/O over SSH which would made I/O performance even worse. Then the rest, with the current stream-based I/O between upstream sshj and Amaze, IMO I'm seeing little room for improvement, if large scale code optimization is not possible at the moment.

Possible to use native (C/Go/Rust-based?) I/O, but that's completely other story then...

from amazefilemanager.

I made use of RemoteFile.ReadAheadRemoteFileInputStream too

Perhaps we may adjust the size of BufferedInputStream - from the comment in sshj/688 it makes a buffer of 1024*1024 = 1048576 = 1MB while we have only 64KB 🤦‍♂️ (DEFAULT_TRANSFER_QUANTUM below is 65536)

from amazefilemanager.