remote how example bash ssh scp

how - SCP no funciona cuando echo en.bashrc?



scp unix (8)

Tengo dos usuarios en Fedora:

  1. Wani
  2. root (¡bastante obvio!)

Mis contenidos de .bashrc del usuario Wani son:

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

Ahora, después de iniciar sesión en root, escribo los siguientes comandos:

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

Ahora inicio sesión en Wani y escribo:

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

Ahora vuelvo a iniciar sesión en root y escribo el mismo comando con -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''s password: debug1: Authentication succeeded (password). Authenticated to localhost ([127.0.0.1]:22). debug1: channel 0: new [client-session] debug1: Requesting [email protected] 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

(Y después de presionar Enter)

[root@Dell Wani]#

¿Puede alguien por favor arrojar algo de luz sobre lo que sucedió exactamente aquí? ¿Por qué el archivo no se copió de la raíz de Wani?

El Ubuntu .bashrc predeterminado contiene el siguiente fragmento que ya soluciona el problema:

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

El uso de echo en a .bashrc romperá scp , ya que scp espera ver sus datos de protocolo a través de los canales stdin / stdout. Consulte https://bugzilla.redhat.com/show_bug.cgi?id=20527 para obtener más información sobre este tema.

Hay algunas soluciones disponibles:

  • Condición en la bandera ''interactiva'' (por ejemplo, case $- in *i* según lo sugerido por tripleee)
  • Utilice la utilidad tty para detectar un shell interactivo (por ejemplo, if tty > /dev/null o if [ -t 0 ] )
  • Verifique el valor de $SSH_TTY

Supongo que deberías usar el que te funcione. No sé cuál es la mejor opción (la más portátil / más confiable), desafortunadamente.

En .bashrc , use STDERR como salida en su lugar:

echo "# Important Notice" >&2

Actualización: ¡no lo use! Hace poco tuvimos un problema que una herramienta (de fuente cerrada) falló debido a un echo de STDERR en .bashrc . La herramienta (usando rcp ) no esperaba salida alguna, ni en STDOUT ni STDERR. Y se estancó cuando obtuvo el eco. Lección aprendida: hacer cuentas separadas para humanos y para máquinas (scripts), o simplemente dejar de insultar a través de .bashrc .

La forma más portátil de probar un shell interactivo parece ser:

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

La solución de nneonneo funcionó también para mí. Pero como mi shell predeterminado es TCSH, tuve que editar ligeramente la corrección de la siguiente manera (en .tcshrc):

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

Solo pensé que compartiría para el beneficio de todos.

Para agregar a las opciones de nneonneo, también puede acondicionar con la bandera interactiva con

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

que creo que es posiblemente el camino más claro en bash.

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

Source