Não é possível fazer um pull de SCP apesar do SSH funcionar bem

Question

Tenho autenticação de chave de configuração entre dois servidores e posso ssh in sem uma chave, por exemplo:

ssh backup@hostname

isso funciona bem e me conecta. Mas quando eu tento um SCP para puxar um arquivo, não recebo arquivos.

Os arquivos de destino têm chmod 777 feito para eles para solução de problemas, mas é como se ele simplesmente não encontrasse nenhum arquivo para copiar, mesmo que eles estejam lá.

Aqui está a saída (ip ofuscada) de

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

do ponto em que ele autentica.

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$ 

    

Answer 1

Tente isto:

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

Se isso não funcionar, tente isto:

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

    

Answer 2

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

Essas linhas indicam que a instância scp local solicitou que o comando scp esperado fosse executado no sistema remoto e o servidor remoto iniciou um processo em resposta à solicitação. Mas o processo remoto saiu com o código de status 1 quase imediatamente e sem emitir nenhuma saída.

Se a instância do scp remoto não conseguisse ler os arquivos a serem copiados, ou se esses arquivos não existissem, você teria recebido uma mensagem de erro. Se o programa scp remoto não puder ser encontrado ou não fosse executável, o código de saída teria sido 126 ou 127 em vez de 1.

Eu suspeito que uma dessas coisas está acontecendo:

1. Algo no .bashrc ou .bash_profile da conta remota está fazendo com que o shell saia mais cedo. Pode ser sensível ao fato de a sessão não ter um TTY, por exemplo.
2. O programa scp no sistema remoto está corrompido ou está com defeito.
3. O programa scp no sistema remoto foi substituído por outro que não está funcionando como o scp. Alguém pode tê-lo substituído por um script de shell mal escrito, por exemplo, ou uma cópia de '/ bin / false'.
4. O software SSH foi configurado para impedir que pessoas executem o scp. A chave que você está usando pode ser definida em authorized_keys para executar um comando específico ou pode haver uma diretiva ForceCommand no arquivo sshd_config do servidor remoto.

A maneira mais simples de verificar isso seria perguntar ao administrador do sistema remoto ou efetuar login no sistema remoto e inspecionar o executável do scp. Executar scp -h imprimirá uma mensagem de uso específica do scp, por exemplo.

Se você precisar solucionar isso remotamente, a próxima coisa que eu tentarei é algo assim:

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

Isso deve gravar o arquivo de grupo do sistema remoto no seu terminal. Isso provaria que você pode executar comandos arbitrários no sistema remoto.

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

Isso simula a parte remota de uma sessão scp . Se o programa scp remoto estiver funcionando, você deverá obter algo como:

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

Se tudo isso funcionar, a questão é porque scp falha em "/var/stuff/backups/*.tgz", mas funciona para "/ etc / group". Você pode executar isso para confirmar se está funcionando ou não:

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

Se isso continuar a falhar, a opção nuclear seria organizar a sessão remota em strace e ver exatamente o que cada programa está fazendo.

    

Answer 3

Seu problema é claramente identificado nestas linhas:

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 mostra que o seu canal é encerrado assim que é aberto, embora o motivo não esteja indicado.

Normalmente, isso ocorre devido a uma configuração defeituosa no arquivo / etc / passwd, veja por exemplo esta postagem de falha do servidor . Você pode seguir as sugestões desta postagem ou, melhor ainda, verificar os registros na máquina de destino,

 tail /var/log/auth.log

para mais detalhes.

    

Answer 4

Acho que você faz 1 backups / * .tgz para alterar backups * .tgz Certifique-se de não usar nenhum espaço. pode ser 99% problema resolvido.

    

Answer 5

Eu tive a mesma experiência ruim. Eu ligeira modificação do .bashrc no sistema remoto foi o problema. Uma vez adicionei 'ulimit' e obtive o problema durante o próximo scp (ssh funcionou). Depois de remover essa linha, tudo estava bem.