No se puede hacer un SCP a pesar de que SSH funciona bien

He configurado la autenticación de clave entre dos servidores y puedo ingresar sin una clave, por ejemplo:

ssh backup@hostname

esto funciona bien y me conecta. Pero cuando intento un SCP para extraer un archivo, no obtengo archivos.

Los archivos de destino lo han chmod 777hecho para solucionar problemas, pero es como si simplemente no encontrara ningún archivo para copiar a pesar de que están allí.

Aquí está la salida (ofuscada de ip) de

scp -vvv backup@hostname:/var/stuff/backups/*.tgz /data/backups/

desde el punto se autentica en adelante.

debug1: Authentication succeeded (publickey).    
Authenticated to xxx.xxx.xxx.xxx ([xxx.xxx.xxx.xxx]:22).
debug2: fd 4 setting O_NONBLOCK    
debug2: fd 5 setting O_NONBLOCK    
debug2: fd 6 setting O_NONBLOCK    
debug1: channel 0: new [client-session]    
debug3: ssh_session2_open: channel_new: 0    
debug2: channel 0: send open    
debug1: Entering interactive session.    
debug2: callback start   
debug2: fd 3 setting TCP_NODELAY    
debug3: packet_set_tos: set IP_TOS 0x08    
debug2: client_session2_setup: id 0    
debug1: Sending environment.    
debug3: Ignored env XDG_SESSION_ID    
debug3: Ignored env TERM    
debug3: Ignored env SHELL    
debug3: Ignored env SSH_CLIENT    
debug3: Ignored env SSH_TTY    
debug3: Ignored env http_proxy    
debug3: Ignored env USER    
debug3: Ignored env LS_COLORS    
debug3: Ignored env MAIL    
debug3: Ignored env PATH   
debug3: Ignored env QT_QPA_PLATFORMTHEME    
debug3: Ignored env PWD    
debug1: Sending env LANG = en_AU.UTF-8    
debug2: channel 0: request env confirm 0    
debug3: Ignored env SHLVL    
debug3: Ignored env HOME    
debug3: Ignored env LANGUAGE    
debug3: Ignored env LOGNAME    
debug3: Ignored env SSH_CONNECTION    
debug3: Ignored env LESSOPEN    
debug3: Ignored env XDG_RUNTIME_DIR    
debug3: Ignored env LESSCLOSE    
debug3: Ignored env _    
debug3: Ignored env OLDPWD    
debug1: Sending command: scp -v -f /var/stuff/backups/*.tgz    
debug2: channel 0: request exec confirm 1    
debug2: callback done    
debug2: channel 0: open confirm rwindow 0 rmax 32768    
debug2: channel 0: rcvd adjust 131072    
debug2: channel_input_status_confirm: type 99 id 0    
debug2: exec request accepted on channel 0    
debug1: client_input_channel_req: channel 0 rtype exit-status reply 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    
debug2: channel 0: rcvd close    
debug2: channel 0: close_read    
debug2: channel 0: input open -> closed    
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 cc -1)
debug1: fd 0 clearing O_NONBLOCK   
debug1: fd 1 clearing O_NONBLOCK    
debug1: fd 2 clearing O_NONBLOCK    
Transferred: sent 3736, received 2280 bytes, in 0.0 seconds    
Bytes per second: sent 764498.2, received 466556.7    
debug1: Exit status 1    
backup@ar-secubn03:/var/scripts$ 

Prueba esto:

scp -vvv 'backup@hostname:/var/stuff/backups/*.tgz' /data/backups/

Si eso no funciona, intente esto:

scp -vvv 'backup@hostname:/var/stuff/backups/\*.tgz' /data/backups/

debug1: Sending command: scp -v -f /var/stuff/backups/*.tgz    
debug2: channel 0: request exec confirm 1    
debug2: callback done    
debug2: channel 0: open confirm rwindow 0 rmax 32768    
debug2: channel 0: rcvd adjust 131072    
debug2: channel_input_status_confirm: type 99 id 0    
debug2: exec request accepted on channel 0    
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
...
debug1: Exit status 1

Estas líneas indican que la instancia scp local solicitó el scpcomando esperado para ejecutarse en el sistema remoto, y el servidor remoto inició un proceso en respuesta a la solicitud. Pero el proceso remoto salió con el código de estado 1 casi de inmediato, y sin emitir ningún resultado.

Si la instancia remota de scp no pudiera leer los archivos que se copiarán, o si esos archivos no existieran, habría recibido un mensaje de error en ese sentido. Si no se pudo encontrar el programa scp remoto o no era ejecutable, entonces el código de salida habría sido 126 o 127 en lugar de 1.

Sospecho que una de estas cosas está sucediendo:

1. Algo en el .bashrc o .bash_profile de la cuenta remota está causando que el shell salga temprano. Puede ser sensible al hecho de que la sesión no tiene un TTY, por ejemplo.
2. El scpprograma en el sistema remoto está dañado o no funciona correctamente.
3. El scpprograma en el sistema remoto ha sido reemplazado por algo más que no funciona como scp. Alguien podría haberlo reemplazado con un script de shell mal escrito, por ejemplo, o una copia de '/ bin / false'.
4. El software SSH se ha configurado para impedir que las personas ejecuten scp. La clave que está utilizando puede configurarse authorized_keyspara ejecutar un comando específico, o puede haber una ForceCommanddirectiva en el sshd_configarchivo del servidor remoto .

La forma más sencilla de verificar esto sería preguntarle al administrador del sistema remoto o iniciar sesión en el sistema remoto e inspeccionar el ejecutable scp. La ejecución scp -himprimirá un mensaje de uso específico de scp, por ejemplo.

Si tiene que solucionar esto de forma remota, lo siguiente que intentaré es algo como esto:

$ ssh -T backup@hostname cat /etc/group

Esto debería escribir el archivo de grupo del sistema remoto en su terminal. Esto probaría que puede ejecutar comandos arbitrarios en el sistema remoto.

$ ssh -T backup@hostname scp -v -f /etc/group < /dev/zero

Esto simula la parte remota de una scpsesión. Si el programa scp remoto funciona, debería obtener una salida como esta:

C0644 674 group
root:x:0:
daemon:x:1:
[...]
devuser:x:1001:
Sending file modes: C0644 674 group
$ 

Si todo eso funciona, la pregunta es por qué scpfalla para "/var/stuff/backups/*.tgz" pero funciona para "/ etc / group". Puede ejecutar esto para confirmar si funciona o no:

ssh -T backup@hostname 'scp -v -f /var/stuff/backups/*.tgz' < /dev/zero

Si eso sigue fallando, la opción nuclear sería organizar la ejecución de la sesión remota stracey ver exactamente qué está haciendo cada programa.

Su problema está claramente identificado en estas líneas:

debug2: exec request accepted on channel 0    
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0    
debug2: channel 0: rcvd eof    

que muestra que tu canal se cierra tan pronto como se abre, aunque no se indica el motivo.

Normalmente, esto ocurre debido a una configuración defectuosa en el archivo / etc / passwd, consulte, por ejemplo, esta publicación de Falla del servidor . Puede seguir las sugerencias en esta publicación o, mejor aún, puede verificar los registros en la máquina de destino,

 tail /var/log/auth.log

para mas detalles.

Creo que haces las primeras copias de seguridad / * .tgz para cambiar las copias de seguridad * .tgz asegúrate de no usar ningún espacio. podría haber un 99% de problema resuelto.

Tuve la misma mala experiencia. Una ligera modificación del .bashrc en el sistema remoto fue el problema. Una vez agregué 'ulimit' y obtuve este problema durante el próximo scp (ssh funcionó). Después de eliminar esta línea, todo estuvo bien.

Estaba teniendo un problema similar con el que podía ejercer sshcomandos, pero no scpcomandos. Revisé las buenas técnicas de depuración de Kenster que todavía no me llevaron a ninguna parte, ¡pero muy útiles! Finalmente descubrí que el problema estaba relacionado con los echocomandos en mi .bashrcscript (después de insertar otros). Una vez que comenté todos los echocomandos en el script, pude ejecutar con éxito el scpcomando.