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


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.


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.


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 ...


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 ...


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 ...


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 ...


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.


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


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 ...


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.


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.


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.


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 ...


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 ...


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 . ...


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


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


If you just tar them up and nothing else this will waste tons of time with only minimal speed gain. So simply taring up the files with the cvf switches will effectively cost the time it takes to read all the 55GB images and write them back to disk. (Effectively it will be even more time wasted since there will be an considerable overhead). There is only ...


Use rsync instead of scp: rsync -avz --remove-source-files /sourcedir user@host:/targetdir More info with man rsync.


If you have 9,000 servers under the same management, you'd likely have some form of configuration management in place. That could be in the form of Puppet, Chef, Ansible, etc. You can distribute public keys that way. For 30 users, this is also something that could be handled via central directory authentication (LDAP, Active Directory).

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