scp permissão negada quando um usuário executa o comando scp para arquivos de propriedade em seu diretório pessoal

Question

Eu verifiquei muitas postagens sobre o erro 'Permissão negada' ao usar scp , mas não consegui encontrar a resposta para o meu problema.

Existem dois servidores Ubuntu (digamos, servidor 'A' e 'B') na mesma rede na AWS, e quando eu tentei copiar um arquivo para outro servidor, A para B não está funcionando, mas de B para Um funciona. (Por favor veja abaixo)

No servidor 'A',

ubuntu@server-a ~ $ ls -alt server*
-rwxr-xr-x 1 ubuntu ubuntu 8152 Aug  9 14:26 server.xml.bak

ubuntu@server-a ~ $ scp -P 443 server.xml.bak [email protected]:/home/ubuntu/
Permission denied (publickey).
lost connection

ubuntu@server-a ~ $ scp -P 443 /home/ubuntu/server.xml.bak [email protected]:/home/ubuntu/
Permission denied (publickey).
lost connection

Também tentei copiar o arquivo remoto para aqui e ele também falhou.

ubuntu@server-a ~ $ scp -P 443 [email protected]:/home/ubuntu/sakila.sql .
Permission denied (publickey).

Mas do servidor 'B', tudo funcionou.

ubuntu@server-b ~ $ scp -P 443 [email protected]:/home/ubuntu/server.xml.bak .
server.xml.bak                                                    100% 8152     8.0KB/s   00:00

ubuntu@server-b ~ $ scp -P 443 sakila.sql [email protected]:/home/ubuntu/
sakila.sql                                                        100% 3153KB   3.1MB/s   00:00

Como você vê, não é o problema de permissão - todas as operações foram feitas pelo 'ubuntu' no 'ubuntu' home e os arquivos também são de propriedade do 'ubuntu' com o modo 755.

Então, agora estou confuso sobre o que está errado.

    

Answer 1

Como sugerido, passo o meu comentário original para a resposta com mais detalhes, caso alguém tenha um problema semelhante.

Eu recebi uma dica do comentário do @lgeorget - eu corri o comando com scp -v e descobri que é devido à falta da chave privada.

Por motivos de segurança, removi todas as chaves privadas nos servidores e usei o Pageant para o gerenciamento de chaves privadas. Nesse cenário, conectei-me a B (B é um servidor de bastiões) usando o PuTTY, abri um outro terminal PuTTY, conectei-o novamente a B e, em seguida, conectei-me a A via ssh. Portanto, o Pageant pode manipular a chave privada para B, mas não pode para A diretamente (não consegui reconhecer isso)
O resultado é que o comando scp de B para o servidor de destino A funciona, mas o scp de A para o servidor de destino B não funciona.

Eu carrego a chave privada para A para testes e o comando scp da A também funciona bem.

Como não posso manter chaves privadas nos servidores, acho que só devo usar o comando scp no servidor B.