On Mon, 4 Nov 2019 at 14:07, David Newall <openssh at davidnewall.com> wrote:> [about scp] That's just awful, and I should have > thought it was not at all necessary. Am I missing something? >If you're saying that the scp protocol is an unfixable mess then the openssh team has been agreeing[0] with you for at least a decade and a half. We fix what we can, but some parts can't be fixed. [0] eg https://marc.info/?l=openssh-unix-dev&m=104157774216425&w=2 -- Darren Tucker (dtucker at dtucker.net) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
On 2019/11/04 14:28, Darren Tucker wrote:> On Mon, 4 Nov 2019 at 14:07, David Newall <openssh at davidnewall.com> wrote: > > > [about scp] That's just awful, and I should have > > thought it was not at all necessary. Am I missing something? > > > > If you're saying that the scp protocol is an unfixable mess then the > openssh team has been agreeing[0] with you for at least a decade and a > half. We fix what we can, but some parts can't be fixed. > > [0] eg https://marc.info/?l=openssh-unix-dev&m=104157774216425&w=2At various times I've tried to use sftp instead of scp but it never lasted long. Remembering to type sftp instead of scp isn't so bad, but file uploads are really hard to work with, I don't think it's possible to get good finger memory for "echo 'put somefile' | sftp hostname:/tmp/" (and it's even worse when copying out multiple files). I'm sure it's already been considered, but from a user perspective it would be very convenient if we could have essentially the command-line interface of scp(1) (with divergence for filename escaping) but using the SFTP protocol.
On Mon, Nov 4, 2019 at 7:34 AM Stuart Henderson <stu at spacehopper.org> wrote:> > On 2019/11/04 14:28, Darren Tucker wrote: > > On Mon, 4 Nov 2019 at 14:07, David Newall <openssh at davidnewall.com> wrote: > > > > > [about scp] That's just awful, and I should have > > > thought it was not at all necessary. Am I missing something? > > > > > > > If you're saying that the scp protocol is an unfixable mess then the > > openssh team has been agreeing[0] with you for at least a decade and a > > half. We fix what we can, but some parts can't be fixed. > > > > [0] eg https://marc.info/?l=openssh-unix-dev&m=104157774216425&w=2 > > At various times I've tried to use sftp instead of scp but it never lasted > long. Remembering to type sftp instead of scp isn't so bad, but file > uploads are really hard to work with, I don't think it's possible to get > good finger memory for "echo 'put somefile' | sftp hostname:/tmp/" (and > it's even worse when copying out multiple files). > > I'm sure it's already been considered, but from a user perspective it > would be very convenient if we could have essentially the command-line > interface of scp(1) (with divergence for filename escaping) but using > the SFTP protocol.Filesystem limitations for files with ':' in them are a real problem. The much simpler solution is that 'if it hurts when you put a pointy thing in your eyeball, stop putting a pointy thin in your eyeball", not to try to armor the eyeball. In this case, stop creating files with ':' in the filename. That said, David, you *might* have some success with using rsync over SSH to transmit such files. But I make no promises.
That's why rsync is the better alternative to scp/sftp ... it does uploads and downloads with the same sane syntax, and does recursive, permissions, and doesn't need to upload/download everything again when re-trying :) rscynv -vPar <source> <dest> On Mon, Nov 4, 2019 at 1:35 PM Stuart Henderson <stu at spacehopper.org> wrote:> On 2019/11/04 14:28, Darren Tucker wrote: > > On Mon, 4 Nov 2019 at 14:07, David Newall <openssh at davidnewall.com> > wrote: > > > > > [about scp] That's just awful, and I should have > > > thought it was not at all necessary. Am I missing something? > > > > > > > If you're saying that the scp protocol is an unfixable mess then the > > openssh team has been agreeing[0] with you for at least a decade and a > > half. We fix what we can, but some parts can't be fixed. > > > > [0] eg https://marc.info/?l=openssh-unix-dev&m=104157774216425&w=2 > > At various times I've tried to use sftp instead of scp but it never lasted > long. Remembering to type sftp instead of scp isn't so bad, but file > uploads are really hard to work with, I don't think it's possible to get > good finger memory for "echo 'put somefile' | sftp hostname:/tmp/" (and > it's even worse when copying out multiple files). > > I'm sure it's already been considered, but from a user perspective it > would be very convenient if we could have essentially the command-line > interface of scp(1) (with divergence for filename escaping) but using > the SFTP protocol. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >-- Mark Janssen -- mark at sig-io.nl Unix / Linux Open-Source and Internet Consultant
On 11/04/2019 01:25 PM, Stuart Henderson wrote:> I'm sure it's already been considered, but from a user perspective it > would be very convenient if we could have essentially the command-line > interface of scp(1) (with divergence for filename escaping) but using > the SFTP protocol.Agreed, but it essentially means to fix a server-side threat with changes (that mainly happen) on the client side. In instances of cross-organization data transfers with established multi-tenant servers, that might not be a practical option. On the other hand, if it were possible to set a server account's login shell or ForceCommand to an "scpd", and thus completely cut out the normal shell ... (Yes, I'm aware that that'd likely entail re(?)implementing the entire server-side wildcard expansion within that executable. Given that different-OS shells' wildcard expansion is a known source of confusion, that doesn't seem like the worst idea ever, though, if I may say so.) Regards, -- Jochen Bern Systemingenieur Binect GmbH Robert-Koch-Stra?e 9 64331 Weiterstadt