On 11/6/24 8:07 PM, Damien Miller wrote:> On Wed, 6 Nov 2024, Chris Rapier wrote:
>
>> I think I know the answer to this (which would be that you can't)
but is there
>> any not entirely insane way to get the ssh->compat information back
to either
>> scp or sftp?
>
> There's no way at present.
That's what I thought.
>> I'm doing some extensions on scp (and eventually sftp) and having
remote
>> version or capability information would be helpful.
>
> IMO it would be easier for SFTP, as the protocol has an explicit
> extension mechanism. If you're prepared to trust this mechanism
> to make assertions about the SSH channel the SFTP session is
> running over, then it would be very easy to wire it up to make
> changes to buffer sizes, the number of requests in flight, etc.
> as these are already configurable.
I'll be looking into that.
The background is that a few year ago I introduced a method to restart
failed transfers in HPN-SSH. Some of the people I'm dealing with are
moving files that are 10s of GB in size so anything that can reduce the
retransmission of already received data can be helpful. It's similar to
rsync in that we use hashes to determine if the file fragment (assuming
that the transfer cut out mid-file) is identical to the corresponding
fragment on the source side. If it is then we start the transfer from
the last received byte and append to the destination. I had been using
Blake2b512 for the hashing algorithm but I want to put in a path to use
xxhash instead. Maintaining backward compatibility means I need to know
something about the remote. Hence, the question. I think I have an idea
that might work but it's hacky. Alternatively, I can just break
compatibility as I am not convinced a lot of people use this function in
its current state. Especially being that people should just use rsync :)
Also, the work required to do this in SCP really helped my understand
why you want to stop supporting SCP.
Chris