# scp & shfs not working for non-root accounts [solved]

## smadasam

I have been having trouble using scp or shfs to copy files from remote ssh servers.  It works just fine if I am root, not at all if I am an unprivileged user.  The servers I am trying to connect to are running RHEL5.  Does anyone have an idea what the problem is?

----------

## sschlueter

"not working" is not a description of the problem  :Wink: 

----------

## smadasam

If I knew why it was not working, then I wouldn't have to post for help.  I was hoping that someone else had this same problem so I could have a better idea of why it is not working instead of just "not working"

----------

## Rob1n

Can you tell us what commands you're typing and what the error message (or output) you get is.  "Not working" covers everything from the commands not being in the PATH through network errors and authentication problems.

----------

## smadasam

This is the output I get when I run the with the -v flag.  I doesn't really tell me much except it gets an exit code 1. 

sam@phoenix ~ $ scp -v prodnode1:~/*sar .  

Executing: program /usr/bin/ssh host prodnode1, user (unspecified), command scp -v -f ~/*sar

OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Connecting to prodnode1 [140.140.207.111] port 22.

debug1: Connection established.

debug1: identity file /home/sam/.ssh/identity type -1

debug1: identity file /home/sam/.ssh/id_rsa type -1

debug1: identity file /home/sam/.ssh/id_dsa type -1

debug1: Remote protocol version 1.99, remote software version OpenSSH_4.3

debug1: match: OpenSSH_4.3 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_4.6

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: server->client aes128-cbc hmac-md5 none

debug1: kex: client->server aes128-cbc hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Host 'prodnode1' is known and matches the RSA host key.

debug1: Found key in /home/sam/.ssh/known_hosts:6

debug1: ssh_rsa_verify: signature correct

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,gssapi-with-mic,password

debug1: Next authentication method: publickey

debug1: Trying private key: /home/sam/.ssh/identity

debug1: Trying private key: /home/sam/.ssh/id_rsa

debug1: Trying private key: /home/sam/.ssh/id_dsa

debug1: Next authentication method: password

sam@prodnode1's password: 

debug1: Authentication succeeded (password).

debug1: channel 0: new [client-session]

debug1: Entering interactive session.

debug1: Sending command: scp -v -f ~/*sar

Sink: Setting up [gcc production] cluster environment

Setting up [gcc production] cluster environment

sam@phoenix ~ $ Sending file modes: C0600 10976000 brain_bbal

l_x140y140z140.sar

debug1: client_input_channel_req: 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 1

----------

## Rob1n

No, that doesn't tell us much - it's mostly the same as I get for mine.  Not sure what the "Setting up [gcc production] cluster environment" bit is about though - any ideas?  Could you try with -vv and see whether that's more helpful.

----------

## smadasam

 *Rob1n wrote:*   

> Setting up [gcc production] cluster environment

 

That is just part of a log in script to insure the correct libraries are loaded

Here it is with the -vv

```
sam@phoenix ~ $ scp -vv prodnode1:~/*sar .

Executing: program /usr/bin/ssh host prodnode1, user (unspecified), command scp -v -f ~/*sar

OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007

debug1: Reading configuration data /etc/ssh/ssh_config

debug2: ssh_connect: needpriv 0

debug1: Connecting to prodnode1 [140.140.207.111] port 22.

debug1: Connection established.

debug1: identity file /home/sam/.ssh/identity type -1

debug1: identity file /home/sam/.ssh/id_rsa type -1

debug1: identity file /home/sam/.ssh/id_dsa type -1

debug1: Remote protocol version 1.99, remote software version OpenSSH_4.3

debug1: match: OpenSSH_4.3 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_4.6

debug2: fd 3 setting O_NONBLOCK

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib

debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib

debug2: kex_parse_kexinit: 

debug2: kex_parse_kexinit: 

debug2: kex_parse_kexinit: first_kex_follows 0 

debug2: kex_parse_kexinit: reserved 0 

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib@openssh.com

debug2: kex_parse_kexinit: none,zlib@openssh.com

debug2: kex_parse_kexinit: 

debug2: kex_parse_kexinit: 

debug2: kex_parse_kexinit: first_kex_follows 0 

debug2: kex_parse_kexinit: 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_GEX_REQUEST(1024<1024<8192) sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug2: dh_gen_key: priv key bits set: 109/256

debug2: bits set: 487/1024

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Host 'prodnode1' is known and matches the RSA host key.

debug1: Found key in /home/sam/.ssh/known_hosts:6

debug2: bits set: 506/1024

debug1: ssh_rsa_verify: signature correct

debug2: kex_derive_keys

debug2: set_newkeys: mode 1

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug2: set_newkeys: mode 0

debug1: SSH2_MSG_NEWKEYS received

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug2: service_accept: ssh-userauth

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug2: key: /home/sam/.ssh/identity ((nil))

debug2: key: /home/sam/.ssh/id_rsa ((nil))

debug2: key: /home/sam/.ssh/id_dsa ((nil))

Beowulf Computer Cluster (BCC)

AFRL/HED

This is a Department of Defense Computer System. This computer system, includingall related equipment, networks, and network devices (specifically including

Internet access) are provided only for authorized U.S. Government use.

DoD computer systems may be monitored for all lawful purposes, including to

ensure that their use is authorized, for management of the system, to facilitateprotection against unauthorized access, and to verify security procedures,

survivability, and operational security. Monitoring includes active attacks by

authorized DoD entities to test or verify the security of this system. During

monitoring, information may be examined, recorded, copied and used for

authorized purposes. All information, including personal information, placed or sent over this system may be monitored.

debug1: Authentications that can continue: publickey,gssapi-with-mic,password

debug1: Next authentication method: publickey

debug1: Trying private key: /home/sam/.ssh/identity

debug1: Trying private key: /home/sam/.ssh/id_rsa

debug1: Trying private key: /home/sam/.ssh/id_dsa

debug2: we did not send a packet, disable method

debug1: Next authentication method: password

sam@prodnode1's password: 

debug2: we sent a password packet, wait for reply

debug1: Authentication succeeded (password).

debug2: fd 4 setting O_NONBLOCK

debug2: fd 5 setting O_NONBLOCK

debug1: channel 0: new [client-session]

debug2: channel 0: send open

debug1: Entering interactive session.

debug2: callback start

debug2: client_session2_setup: id 0

debug1: Sending command: scp -v -f ~/*sar

debug2: channel 0: request exec confirm 0

debug2: fd 3 setting TCP_NODELAY

debug2: callback done

debug2: channel 0: open confirm rwindow 0 rmax 32768

debug2: channel 0: rcvd adjust 131072

Sink: Setting up [gcc production] cluster environment

Setting up [gcc production] cluster environment

debug2: channel 0: read<=0 rfd 4 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

sam@phoenix ~ $ debug2: channel 0: rcvd ext data 64

Sending file modes: C0600 10976000 brain_bball_x140y140z140.sar

debug2: channel 0: written 64 to efd 6

debug2: channel 0: rcvd eof

debug2: channel 0: output open -> drain

debug1: client_input_channel_req: channel 0 rtype exit-status reply 0

debug2: channel 0: rcvd close

debug2: channel 0: write failed

debug2: channel 0: close_write

debug2: channel 0: output drain -> closed

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

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 1

```

----------

## sschlueter

I think we need the debug output of the ssh server - the client does not receive anything.

----------

## tarpman

Does the login script produce any output?  That's what the 'gcc production environment' messages look like to me.  If so, it'll have to go - scp can't tolerate output.

```
(04:42 PM) ~ > head .bashrc

# /etc/skel/.bashrc

#

# This file is sourced by all *interactive* bash shells on startup,

# including some apparently interactive shells such as scp and rcp

# that can't tolerate any output.  So make sure this doesn't display

# anything or bad things will happen !
```

----------

## smadasam

 *tarpman wrote:*   

> Does the login script produce any output?  That's what the 'gcc production environment' messages look like to me.  If so, it'll have to go - scp can't tolerate output.
> 
> ```
> (04:42 PM) ~ > head .bashrc
> 
> ...

 

Thanks!  That was the problem.  My login script was writing something that was killing scp.  I took out the echos in the .bashrc file, and everything is happy now.   :Smile: 

----------

