Hacker News Reader

Comment by edwintorok | Hacker News Reader

IIUC the `scp` cmdline will still exist it'll just use the sftp protocol behind the scenes instead of the eco protocol. Note that the deprecation is about the protocol not the cli.

View on HN

I doubt this will be accepted.

It'll break a lot of valid functionality that relies on it, and the only case I can see presented as to why is for situations when servers choose to offer scp when they should have chosen to offer sftp.

Complaining that some people hand out shell access and this creates a "problem" that they gave people access to shell commands verges on ridiculous.

It looks like the openssh main dev is positive about this change: https://github.com/openssh/openssh-portable/pull/194#pullreq...

That sounds like it will probably be accepted after a few more minor fixes.

You can deprecate something while still letting people add it back into their PPA manually. If you absolutely need an deprecated tool, no one's going to stop you: it's linux. Heck, just com,pile it from source and be on your merry unsupporteed way.

Yeah, and lose the security updates?

I much prefer the status quo. Don't agree that this change is necessary.

The scp protocol is literally deprecated: what do you not agree with? The idea (and already being worked on) is to change the scp command's underlying code so that it behaves exactly the same as before, all your scripts will keep working just fine, it just won't use the now dead scp protocol under the hood and will instead use the universally supported sftp protocol.

The replacement scp was described as not even being an official project of OpenSSH, so it's not being officially replaced.

Is that not correct?

And you don't deprecate a 25-year old utility with just a replacement "idea".

So... have you heard of wayland? If X11 can be deprecated without a drop-in replacement, then scp is pretty much doomed.

X11 has not been deprecated. It is still actively developed. The most recent commit was 23 hours ago. [1]

[1]: https://cgit.freedesktop.org/xorg/lib/libX11

I think these are the articles that craftinator was referring to:

https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server... https://news.ycombinator.com/item?id=24920183 https://www.phoronix.com/scan.php?page=news_item&px=XServer-... https://news.ycombinator.com/item?id=24884988

Having servers offer scp instead of ssh is not the only problem.

What about this part of the article:

Finally, while the danger is remote, it is worth noting that a local file name containing `backticks` (a file named `touch you-lose`, for example) will be handled the same way on the other end; if a user can be convinced to perform a recursive copy of a directory tree containing a file with a malicious name, bad things can happen.

Which probably won't work in a lot of cases. I just got burned by the very minimal raspian ssh server they ship by default.

First it didn't support the authentication method I wanted to use, and then it didn't have any port forwarding ability. I'm betting it doesn't have sftp support either.

Yes, many embedded devices run Dropbear where built-in scp support is often enabled. But most systems probably won't have sftp binary from openssh installed ( https://openwrt.org/docs/guide-user/services/nas/sftp.server )

In practice many times I end up using:

    ssh cat /foo/bar > /bar/baz 
    ssh tar c /foo | tar x -C /bar

mostly because variants such as vagrant ssh or docker-machine ssh, cross-product with the remote target being any weird platform like solaris or a limited busybox or has sftp disabled

In practice, tar c | ssh tar x can actually be far faster than scp -r, especially when you have a lot of small files.

I've found many people either forget (or never knew) that pipes have a buffer, and that buffers are very useful when you are dealing with potentially bursty throughput.

In a previous team where we dealt with shipping around lots of ZFS snapshots (where both the performance of reading from disk can vary based on the ARC and filesystem metadata) and occasionally using VPN tunnels on public internet links, pv to get even larger pipe buffers than standard was often a huge performance equalizer. Readers read as fast as they can, writers write as fast as they can, and the buffer massages any variability in the middle.

https://linux.die.net/man/1/pv

It's not just the buffer, it is the PIPE. Specifically, pipelining that streams one file after another, without an idle period of waiting for the round-trip acknowledgements of one file receipt prior to sending the next. Using rsync over ssh has the same massive benefit for transferring many files, even if there is no existing data to make use of its differential transfer mechanisms.

(Those extra mechanisms are usually beneficial in WAN scenarios as well, except when you have high speed links, in which case blasting the full files may be faster than doing the IO to figure out comparisons and skip transfer.)

Edited: adjusted confused punctuation.

I’ve also used

   dd if=filename | ssh hostname dd of=remote_filename

Quite a bit

There's something a little badass about using dd to transfer a file to a remote system.

Everything is a file!

I was transferring files to an Android device, and adb push wasn't working for some reason. It would hit an error and kill the adb connection until I re-plugged the USB.

Somehow this worked:

    dd if=foo | adb shell dd of=/storage/.../foo

Huh, pleasantly surprised to learn that dd correctly handles the truncated final block of a not-multiple-of-512-byte file; could have sworn that didn't work at some point.

SUS specifies that dd should do the "right thing" with input with non-integer number of blocks input, that is pad it with zeros if conv=sync, just pass through shorter otherwise.

> SUS specifies that dd should do the "right thing"

A example the C standard could stand to learn from, then.

Ah yes, that one too. Used it a couple of times straight with a /dev/sda to best effort salvage data from a broken but running remote system I knew would not reboot as is.

Why not just

  cat file | ssh user@host 'cat >file'
  ssh user@host cat file | cat >file

PS.

I use mc to copy: F5, Enter.

Cause when I younger I didn’t know how to pipe like that and dd just worked. It’s kinda stuck with me and there isn’t much a different imo

Thanks for clarifying. I felt the same as OP above. The title of this post totally through me off.

Scp itself is/will be deprecated.

(But not deleted for now)

A new command with similar cli but different name is in process but it will not (and can't) support all features of scp so it can't be a drop in replacement and as such you can't name it scp as this would brake existing systems.

I forsee a new alias in my .bashrc

Thanks for pointing that out, even after reading the article I had not understood that to be the case. I suspect doing so will have issues of its own however.

I agree; the headline simply says "deprecating scp" which suggests that the command "scp" would be deprecated :)

Reply on news.ycombinator.com