similar to: scp -t - revisited.....

>From the testing that I've done so far, using the command= restriction essentially ignores any and all attempts by the client to send different remote filenames, directory commands, etc... using scp -i some_key localfile remotehost:../../../../../../../../../../tmp/file places a copy of the file named "localfile" in the directory specified in the command= line of the

Thanks to J.P. I now have a better understanding of how scp really works. I haven't uncovered any dark secrets, or unintended capabilities, I just prevented scp from sending the proper commands via ssh to the remote server. In essence, I gave scp a lobotomy or short-circuit. Either way, it's useful and gives me the desired effect. I don't know if anyone else would find this

https://bugzilla.mindrot.org/show_bug.cgi?id=1989 Bug #: 1989 Summary: SCP wihout a source path Classification: Unclassified Product: Portable OpenSSH Version: 4.3p2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: unassigned-bugs

Hi, I'm having trouble finding the correct syntax to scp between two remote hosts with non-defaults ports. <scp -P 1234 user at remotehost:/sourcefile -P 4321 user at remotehost:/destfile> No matter what i've tried i cant get scp to connect both servers with different ports. Is this even possible? The workaround i've found is to use <ssh... "scp..."> Thanks,

On Windows, ?scp C:/foo/bar remotehost:? will attempt to connect to a remote host ?C? and access file ?/foo/bar?. There is currently no syntax or flag to allow copying files that start with a drive name. This patch changes the behaviour (only on Cygwin) by considering that a single letter followed by a colon is a Windows drive name and thus an absolute path. This is also more consistent with the

I hear you - but it seems that the choice is between (a) limiting "scp" functionality to address the security vulnerability, and (b) killing "scp" altogether. I'd much prefer (a), even if it means I lose "scp remotehost:foo\* .". Especially, since (almost always) I have equal privileges on both local and remote hosts, so in that case I just originate that

The scp program from openssh-1.2.2p1 behaves different from the scp program from ssh-1.2.27. In ssh-1.2.27 you can copy one or more file(s) to a remote users home directory using the command: scp filename(s) user at remotehost In openssh-1.2.2p1 this copies the file(s) to a file named "user at remotehost" in the current (local) directory. To copy the files to the wanted (remote)

>> I understand that that is not how scp works today.>And it will likely never change. Why not? Just because "That's how we've always not done it" doesn't sound like a very good reason to me. >> I'm suggesting that we make a minor change to how it works.>scp is maintained for compatibility reasons only, as I've understood>things. That's still

A few people have commented that the synopsis in 'man 1 scp' is a bit difficult for humans to parse. I attach a diff between the distributed version and mine: (I suppose this should really go to the OpenBSD maintainers, but I wanted a little feedback about whether this was better or not.) Thanks, Andrew Stribblehill Systems Programmer, IT Service, University of Durham --------------

I conjecture that only few of the existing use cases rely on remote expansion. In any case (no pun intended), IMHO it would be better to break a few of the current use cases but leave the majority functional - than kill scp for all. Regards, Uri > On Aug 3, 2020, at 02:50, Jakub Jelen <jjelen at redhat.com> wrote: > > ?On Sat, 2020-08-01 at 00:17 +0000, Blumenthal, Uri - 0553

On Sun, Mar 01, 2015 at 10:58:30AM -0600, Valeri Galtsev wrote: > Why "slash": /.thunderbird in case of your example? Because if you do not > specify absolute path beginning with / the ssh daemon prepends your > relative path with its `pwd` it runs in, and its `pwd` is "/") I'm not sure I understand what you're saying here... Are you saying that if I run

http://bugzilla.mindrot.org/show_bug.cgi?id=852 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From dtucker at zip.com.au 2004-09-11

How difficult would it be to add an additional parameter to the -t that would *lock* the user at that directory level. say -T instead of -t... By locking, I mean translating /path/to/file as ./path/to/file, or ../../../path/../../../path/to/file as ./path/to/file. Basically set a root point as the current home directory, then build the pathing based on that, any "../" would become

On Sun, March 1, 2015 10:22 am, Richard wrote: > > > ------------ Original Message ------------ >> Date: Sunday, March 01, 2015 10:44:08 -0500 >> From: Mark LaPierre <marklapier at gmail.com> >> To: centos at centos.org, Mark LaPierre <marklapier at aol.com> >> Subject: Re: [CentOS] scp -rp behavior(SOLVED) >> >> On 02/26/15 19:45, Valeri

https://bugzilla.mindrot.org/show_bug.cgi?id=1405 Summary: scp: pattern-driven copying process Classification: Unclassified Product: Portable OpenSSH Version: 4.7p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: bitbucket at mindrot.org

Hello, I apologize if this isn't the right place to post about the Google Summer of Code; if so, I would appreciate guidance toward the correct list. If this is the correct list, I would appreciate answers to the message below. Thanks. -----Original Message----- From: Jawaad Ahmad <jawaadahmad32 at webster.edu> To: djm at openssh.com Subject: OpenSSH GSoC Project Date: Thu, 19 Mar

Hello, I have encountered a problem using ssh-2.1.1p1 on HP-UX 11.00: Everything else seems to work but running scp results in processes staying open: On the server there are 2 processes still running after copying a file: "scp -v -t /tmp" and one sshd. On the client also a ssh-process stays running until killing one of the processes manually... The copying works fine however.

Hey All, I am running rsync version 2.5.5 protocol version 26 on my remote machine (Redhat 8 def. install) and rsync version 2.5.6 protocol version 26 on my local machine (Redhat 7.2, 2.4.17 kernel instead of Redhat one with acl patches). I can copy files between these two machines (using ssh/scp) fine. When i run the command: rsync -rptz --delete --stats --include="*.ini"

I browsed the web and the archive, and apart from someone asking whether anyone else had rsync problems after installing OpenSSH 3.4, I came up empty. Can anyone point me in the right direction to debug this? I've got over 50 GB to keep in sync, and don't know of another elegant way to do it. Environment: source system = bb: - Linux version 2.4.7-10smp

I just released rssh version 2.2.3 to fix the problem detailed below. I haven't had time to update my website yet, and my Internet acess is quite limited these days (hence the terse announcement), so I probably won't get to that for a while. However, rssh 2.2.3 is available from the sourceforge.net site: http://sourceforge.net/projects/rssh All users of rssh should update to the