SFTP uploads fail on SFTP Server freeFTPd

[grajagopal-cmtelematics]

Hi,

I encountered a compatibility issue while using sftpretty against a legacy SFTP server freeFTPd 1.0. Needing your support here.
NOTE: The same issue doesn't appear when using pysftp with the same underlying paramiko

Code snippet that caused this issue.

        upload_folder_path = posixpath.dirname(upload_path)
        self.conn.mkdir_p(remotedir=upload_folder_path)
        self.conn.put(
            localfile=local_path,
            remotepath=upload_path,
            confirm=self.config.confirm
        )

Error snapshot

[chan 0] Opened sftp connection (server version 3)
Channel Name: [636641c1aee34537b02f02f8a89107ac]
Current Working Directory: [In]
Secsh channel 1 open FAILED: : Connect failed
Traceback (most recent call last):
  File "xxx", line 20, in _upload_single_file
    self.conn.put(
  File "/usr/local/lib/python3.10/site-packages/sftpretty/__init__.py", line 804, in put
    return _put(self, localfile, remotepath=remotepath, callback=callback,
  File "/usr/local/lib/python3.10/site-packages/sftpretty/__init__.py", line 765, in _put
    with self._sftp_channel() as channel:
  File "/usr/local/lib/python3.10/contextlib.py", line 135, in __enter__
    return next(self.gen)
  File "/usr/local/lib/python3.10/site-packages/sftpretty/__init__.py", line 306, in _sftp_channel
    raise err
  File "/usr/local/lib/python3.10/site-packages/sftpretty/__init__.py", line 292, in _sftp_channel
    _channel = SFTPClient.from_transport(self._transport)
  File "/usr/local/lib/python3.10/site-packages/paramiko/sftp_client.py", line 164, in from_transport
    chan = t.open_session(
  File "/usr/local/lib/python3.10/site-packages/paramiko/transport.py", line 875, in open_session
    return self.open_channel(
  File "/usr/local/lib/python3.10/site-packages/paramiko/transport.py", line 1006, in open_channel
    raise e
  File "/usr/local/lib/python3.10/site-packages/paramiko/transport.py", line 2055, in run
    ptype, m = self.packetizer.read_message()
  File "/usr/local/lib/python3.10/site-packages/paramiko/packet.py", line 459, in read_message
    header = self.read_all(self.__block_size_in, check_rekey=True)
  File "/usr/local/lib/python3.10/site-packages/paramiko/packet.py", line 303, in read_all
    raise EOFError()
EOFError

[byteskeptical]

You're not giving me much to go on. What version of FreeFTPd 1.0.? I don't have access to a FreeFTPd server to test against and looking up old changelog posts on their now offline site wasn't much help. There is a hint though, you seem to be making an initial connection just fine according to the log:

[chan 0] Opened sftp connection (server version 3)
Channel Name: [636641c1aee34537b02f02f8a89107ac]

On attempting to create a second channel for the upload is where you get a failed connection. It seems this version or perhaps all versions of FreeFTPd don't support channels or perhaps this server has a multiple connections limit. Either way pysftp working makes sense as it uses a single connection for its operations.

[byteskeptical]

@grajagopal-cmtelematics ping

[grajagopal-cmtelematics]

Hi @byteskeptical,

Apologies for the delayed response. As you correctly pointed out, the issue was due to multiple channel opening attempts, which freeFTPd does not support, as confirmed by the logs.

Is there a way to disable this behaviour via a configuration flag (may be like passing things into cnopts as we'd do in pysftp)? That would be very helpful.

We encountered this problem while uploading to a customer’s legacy SFTP server, to which we do not have administrative access.

Thanks

[byteskeptical]

Unfortunately not currently. I'm not against it but would have to be implemented without affecting the default threaded preformance. That being said it hasn't been a previous request and I'm not sure how useful it would for others without trying to be dismissive of your plight. If I find some time, I will give it a try but make no commitment.

[byteskeptical]

There is now a path forward for this if you are still interested. Unfortunately I don't have a sftp server with these limitations to test. I've tried to mock one but I suspect the real thing may apply the limits at different points in the connection flow.