Tag Info

Hot answers tagged

243

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


67

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


54

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


45

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


32

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


27

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


25

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.


24

rssh shell (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/ 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 ...


24

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


22

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


22

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


21

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


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

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

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


17

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.


16

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.


14

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


14

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


13

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.


12

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


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

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


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

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

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.


10

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


10

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


10

This problem can be solved with rsync. At least this solution should be competitive in terms of performance. First, rsync can be called from one of the remote systems to overcome the limitation in the inability to copy between two remote systems directly. Second, encryption/decryption can be avoided by running rsync in Daemon Access mode instead of Remote ...



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