I wonder why OpenSSH doesn’t attempt to negotiate with its peer to find a usable protocol. Is it an intentional security thing? IIRC SSH does all sorts of negotiation of other types when connecting (key type, auth method, etc)
It's an intentional security thing. If the sftp subsystem command failed OpenSSH could fall back to scp automatically, but there are some security issues with that. Certain semantics, e.g. file name expansions, differ between scp and sftp on the backend, with the potential for some (theoretical?) exploits. IIRC, in particular, scp is invoked on the server through the shell, passing file names and commands as parameters, with shell expansion occurring. Whereas sftp commands are issued in-band to the remote sftp subsystem using an additional protocol layer. (In theory the sftp protocol could be wrapped in TLS; it's independent of the SSH protocol itself.)
> The legacy SCP protocol (selected by the -O flag) requires execution of the remote user's shell to perform glob(3) pattern matching. This requires careful quoting of any characters that have special meaning to the remote shell, such as quote characters.
so I guess it is defending about theoretical problem where you use sftp-compatible quoting that silently breaks if you use same commands against scp script, still would be nice to have global config for scp fallback.
(Sorry, I hate that it has a political reference, but it's really how I feel about this. How the heck is that error message supposed to mean anything to anyone?)
I wonder why OpenSSH doesn’t attempt to negotiate with its peer to find a usable protocol. Is it an intentional security thing? IIRC SSH does all sorts of negotiation of other types when connecting (key type, auth method, etc)
It's an intentional security thing. If the sftp subsystem command failed OpenSSH could fall back to scp automatically, but there are some security issues with that. Certain semantics, e.g. file name expansions, differ between scp and sftp on the backend, with the potential for some (theoretical?) exploits. IIRC, in particular, scp is invoked on the server through the shell, passing file names and commands as parameters, with shell expansion occurring. Whereas sftp commands are issued in-band to the remote sftp subsystem using an additional protocol layer. (In theory the sftp protocol could be wrapped in TLS; it's independent of the SSH protocol itself.)
There are some caveats to it
> The legacy SCP protocol (selected by the -O flag) requires execution of the remote user's shell to perform glob(3) pattern matching. This requires careful quoting of any characters that have special meaning to the remote shell, such as quote characters.
so I guess it is defending about theoretical problem where you use sftp-compatible quoting that silently breaks if you use same commands against scp script, still would be nice to have global config for scp fallback.
Honestly from the domain I figured this was going to be a Xorg/Wayland/XWayland issue
Make Error Messages Great Again
(Sorry, I hate that it has a political reference, but it's really how I feel about this. How the heck is that error message supposed to mean anything to anyone?)
Sometimes the message is different. I think it depends on the recipient server. Trying to scp to a dropbear ssh server on a router gives
The -O resolution works.Yeah, regardless of how one feels about the design decision to fail without fallback, the messaging seems like an oversight.