Execute scp com o modo verbose (-vvv) e veja se você consegue identificar o problema lá. Pode ser que as permissões no seu arquivo .ssh / authorized_key no destino (ou mesmo na origem) sejam muito abertas.
Tentando copiar os arquivos do servidorB para o servidorA e obter o seguinte erro:
root@server:~# scp /root/test.txt [email protected]:/home/somefolder/
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
lost connection
No serverA eu criei um par de chaves pública / privada sem senha. No servidorB, adicionei a chave pública ao arquivo .ssh / authorized_keys. Tanto a pasta como o arquivo são de propriedade do root.
Eu originalmente tentei isso com uma frase secreta ... já que não estava funcionando, criei outra chave sem uma frase secreta. Ambos estão dando os mesmos resultados.
Este não é um problema de firewall. serverA é centos. serverB é o Ubuntu.
Execute scp com o modo verbose (-vvv) e veja se você consegue identificar o problema lá. Pode ser que as permissões no seu arquivo .ssh / authorized_key no destino (ou mesmo na origem) sejam muito abertas.
Acontece que eu precisava especificar a identidade no comando scp algo assim:
scp -rp -i / root /.ssh / servidor / home / user-data / * [email protected]: / home / user-data
onde '/root/.ssh/server' é o local da chave privada a ser usada. Permissões e propriedade devem estar corretas também.
O problema que me ocorreu com isso foi a conta de usuário foi bloqueada. Um estrondo (caractere de ponto de exclamação) estava no campo / etc / shadow password, o que significava que a conta estava bloqueada. Para consertar, eu tive que
sudo vi /etc/shadow
E mude o "!!" para '*'. Como alternativa, você pode definir uma senha para a conta
sudo passwd newacct
Veja também O que significa * no arquivo passwd
O que você vê no arquivo /var/log/secure ? Provavelmente .ssh/* tem permissões ruins.
Você pode tentar executar o comando ssh -v para ver qual é o problema.
Tags scp