Tag Info

New answers tagged

2

you need to set up a password less login, using public/private key with ssh. then, assuming fles to be copied are in dir, source$ tar cf - dir | ssh servera 'ssh serverb "cd dest ; tar xf - " ' where source$ is you prompt tar cf - dir tar files in dir to stdin ssh servera logs you to servera cd dest ; tar xf - extract from stdin files in dest dir.


2

The easiest option would be, to perform a ssh connection without password via pubkey authentication. That means you have to share the public keys between the servers. Then you can just use a command like that at the "source" server: cat file | ssh user@serverA "ssh user@serverB \"cat > file\""


0

The original problem (based on reading all comments to the OP question) was that the scp executable on the 64-bit system was a 32-bit application. A 32-bit application that isn't compiled with "large-file support" ends up with seek pointers that are limited to 2^32 =~ 4GB. You may tell if scp is 32-bit by using the file command: file `which scp` On most ...


6

You are copying localy with your command, you create file 'root@192.168.1.104', you should run: scp /etc/drbd.d/r0.res root@192.168.1.104:/path/ where path/ is your desired destination on machine 192.168.1.104


2

If fig is a binary, as opposed to a script, then it will not run on a different operating system. Run file fig to find out (if the output is something similar to ELF 64-bit LSB executable, then it's a binary, if it looks more like Perl script, ASCII text executable, then it's a script and has at least a fighting chance of running on a different platform). In ...


-1

before using scp command, make sure that you give permissions read, write and execute to everyone outside. "chmod 777 file_name"


0

debug1: Sending command: scp -v -f /var/stuff/backups/*.tgz debug2: channel 0: request exec confirm 1 debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 debug2: channel_input_status_confirm: type 99 id 0 debug2: exec request accepted on channel 0 debug1: ...


0

I think you do 1st backups/* .tgz to change backups*.tgz make sure don't use any space. might be 99% issue solved.


0

Your problem is clearly identified in these lines: debug2: exec request accepted on channel 0 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug2: channel 0: rcvd eof which shows your channel is shut down as soon as it is opened, though the reason is not stated. Normally,this occurs because of a faulty configuration ...


2

Try this: scp -vvv 'backup@hostname:/var/stuff/backups/*.tgz' /data/backups/ If that doesn't work try this: scp -vvv 'backup@hostname:/var/stuff/backups/\*.tgz' /data/backups/


28

Rsync is very well suited for transferring large files over ssh because it is able to continue transfers that were interrupted due to some reason. Since it uses hash functions to detect equal file blocks the continue feature is quite robust. It is kind of surprising that your sftp/scp versions does not seem to support large files - even with 32 Bit ...


16

I'm not sure about the file size limits of SCP and SFTP, but you might try working around the problem with split: split -b 1G matlab.iso This will create 1 GiB files which, by default, are named as xaa, xab, xac, .... You could then use scp to transfer the files: scp xa* xxx@xxx: Then on the remote system recreate the originial file with cat: cat xa* ...


1

A combination of dd and ssh can probably help here: # dd if=/dev/mtd0 | ssh me@myhost "dd of=mtd0.img"


0

The following command works for me. paste -d'@:' <(whoami;) <(ifconfig | awk -F':' '/inet addr/&&!/127.0.0.1/{split($2,_," ");print _[1]}') <(pwd)


0

If I understand you right this should do it. Use scp with -v option. Verbose scp -rv $Blah@HOSTNAME:~/source-dir/ /local/machine/


1

The syntax for scp is: If you are on the computer from which you want to send file to a remote computer: scp /file/to/send username@remote:/where/to/put Here the remote can be a FQDN or an IP address. On the other hand if you are on the computer wanting to receive file from a remote computer: scp username@remote:/file/to/send /where/to/put scp can ...


10

The ~/SDRIVE directory is mounted as a fuse filesystem which means that the filesystem operations are handled by some userspace program, not by the kernel. Those errors are coming from the filesystem implementation, which could be anything at all and is probably some kind of site-custom software. This is one of those times where you're probably going to ...


0

On my SuSE 11 system, I found the banner message in /etc/issue.net and then remarked out the banner line in my /etc/ssh/sshd_config file. #banner /etc/issue.net Then restarted the ssh daemon service sshd restart This suppressed the banner when using scp inside scripts and cleaned up the log files.


0

What I found was that on older HP-UX machines (parisc 11.11), I had to use [^a]* But, on newer machines (parisc 11.31 and newer) it works with !(a*) This is what I ended up with. And it works: if [[ ${S_MACH} = "phd026a" || ${S_MACH} = "tht030a" ]] then scp -p -r ${S_MACH}:${S_DIR}/bin/[^a^b^c^p]* ${D_DIR}/bin/. else ...


3

On your local system, create a skeleton of what you want. For example, if you want to copy file foo to remote location /etc/foo, then you need to create an etc directory and then put foo into it. Then tar the skeleton. Now you can do this via cron as suggested by @Anthon in the comments to the question above. Step by step: On the remote host, create ...



Top 50 recent answers are included