Tag Info

Hot answers tagged

131

Yup, use -r: scp -rp sourcedirectory user@dest:/path


51

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


51

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


31

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


25

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: http://www.cyberciti.biz/tips/moving-home-data-from-old-system-to-new-linux-system.html The real answer is to ...


23

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 backupuser@xxx.xxx.xxx.194:/backup By using a special account for the backup on the destination system you are not exposing your root password.


23

Use the tool sshpass sshpass -p 'password' scp file.tar.gz root@xxx.xxx.xxx.194:/backup


21

rssh (http://pizzashack.org/rssh/) 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: http://dag.wieers.com/rpm/packages/rssh/


21

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.


20

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


18

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


18

The command scp -r source user@target:dest will walk all subdirectories of source and copy them. However if you are only making updates, not re-creating the whole thing, you will probably find things move along faster if you use rsync over ssh instead of scp. Probably something like rsync -av -e ssh source user@target:dest ...to get started. If you are ...


17

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


14

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


13

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.


13

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


13

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


12

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


12

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


11

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


11

Capital "P". $ scp -P 12345 svn_backup.tgz user@xxx.xxx.xx.xxx:/path/to/new/svn/ See $ man scp for more details.


11

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


10

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


10

You probably do it wrong. Each user (of the 30) has to create his own (thus private!) key. The public key of each user goes to every server (of the 9000) he should have access to. Don't do it the other way around.


9

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


9

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.


8

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


8

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


8

When you talk about command="" I assume you refer to the entry you can put in a ~/.ssh/authorized_keys, limiting what command a public ssh key can be used to execute? When transferring a file across ssh using scp you spawn the following process on the remote side: "scp -t /destination/directory". Hence, if you want an entry only allowing you to scp files ...



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