ssh compat information

[Chris Rapier]

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