SCP doesn't work if echo is in .bashrc?

Question

I have two users in Fedora:

• Vani
• root (quite obvious!)

My Wani user .bashrc content:

# .bashrc echo "Hello" # Source global definitions if [ -f /etc/bashrc ]; then . /etc/bashrc fi # User specific aliases and functions 

Now, after logging in to root, enter the following commands:

 [root@Dell Wani]# touch try.txt [root@Dell Wani]# service sshd start [root@Dell Wani]# scp try.txt Wani@localhost:~/ Wani@localhost password: Hello [root@Dell Wani]# 

Now I sign up for Wani and type:

 [Wani@Dell ~]$ cat try.txt cat: try.txt: No such file or directory [Wani@Dell ~]$ 

Now I log in to root again and enter the same command with -v :

 [root@Dell Wani]# scp -v morph.log Wani@localhost: Executing: program /usr/bin/ssh host localhost, user Wani, command scp -v -t -- . OpenSSH_5.6p1, OpenSSL 1.0.0j-fips 10 May 2012 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to localhost [127.0.0.1] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.6 debug1: match: OpenSSH_5.6 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.6 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr 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 'localhost' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:2 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi- with-mic,password debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information Credentials cache file '/tmp/krb5cc_0' not found debug1: Unspecified GSS failure. Minor code may provide more information Credentials cache file '/tmp/krb5cc_0' not found debug1: Unspecified GSS failure. Minor code may provide more information debug1: Unspecified GSS failure. Minor code may provide more information debug1: Next authentication method: publickey debug1: Trying private key: /root/.ssh/id_rsa debug1: Trying private key: /root/.ssh/id_dsa debug1: Next authentication method: password Wani@localhost password: debug1: Authentication succeeded (password). Authenticated to localhost ([127.0.0.1]:22). debug1: channel 0: new [client-session] debug1: Requesting [e-mail] debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env XMODIFIERS = @im=none debug1: Sending env LANG = en_US.UTF-8 debug1: Sending command: scp -v -t -- . Hello [root@Dell Wani]# 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 Transferred: sent 1664, received 1976 bytes, in 0.1 seconds Bytes per second: sent 22961.5, received 27266.8 debug1: Exit status 0 

(And after I hit Enter)

 [root@Dell Wani]# 

Can someone shed light on what happened here? Why the file was not copied to Wani from root?

Answer 1

Using echo in .bashrc will cause scp to break, since scp expects to see its protocol data on stdin / stdout channels. See https://bugzilla.redhat.com/show_bug.cgi?id=20527 for a more detailed discussion of this issue.

There are several workarounds:

• Condition on an "interactive" flag (for example, case $- in *i* , as indicated in the triple)
• Use the tty utility to detect an interactive shell (for example, if tty > /dev/null or if [ -t 0 ] )
• Check the value of $SSH_TTY

I suppose you should use what works for you. Unfortunately, I do not know which is the best (most portable / most reliable) option.

Answer 2

To add nneonneo to the parameters, you can also set using the interactive flag with

 if [[ $- =~ "i" ]] 

which, in my opinion, is the clearest way in bash.

Answer 3

It works for me
In .bashrc add the first line as:

 if [ -z "$PS1" ]; then return fi 

https://superuser.com/questions/690735/can-i-tell-if-im-in-an-scp-session-in-my-bashrc

Answer 4

default Ubuntu .bashrc contains the following code snippet that already performs this task:

 # If not running interactively, don't do anything case $- in *i*) ;; *) return;; esac 

Answer 5

In .bashrc use STDERR instead:

 echo "# Important Notice" >&2 

Update: do not use it! We recently had a problem due to which (with closed source) the tool crashed due to echo for STDERR in .bashrc . The tool (using rcp ) did not expect output at all, either on STDOUT or STDERR. And he was stuck when he received an echo. Lesson learned: create separate accounts for people and for cars (scripts) or just stop tutling through .bashrc .

Answer 6

The most portable way to test an interactive shell is:

 test -t 0 if [ $? -eq 0 ] then # interactive ; else # non-interactive ; fi 

Answer 7

The nneonneo solution worked for me as well. But since my default shell is TCSH, I had to slightly modify the fix as follows (in .tcshrc):

 if ( $?SSH_TTY ) then exec /bin/bash endif 

Just thought that I would share for everyone.

Answer 8

 if [ 0 -eq $(shopt -q login_shell; echo $?) ]; then echo "do something?" fi 

Source

Answer 9

If you are running Red Hat Enterprise Linux (RHEL) or another option, add the script that is echo , or whatever, to /etc/profile.d/

Answer 10

Is there a parameter that we could insert in ~ / .ssh / config to disable the startup script?