scp "perdió conexión" pero ssh funciona bien

10

Un servidor en el que puedo trabajar bien ha comenzado a negarse a scp.

$ scp ~/tmp/foo user@some.example.com:~/tmp/
lost connection

Con scp -v -vPuedo ver que la conexión tiene éxito y la transferencia parece tener éxito, pero no aparece ningún archivo en el otro lado.

OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /Users/schwern/.ssh/config
debug1: /Users/schwern/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to testcurrent01.dev.liquidweb.com [10.30.152.254] port 22.
debug1: Connection established.
debug1: identity file /Users/schwern/.ssh/id_rsa type -1
debug1: identity file /Users/schwern/.ssh/id_rsa-cert type -1
debug1: identity file /Users/schwern/.ssh/id_dsa type -1
debug1: identity file /Users/schwern/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
...lots of authentication details...
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).
Authenticated to user@some.example.com ([1.2.3.4]:22).
debug2: fd 5 setting O_NONBLOCK
debug2: fd 6 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
debug2: fd 3 setting TCP_NODELAY
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending command: scp -v -t -- ~/tmp/
debug2: channel 0: request exec confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> 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
Transferred: sent 4576, received 2520 bytes, in 0.0 seconds
Bytes per second: sent 167737.0, received 92372.6
debug1: Exit status 0
debug1: compress outgoing: raw data 135, compressed 121, factor 0.90
debug1: compress incoming: raw data 66, compressed 52, factor 0.79
lost connection

Es una máquina CentOS 5.9.

Cosas que he comprobado ...

Tengo permiso para escribir en ese directorio.
El usuario tiene un shell sensible (/ bin / bash).
Traté de apartarme ~/.ssh/configdel camino.
scp'ing a esa máquina de otros con sistemas operativos completamente diferentes también falla.
El disco no está lleno.
Reiniciando sshd.

/ var / log / secure contiene ...

Apr  4 14:23:22 some sshd[12576]: Postponed publickey for user from 1.2.3.4 port 33581 ssh2
Apr  4 14:23:22 some sshd[12575]: Accepted publickey for user from 1.2.3.4 port 33581 ssh2
Apr  4 14:23:22 some sshd[12575]: pam_unix(sshd:session): session opened for user user by (uid=0)
Apr  4 14:23:22 some sshd[12575]: pam_unix(sshd:session): session closed for user user

¿Qué puedo verificar a continuación?

ssh scp

— Schwern
fuente

2

No es el error que se puede esperar, pero por si acaso, hacer su ~/.bashrco ~/.profileo /etc/bash.bashrco /etc/profileimprimir cualquier cosa en STDOUT? bugzilla.redhat.com/show_bug.cgi?id=20527 . ¿Y supongo que estás usando Linux?

— terdon

No Acabo de obtener lo de siempre Last login: Thu Apr 4 10:15:28 2013 from 1.2.3.4.

— Schwern

¿Algo en alguno de los registros del sistema en el host de destino?

— Flup

@Flup Parece normal. Publiqué lo que aparece en los registros cuando me conecto.

— Schwern

¿Podría comenzar strace -f -o /tmp/sshd.strace -p [pid of sshd]en el servidor, volver a intentarlo y luego publicar algo de ese archivo que parezca relevante?

— Flup

1

Tuve el mismo problema.

Si realizó una instalación mínima de Centos, solo instalará los paquetes opensshy openssh-serverpero no el openssh-clients. sudo yum install openssh-clientsArreglará su problema.

— qux
fuente

Ya no tengo acceso a esa máquina, pero esa parece una respuesta probable.

— Schwern

4

scpfunciona haciendo una sshconexión con el host remoto y luego iniciando otra copia del scpprograma en ese host. Las dos instancias scp se comunican a través de la conexión ssh para realizar la transferencia de archivos.

El scpprograma local imprime la "conexión perdida" cuando la conexión ssh cae prematuramente. La razón habitual para esto es que el scpprograma en el host remoto no pudo iniciarse o salió prematuramente. Esto podría haber sucedido porque el programa scp no existe en el host remoto, o no está en el comando PATH, o no está marcado como ejecutable, o se bloqueó después del inicio, o algo por el estilo.

— Kenster
fuente

0

Recientemente tuvimos este problema en uno de nuestros sistemas.

Podríamos enviar ssh adecuadamente al servidor host, pero descubrimos que no podíamos ssh desde el servidor a la máquina. Este es un buen lugar para investigar, si no puede hacerlo, no podrá usar SCP.

En nuestro caso, de alguna manera (tal vez una instalación fallida) había reemplazado nuestros archivos binarios ssh con archivos vacíos de 0 bytes. Cada vez que se ejecutaba "ssh", no pasaba nada.

Al reinstalar openssh-clients, rectificamos los binarios y scp comenzó a funcionar.

yum reinstall openssh-clients

— Ultimation
fuente