In the past, the way in which scp worked, when called (naively) to copy files between remote systems, was very inconvenient: if you wrote, for instance
scp user1@remote1:/home/user1/file1.txt user2@remote2:/home/user2/file1.txt
scp would first open an ssh session on remote1, and then it would run scp from there to remote2. For this to work, you would ...
If you have white space in a path, you have to escape the characters by using double backslashes \\ and enclosing the entire path in quotes:
scp myfile.txt email@example.com:"/file\\ path\\ with\\ spaces/myfile.txt"
With SCP, you have to do in two steps, however, you can do it in one with rsync as follows:
rsync --rsync-path="sudo rsync" <LOCALFILE> USER@SERVER2:/root
Note: This does require NOPASSWD sudo configuration. If you have to enter the password for sudo, then the two step way is needed.
To copy directory, you need to add -r parameter. And -v for ...
FTPS is FTP using the SSL/TLS protocol for encryption. This is different from the SCP/SFTP family of protocols which use SSH as their transport tunnel.
You will usually use client programs like WinSCP for SCP and SFTP (SFTP is an upgraded version of SCP), whereas you would usually use a web browser or web Download manager (like Filezilla) for FTPS.
This question is essentially answered elsewhere, including here for scp and here for rsync. Since the latter includes my answer, but no answer was accepted, I'll repeat it here.
As you noted, you can use rsync's -e | --rsh option, but it's going to be a bit more complicated:
rsync -azv -e 'ssh -o "ProxyCommand ssh -A PROXYHOST -W %h:%p"' foo/ dest:./foo/
Copy the file "foobar.txt" from a remote host to the local host:
$ scp firstname.lastname@example.org:foobar.txt /some/local/directory
Copy the file "foobar.txt" from the local host to a remote host:
$ scp foobar.txt email@example.com:/some/remote/directory
Copy the directory "foo" from the local host to a remote host's directory "bar":
$ scp -...
Lsyncd would be a good solution for this.
Lsyncd watches a local directory trees event monitor interface (inotify or fsevents). It aggregates and combines events for a few seconds and then spawns one (or more) process(es) to synchronize the changes. By default this is rsync. Lsyncd is thus a light-weight live mirror solution that is comparatively easy to ...
As said before, scp happily overwrites any file that is already present.
The "file exists" issue can only occur when you have some other process (like a concurrent scp process, or something else) writing folders and files to the same destination. Consider using rsync instead.
Not just the admin.
For testing, I just copied /bin from my server to a temporary directory on my laptop. ps on the server shows
$ ps 24096
PID TTY STAT TIME COMMAND
24096 ? Ss 0:00 scp -r -f /bin
This information is generally accessible to all users.
I need this a lot since my code needs to run on remote boxes and I write code on local machine. I found a nice tool which you can use to continuously monitor your local folders and sync them to remote or local folder: https://github.com/axkibe/lsyncd
A simple command to continuously sync a local dir with remote machine over ssh will be:
lsyncd -log all -...
A ServerFault question is almost identical to this. Hopefully you checked before posting your question, but yours is a little different so I will answer here.
The short answer is that if ANYONE has access and permissions to an endpoint (the system you are scping from or scping to), they can see what happens. If they do not have access to either endpoint, ...
My preferred working solution would be to use rsync instead:
scp /path/to/file server:/server/path/to/file
rsync --chmod=u+rwx,g+rwx,o+rwx /path/to/file server:/path/to/file
This prevents you from authenticating twice. There are also a lot of other options with rsync which would probably add value such as being able to preserve owner, ...
You can now* do this as a one-liner, without requiring nc anywhere:
scp -o "ProxyCommand ssh firstname.lastname@example.org -W %h:%p" email@example.com:file .
pcreds and tcreds represent your proxy and target credentials if required (username, username:password, etc.).
This is possible because of a built-in netcat-like ability, removing the ...
Modification time is mtime, not ctime. scp -p already preserves mtime.
ctime is the inode change time, updated every time the file itself is touched in any way – renamed, moved, chmodded, etc.
Generally there is no way to preserve it, as the OS does not provide any function for that, and even if it did, the very act of setting the ctime would be a change ...
First get the size of the remote file in bytes:
$ ssh user@host 'stat -c%s FILENAME'
Calculate 10% of that number, and copy the last ten percent:
$ ssh user@host 'tail -c 5000 FILENAME' > DESTINATION
The culprit is CVE-2018-20685, whose description is:
In OpenSSH 7.9, scp.c in the scp client allows remote SSH servers to
bypass intended access restrictions via the filename of . or an empty
filename. The impact is modifying the permissions of the target
directory on the client side.
This is part of a larger set of SCP vulnerabilities. Quoting ...
According to this previous answer, the culprit is CVE-2017-20685; apparently, malicious remote hosts could exploit improper name validation, so support for . in paths for scp was disabled. The workaround is to replace . with $(pwd).
Although the proper answer is probably to use WinSCP and their C# library, I did find a way to get PSCP to work when the target folder has a space in it.
The correct answer is to do this:
pscp.exe -pw MyPassword firstname.lastname@example.org:/etc/myfolder/myfile.opt "C:\download files"
It turns out that I was having another problem that was making me think the above was ...
The ssh command will allow you to execute pretty much any command on the remote host, e.g.,
ssh yourlogin@remotehost rmdir somedir
where in this example somedir is relative to the home directory of yourlogin.
SCP is the file transfer tool from SSH. It requires SSH on both client and server. It is not interactive.
SFTP is another file transfer tool that can be used with SSH (so it again may require SSH on both client and server) or with any other compatible secure connection tool, since it is intended to be independent of SSH. It is interactive like the old plain ...
You can do it with just one command scp.
for newer versions of scp:
scp `find <path> -name <expression>` user@host:<path_where_to_copy>
for older versions:
scp --exec=`find <path> -name <expression>` user@host:<path_where_to_copy>
Make sure to encapsulate the find command in between backticks ` and not single quotes '....
try scp in a fast way
scp -p -C -o 'CompressionLevel 9' -o 'IPQoS throughput' -c arcfour machine:file .
these options speed up scp 5 times in my setup compared to plain scp machine:file .
Actually scp is slow due to poor management of TCP details such as MTU and buffer size. Luckily this has been fixed by the HPN SSH project. To my ...
in host1, edit ~/.ssh/config and add something like this
this will turn the messages off for you.
because -q only controls the ssh client connection from your localhost, not from host1.
alias run_rsync='rsync -azP --exclude ".*/" --exclude ".*" --exclude "tmp/" /source_folder username@host:/destination_folder'
run_rsync; fswatch -o . | while read f; do run_rsync; done
Second line runs run_rsync once unconditionally and then - on each change in current directory (or specify exact path instead of .)
You will need fswatch - here is how to ...
After some investigation, I have found these two options:
scp 'user@remote_host:"/home/user/path with spaces/filename with spaces.ext"' .
scp 'user@remote_host:/home/user/path\ with\ spaces/filename\ with\ spaces.ext' .
I hope it helps you too!
My standard bashrc on debian had this as the first lines:
if [ -z "$PS1" ]; then
This checks if the variable $PS1 is set (which only is set if you're on an interactive shell), and prevents the execution of the rest if it isn't.
To copy millions of files over a gigabit switch (in a trusted environment) you may also use a combination of netcat (or nc) and tar, as already suggested by user55286. This will stream all the files as one large file (see Fast File Copy - Linux! (39 GBs)).
# requires netcat on both servers
nc -l -p 2342 | tar -C /target/dir -xzf - # destination box