4 ms·

They plan to deprecate scp the protocol, not scp the tool, which will use SFTP under the hood.

by exitb 5y ago

perbu 5y ago
I'm pretty sure scp isn't a protocol. It is just a tool that relies on doing a request for execution over the regular ssh2 protocol. I've written a few custom ssh servers and you don't really need to do anything to them to support scp. sftp uses the sftp subsystem. scp just uses regular ssh requests and transports data over the ssh channels.
- deleted 5y ago
  [deleted]
- yakubin 5y ago
  See <https://en.wikipedia.org/wiki/Secure_copy_protocol https://en.wikipedia.org/wiki/Secure_copy_protocol> SFTP also transports data over SSH channels.
  - perbu 5y ago
    I guess you can call it a (application) protocol. However, when implementing this I've not needed to anything to make scp works as opposed to anything else. Just supporting ssh executions requests and connecting the channels as you do with any remote invocation.
pilif 5y ago
the only snag about this plan is that the old `scp` tool works with any server, whereas the new tool will require additional configuration on the server to enable SFTP. It's not enabled by default in some distributions and many "how to secure your server" guides recommend disabling it/keeping it disabled due to the best practice of only enabling necessary services. This will break `scp` for many corporate cases (where arguing that sftp is necessary is an impossible fight)
- tialaramex 5y ago
  The fact scp "worked" illustrates that such "How to secure your server" guides are... at best... poorly thought out. If "remote file access" is not in fact a "necessary service" then you can't very well allow scp to work, and thus you can't allow basic ssh service. Actually a more sane setup, which I've used, is only SFTP is enabled, no shells. You can fetch files, you can send files, but you can't... for example... run a race exploitation shell script to seize root permissions. This also has the advantage that if we can only send and receive files, the "server" we're connecting to needn't really exist, like an HTTP virtual host it's just a bunch of "files" and could actually be backed by a database with some blob tables. There's a lot of scp usage in a typical corporate environment that should actually be files living in a shared filestore anyway, I've seen way too many files which ought to actually be: * A wiki entry * Checked into a git repository * Shared in some cloud service e.g. OneCloud ... but instead they live on Steve's F:\Documents and if Steve is off sick well, here's the copy I made last week, I hope it isn't missing any important updates and somebody make sure Steve gets this when we change it... The file living in /usr/project/ on testserver03 instead of F:\Documents on Steve's laptop is not a real improvement.
- disruptiveink 5y ago
  You're actually making the opposite argument that you think you're making: if the scp command stops working, from a "corporate" perspective, from all intents and purposes, it means that "our server no longer works with scp due to an update". Regardless of implementation details, the opposite will then happen: whoever is in charge will request for "SCP to be fixed", which will actually mean turning on SFTP support. Removing options from "corporate" users usually results in saner choices being made, because you stop being able to bikeshed the implementation details. People have a server and they need a way to transfer files. If you have two protocols that can be used, arbitrary decisions will be made. If the readily available tools all break, there is no more decision to be made – whatever needs to be enabled will be enabled.
  - pilif 5y ago
    if regular ssh is available, nothing stops people from building pipes with tar on both ends. This will be integrated into additional tools (future "show HN - scp replacement written in $FANCY_LANGUAGE that works even when sftp is disabled") and will be the "new way" of doing things because it won't require any configuration change on the server. Never underestimate the inertia of server configurations.

They plan to deprecate scp the protocol, not scp the tool, which will use SFTP under the hood.

by exitb 5y ago

They plan to deprecate scp the protocol, not scp the tool, which will use SFTP under the hood.

I'm pretty sure scp isn't a protocol. It is just a tool that relies on doing a request for execution over the regular ssh2 protocol. I've written a few custom ssh servers and you don't really need to do anything to them to support scp. sftp uses the sftp subsystem. scp just uses regular ssh requests and transports data over the ssh channels.

deleted 5y ago
[deleted]
yakubin 5y ago
See <https://en.wikipedia.org/wiki/Secure_copy_protocol https://en.wikipedia.org/wiki/Secure_copy_protocol> SFTP also transports data over SSH channels.
- perbu 5y ago
  I guess you can call it a (application) protocol. However, when implementing this I've not needed to anything to make scp works as opposed to anything else. Just supporting ssh executions requests and connecting the channels as you do with any remote invocation.

pilif 5y ago

the only snag about this plan is that the old `scp` tool works with any server, whereas the new tool will require additional configuration on the server to enable SFTP. It's not enabled by default in some distributions and many "how to secure your server" guides recommend disabling it/keeping it disabled due to the best practice of only enabling necessary services. This will break `scp` for many corporate cases (where arguing that sftp is necessary is an impossible fight)

tialaramex 5y ago
The fact scp "worked" illustrates that such "How to secure your server" guides are... at best... poorly thought out. If "remote file access" is not in fact a "necessary service" then you can't very well allow scp to work, and thus you can't allow basic ssh service. Actually a more sane setup, which I've used, is only SFTP is enabled, no shells. You can fetch files, you can send files, but you can't... for example... run a race exploitation shell script to seize root permissions. This also has the advantage that if we can only send and receive files, the "server" we're connecting to needn't really exist, like an HTTP virtual host it's just a bunch of "files" and could actually be backed by a database with some blob tables. There's a lot of scp usage in a typical corporate environment that should actually be files living in a shared filestore anyway, I've seen way too many files which ought to actually be: * A wiki entry * Checked into a git repository * Shared in some cloud service e.g. OneCloud ... but instead they live on Steve's F:\Documents and if Steve is off sick well, here's the copy I made last week, I hope it isn't missing any important updates and somebody make sure Steve gets this when we change it... The file living in /usr/project/ on testserver03 instead of F:\Documents on Steve's laptop is not a real improvement.
disruptiveink 5y ago
You're actually making the opposite argument that you think you're making: if the scp command stops working, from a "corporate" perspective, from all intents and purposes, it means that "our server no longer works with scp due to an update". Regardless of implementation details, the opposite will then happen: whoever is in charge will request for "SCP to be fixed", which will actually mean turning on SFTP support. Removing options from "corporate" users usually results in saner choices being made, because you stop being able to bikeshed the implementation details. People have a server and they need a way to transfer files. If you have two protocols that can be used, arbitrary decisions will be made. If the readily available tools all break, there is no more decision to be made – whatever needs to be enabled will be enabled.
- pilif 5y ago
  if regular ssh is available, nothing stops people from building pipes with tar on both ends. This will be integrated into additional tools (future "show HN - scp replacement written in $FANCY_LANGUAGE that works even when sftp is disabled") and will be the "new way" of doing things because it won't require any configuration change on the server. Never underestimate the inertia of server configurations.