Need help with scp

Question

Level 1

125 points

Need help with scp

I can't figure out the syntax for scp.

/Users/chap/foo.txt is a file I want to send to /Users/Shared/ on bigguy.local.

My command is

scp /Users/chap/foo.txt chap@bigguy.local:/Users/Shared/

I'm prompted for password and the command completes normally but the file isn't copied.

I've also tried relative paths (relative to the home directories), and specifying the name for the target file.

The -v flag reveals one curiosity:

[...]
Password:
debug1: Authentication succeeded (keyboard-interactive).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending command: scp -v -t /Users/Shared/
~$ debug1: client input_channelreq: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.2 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0

The bolded scp command above makes no mention of the source file (and it uses the apparently-undefined flag '-t')

Thanks for another pair of eyes 😉
Chap

867MHz Powerbook Mac OS X (10.4.8)

Posted on Mar 4, 2007 10:15 PM

Reply

Answer 1

Mar 5, 2007 6:56 AM in response to Chap Harrison

Do you get a result in the Terminal which describes how many bytes was copied, and how many seconds it took, etc?

You can use multiple 'v's for more verbose output too, that may help.

Remember that scp uses SSH. If any component path of SSH has too liberal permissions SSH wail fail with no warning. Look at the System Log for more information, and also on the target machine's system log.

Reply

Answer 2

j.v.

Level 5

4,155 points

Mar 5, 2007 9:54 AM in response to Chap Harrison

your syntax is fine. Can you ssh into bigguy.local?

just for grins and chuckles, what happens if you
scp /Users/chap/foo.txt chap@192.168.0.101:/Users/Shared/
(I'm assuming in this example that 192.168.0.101 is the LAN IPv4 address of bigguy.local -- substitute the appropriate x.x.x.x numeric address)? Does it still crap on you?

BTW, if you are logged in as "chap" on the sending computer, and you have an account "chap" on the receiving computer, you don't need the "chap@" prefix -- it will default to that (well, if everything is working right, it will).

Reply

Answer 3

Chap Harrison Author

Level 1

125 points

Mar 5, 2007 3:09 PM in response to Gnarlodious

Do you get a result in the Terminal which describes
how many bytes was copied, and how many seconds it
took, etc?

I think that's being shown at the bottom of my first post. Looks like zeroes.

Remember that scp uses SSH. If any component path of
SSH has too liberal permissions SSH wail fail with no
warning. Look at the System Log for more information,
and also on the target machine's system log.

Both machines are running OSX 10.4.8. I haven't knowingly changed any permissions. The target machine's secure.log shows successful authentications for chap.

Reply

Answer 4

Chap Harrison Author

Level 1

125 points

Mar 5, 2007 3:22 PM in response to j.v.

your syntax is fine. Can you ssh into bigguy.local?

Yes.

just for grins and chuckles, what happens if you
scp /Users/chap/foo.txt
chap@192.168.0.101:/Users/Shared/
[...] Does it still crap on you?

Yep (with correct ip)

Here's the output with -vvv specified. There are some 'read failed' and 'write failed' messages near the end.
I still think the command being executed (line 2, beginning "Executing:") is fishy looking.

~$ scp -vvv /Users/chap/foo.txt chap@192.168.1.202:/Users/chap/
Executing: program /usr/bin/ssh host 192.168.1.202, user chap, command scp -v -t /Users/chap/
OpenSSH_4.2p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /Users/chap/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.202 [192.168.1.202] port 22.
debug1: Connection established.
debug1: identity file /Users/chap/.ssh/identity type -1
debug1: identity file /Users/chap/.ssh/id_rsa type -1
debug1: identity file /Users/chap/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.2
debug1: match: OpenSSH_4.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2
debug2: fd 6 setting O_NONBLOCK
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
A parameter was malformed
Validation error

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
A parameter was malformed
Validation error

debug1: SSH2 MSGKEXINIT sent
debug1: SSH2 MSGKEXINIT received
debug2: kex parsekexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-g roup1-sha1
debug2: kex parsekexinit: ssh-rsa,ssh-dss
debug2: kex parsekexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes1 92-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex parsekexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes1 92-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex parsekexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac- md5-96
debug2: kex parsekexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac- md5-96
debug2: kex parsekexinit: none,zlib@openssh.com,zlib
debug2: kex parsekexinit: none,zlib@openssh.com,zlib
debug2: kex parsekexinit:
debug2: kex parsekexinit:
debug2: kex parsekexinit: first kexfollows 0
debug2: kex parsekexinit: reserved 0
debug2: kex parsekexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-g roup1-sha1
debug2: kex parsekexinit: ssh-rsa,ssh-dss
debug2: kex parsekexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes1 92-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex parsekexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes1 92-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex parsekexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac- md5-96
debug2: kex parsekexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac- md5-96
debug2: kex parsekexinit: none,zlib@openssh.com
debug2: kex parsekexinit: none,zlib@openssh.com
debug2: kex parsekexinit:
debug2: kex parsekexinit:
debug2: kex parsekexinit: first kexfollows 0
debug2: kex parsekexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2 MSG_KEX_DH_GEXREQUEST(1024<1024<8192) sent
debug1: expecting SSH2 MSG_KEX_DH_GEXGROUP
debug2: dh genkey: priv key bits set: 131/256
debug2: bits set: 539/1024
debug1: SSH2 MSG_KEX_DH_GEXINIT sent
debug1: expecting SSH2 MSG_KEX_DH_GEXREPLY
debug3: check host_inhostfile: filename /Users/chap/.ssh/known_hosts
debug3: check host_inhostfile: match line 4
debug1: Host '192.168.1.202' is known and matches the RSA host key.
debug1: Found key in /Users/chap/.ssh/known_hosts:4
debug2: bits set: 482/1024
debug1: ssh rsaverify: signature correct
debug2: kex derivekeys
debug2: set_newkeys: mode 1
debug1: SSH2 MSGNEWKEYS sent
debug1: expecting SSH2 MSGNEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2 MSGNEWKEYS received
debug1: SSH2 MSG_SERVICEREQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2 MSG_SERVICEACCEPT received
debug2: key: /Users/chap/.ssh/identity (0x0)
debug2: key: /Users/chap/.ssh/id_rsa (0x0)
debug2: key: /Users/chap/.ssh/id_dsa (0x0)
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod isenabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod isenabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod isenabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/chap/.ssh/identity
debug3: no such identity: /Users/chap/.ssh/identity
debug1: Trying private key: /Users/chap/.ssh/id_rsa
debug3: no such identity: /Users/chap/.ssh/id_rsa
debug1: Trying private key: /Users/chap/.ssh/id_dsa
debug3: no such identity: /Users/chap/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod isenabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input userauth_inforeq
debug2: input userauth_inforeq: num_prompts 1
Password:
debug3: packet_send2: adding 32 (len 22 padlen 10 extra_pad 64)
debug2: input userauth_inforeq
debug2: input userauth_inforeq: num_prompts 0
debug3: packet_send2: adding 48 (len 10 padlen 6 extra_pad 64)
debug1: Authentication succeeded (keyboard-interactive).
debug2: fd 7 setting O_NONBLOCK
debug2: fd 8 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh session2open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client session2setup: id 0
debug1: Sending command: scp -v -t /Users/chap/
debug2: channel 0: request exec confirm 0
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
.bashrc ...
debug2: channel 0: read<=0 rfd 7 len 0
debug2: channel 0: read failed
debug2: channel 0: close_read
debug2: channel 0: input open -> drain
debug2: channel 0: ibuf empty
debug2: channel 0: send eof
debug2: channel 0: input drain -> closed
~$ debug2: channel 0: write failed
debug2: channel 0: close_write
debug2: channel 0: output open -> closed
debug1: client input_channelreq: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd eof
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)

debug3: channel 0: close_fds r -1 w -1 e 9 c -1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.2 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0

867MHz Powerbook Mac OS X (10.4.6)

Reply

Answer 5

Jun T.

Level 4

2,191 points

Mar 5, 2007 9:38 PM in response to Chap Harrison

There are some 'read failed' and 'write failed' messages near the end.

They are normal.

I still think the command being executed (line 2, beginning "Executing:") is fishy looking.

This is also normal. The filename (foo.txt) will be sent to bigguy as a part of data, not as a part of command.

debug1: Sending command: scp -v -t /Users/chap/

debug2: channel 0: request exec confirm 0
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 131072
.bashrc ...

Do you really get the output ".bashrc ..."? Then this may be the problem.
If your .bashrc (on bigguy) produces any output for non-interactive shell, then the output will confuse the scp command. Please try modifying the .bashrc so that it produces no output for non-interactive shell.

PowerMacG4, PowerBookG4, iMac(C2D) Mac OS X (10.4.8)

Reply

Answer 6

Mar 5, 2007 9:39 PM in response to Chap Harrison

I didn't ask about secure.log. I asked about system.log.

Reply

Answer 7

Chap Harrison Author

Level 1

125 points

Mar 6, 2007 5:39 AM in response to Jun T.

If your .bashrc (on bigguy) produces any output for
non-interactive shell, then the output will confuse
the scp command. Please try modifying the .bashrc so
that it produces no output for non-interactive
shell.

Beautiful! That was it. Thank you - solved!

Reply