Estou tentando mover um arquivo de uma máquina virtual (Ubuntu 18.04) no meu sistema local para um servidor remoto usando um comando scp muito básico. Esse problema está presente apenas em um servidor específico, outros funcionam bem, por isso não é uma coisa genérica.
scp <file name> <user>@<complete_hostname>:~/
Mas este comando não prossegue além da autenticação, o que é bem sucedido.
O mesmo acontece quando eu uso o FileZilla.
A equipe de TI me aconselhou a usar o 'WinSCP', que funciona bem.
log de depuração do scp
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/username/.ssh/id_dsa
debug1: Trying private key: /home/username/.ssh/id_ecdsa
debug1: Next authentication method: password
'user'@'full hostname's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = C
debug1: Sending env LC_ALL = C
debug1: Sending command: scp -v -t ~/
Não há progresso após isso, o FileZilla expira após 20 segundos de maneira semelhante. enquanto o WinSCP funciona bem.
O que pode fazer o scp travar, já que estou usando isso em alguns dos meus scripts, esse problema com um servidor em particular tornou meus scripts inutilizáveis neles, e isso também se aplica aos métodos SFTP.
A equipe de TI me avisou para não usar os sinalizadores -d e -t ao emitir o comando, pois o mesmo aparece no log de depuração e não é suportado pelo servidor remoto. Podem ser removidos? Eu não os expliquei explicitamente com o comando.
Editar 2:
SCP Log: (from local machine, Ubuntu 18.04)
==========
debug1: Next authentication method: publickey
debug1: Offering public key:
RSA SHA256:<key> /home/username/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to 'HOSTNAME' ([10.6.26.145]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LANG = en_IN
debug1: Sending command: scp -v -r -d -t ~/received/
Isso acaba sendo um firewall bloqueando a transferência. Razão de ser a permissão de arquivo no arquivo . * Rc do meu shell padrão. .cshrc neste caso.
Meu shell padrão é csh, e a permissão de arquivo era
-rwxr-s---
Alterando-os para
-rw-r-----
resolveu o problema.
Obrigado a todos pela ajuda.
The IT Team advised me to not use the flags
-dand-twhile issuing the command as the same shows up on the debug log and is not supported by the remote server. Can these be removed? I did not explicitly issue them with the command.
-t - Isso é um absurdo total. O protocolo SCP não pode funcionar sem o sinalizador -t . Consulte Como a transferência de arquivos SCP (protocolo de cópia segura) está funcionando?
-d - É usado quando você especifica mais de uma fonte. Indica ao servidor que o "destino deve ser o diretório".
Em ambos os casos, duvido que o servidor não suporte nenhum deles. Como é o Ubuntu, ele está executando o OpenSSH com 99,9% de certeza. E o OpenSSH suporta esses sinalizadores desde que ele existe. Veja scp.c de 1999 .
Tenho certeza de que o conselho que você recebeu é apenas um disparate. A "equipe de TI" provavelmente não encontrou essas opções na página scp man e facilitou sua ajuda. Mas esses sinalizadores são sinalizadores internos usados para comunicação entre scp como "cliente" e scp como "servidor". Eles não são documentados por propósito.
O FileZilla também não suporta o protocolo SCP. O que contribui apenas para o acima - Seu problema não tem nada a ver com qualquer " scp flags" .
Tags scp linux file-transfer winscp