Hot answers tagged


Yup, use -r: scp -rp sourcedirectory user@dest:/path -r means recursive -p preserves modification times, access times, and modes from the original file.


While the previous answers are technically correct, you should also consider using rsync instead. rsync compares the data on the sending and receiving sides with a diff mechanism so it doesn't have to resend data that was already previously sent. If you are going to copy something to a remote machine more than once, use rsync. Actually, it's good to use ...


Instead of using tar to write to your local disk, you can write directly to the remote server over the network using ssh. server1$ tar -zc ./path | ssh server2 "cat > ~/file.tar.gz" Any string that follows your "ssh" command will be run on the remote server instead of the interactive logon. You can pipe input/output to and from those remote commands ...


I'd be tempted to rsync it over myself - it does compression and handles link loss well.


Use the tool sshpass sshpass -p 'password' scp file.tar.gz


That should absolutely match hidden files. The / at the end of the source says "every file under this directory". Nevertheless, testing and research bear you out. This is stupid behavior. The "answer" is to append a dot to the end of the source: scp -rp src/. user@server:dest/ The real answer is to use rsync.


Rather than using root create an account just for this job. Use public keys without a passphrase instead of passwords. scp -i /home/backupuser/.ssh/id_rsa By using a special account for the backup on the destination system you are not exposing your root password.


scp is supposed to take the same command line options as ssh, try: -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null Maybe add -q to disable the warnings as well.


rssh shell ( is designed for precisely this purpose. Since RHEL/CentOS 5.2 doesn't include a package for rssh, you might look here to obtain an RPM: To use it just set it as a shell for a new user like this: useradd -m -d /home/scpuser1 -s /usr/bin/rssh scpuser1 passwd scpuser1 ..or ...


rsync over ssh is probably your best bet with the --remove-source-files option rsync -avz --remove-source-files -e ssh /this/dir remoteuser@remotehost:/remote/dir a quick test gives; [tomh@workstation001 ~]$ mkdir test1 [tomh@workstation001 ~]$ mkdir test2 [tomh@workstation001 ~]$ touch test1/testfile.1 [tomh@workstation001 ~]$ ls test1/ testfile.1 [...


Assuming OpenSSH, add to your SSH configuration in .ssh/config Host distant ProxyCommand ssh near nc distant 22 This will cause SSH to be able to connect "directly" to the machine named distant by proxying through the machine named near. It can then use applications like scp and sftp to the distant machine. For this to work you need 'nc' aka netcat ...


The command scp -r source user@target:dest will walk all subdirectories of source and copy them. However, scp behaves like cp and always copies files, even if it is the same on both source and destination. [See here for a workaround.] As this is a static website, you are most likely only making updates, not re-creating the whole thing, so you will probably ...


I'm a bit late to the party, however I will suggest you take a look at the ForceCommand directive of OpenSSH. Subsystem sftp internal-sftp Match group sftponly ForceCommand internal-sftp Granted, this is SFTP and not SCP, but it reaches the same goal, more securely than with a restricted shell. Additionally, you can chroot the user if you want ...


rsync is your friend. rsync -ru /source/directory/* If you want it to delete files at the destination that no longer exist at the source, add the --delete option.


To be real down and dirty you can use netcat. On the sender cat {filename} | nc -l 3333 On the receiver nc {sender_ip_address} 3333 > {filename} Since there will be nearly no application overhead, you should only be limited by IO, whether disk or network.


That is what the -r option is for. :) See the scp man page for more info if needed.


Connect to the console and change the MTU back. If you've not got console access, then reboot the server.


You can add -o options to scp instead of .ssh/config. scp -o ProxyCommand="ssh $jump_host nc $host 22" $local_path $host:$destination_path $jump_host is your "server B" in this case.


You can try rsync. It's better suited for this job: rsync -av src/ user@server:dest/ (And its manual page is worth reading.)


Try to use rsync, it has a lot more benefits besides keeping ownership, permissions and incremental copies: rsync -av source Besides rsync, using ssh, should work where scp works.


Which shell are you using? If you are using bash you may need to enable "advanced" completions in bash... if [ -f /etc/bash_completion ]; then . /etc/bash_completion fi In your ~/.bashrc On OSX you can do: $ sudo port install bash-completion To your ~/.profile add: if [ -f /opt/local/etc/bash_completion ]; then . /opt/local/etc/...


SCP is the abbreviation of 'secure copy', while SFTP stands for 'secure FTP'. The first is used to copy one or more files, often with known names, from host A to host B, whereas the second is mostly used interactively, analogue to an FTP client. SCP will always work out of the box and has little in the field of tweakable options. SFTP can be used with ...


You can use rsync to copy your file from one computer to the other. rsync can use ssh as its underlying transport. Combine rsync --partial with a script such as this one to try again in case of network failure, and you should be able to move your files even in the face of network errors. Another way to do it would be to mount the remote filesystem on your ...


Capital "P". $ scp -P 12345 svn_backup.tgz See $ man scp for more details.


You can ssh to server B using something like ssh -L 5022:<server C IP>:22 <user_serverB>@<server B IP> Then you can ssh to server C using ssh -p 5022 <user_serverC>@localhost Similarly scp would work using scp -P 5022 foo.txt <user_serverc>@localhost: Remember to use correct case of p with scp and ssh


Sneakernet Anyone? Assuming this is a one time copy, I don't suppose its possible to just copy the file to a CD (or other media) and overnight it to the destination is there? That might actually be your fastest option as a file transfer of that size, over that connection, might not copy correctly... in which case you get to start all over again. rsync ...


Two problems: First, the * does not go on the destination side. Second, -r is for copying an entire directory and subdirectories. pscp -i C:\sitedeploy\abt-keypair.ppk includes\* Will copy all of the files in the local includes\ directory to the .../includes/ directory on the server. pscp -r -i C:...


Use this "dot" syntax: scp -prq server1:dir1/. server2:dir2/ This copies the contents of that directory, rather than the directory itself. And I believe it's more portable than * globbing.


With more recent versions of ssh on the server near (B) machine the following will work without netcat: Host distant ProxyCommand ssh near -W distant:22 It will however require AllowTcpForwarding to be yes (the default) on the near (B) machine edit: requires OpenSSH 5.4+ on B

Only top voted, non community-wiki answers of a minimum length are eligible