scp não funciona, mas o ssh não

Question

Minha máquina local e minha máquina remota estão conectadas à mesma rede, ou seja, meu hotspot Android Phone. Posso conectar a maquina remota por ssh mas, o problema é quando estou tentando copiar alguns arquivos em maquina remota, estou enfrentando mensagens de erro, o estranho é que ontem scp estava funcionando, mas hoje scp -v file.txt [email protected]:/root dando seguinte mensagem de erro:

Executing: program /data/data/com.termux/files/usr/bin/ssh host 191.168.43.85, user root, command scp -v -t /root
OpenSSH_7.7p1, OpenSSL 1.0.2o  27 Mar 2018
debug1: Reading configuration data /data/data/com.termux/files/usr/etc/ssh/ssh_config
debug1: Connecting to 191.168.43.85 [191.168.43.85] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /data/data/com.termux/files/home/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /data/data/com.termux/files/home/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /data/data/com.termux/files/home/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /data/data/com.termux/files/home/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /data/data/com.termux/files/home/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /data/data/com.termux/files/home/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /data/data/com.termux/files/home/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /data/data/com.termux/files/home/.ssh/id_ed25519-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /data/data/com.termux/files/home/.ssh/id_xmss type -1
debug1: key_load_public: No such file or directory
debug1: identity file /data/data/com.termux/files/home/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.7
ssh_exchange_identification: read: Connection reset by peer
lost connection

Aqui está o conteúdo de ~/.ssh dobrado da máquina local

# ls -la .ssh
total 12
drwx------  2 u0_a334 u0_a334 4096 Jul 25 12:33 .
drwx------ 36 u0_a334 u0_a334 4096 Jul 25 12:05 ..
-rw-------  1 u0_a334 u0_a334    0 Jul 25 12:33 authorized_keys
-rw-r--r--  1 u0_a334 u0_a334  175 Jul 25 11:51 known_hosts

Eu verifiquei /etc/hosts.deny todas as coisas são comentadas, por isso não é culpado.

Aqui está o conteúdo do arquivo known_hosts da máquina local

# cat .ssh/known_hosts
192.168.43.85 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBB4scw5vCUl2dssTS97+5QhiMBIk+/Tc15LoqAoS05i99jMOwRwyRpoNcKTk52d5hprkI7ECIGC9Qrh1KcIniFM=

Acho que não é duplicado isso Tentando acessar o servidor SSH e obtendo key_load_public: Nenhum arquivo ou erro de diretório

Porque minha situação é um pouco diferente, pois ainda posso controlar minha máquina remota por meio de ssh [email protected] . A propósito, tentei todas as soluções de Tentando acessar o servidor SSH e obtendo key_load_public: Nenhum erro de arquivo ou diretório

Editar

Depois de gerar chaves privadas, tudo está funcionando bem, mas ainda estou confuso porque o scp estava funcionando sem chaves privadas.

    

Answer 1

O problema é que scp tenta usar chaves privadas ssh que não estão no lugar - não há chaves nesessary id_rsa , id_dsa , id_ecdsa dentro do diretório

/data/data/com.termux/files/home/.ssh/

desde o comando

ls -la /data/data/com.termux/files/home/.ssh/

retorna

total 12
drwx------  2 u0_a334 u0_a334 4096 Jul 25 12:33 .
drwx------ 36 u0_a334 u0_a334 4096 Jul 25 12:05 ..
-rw-------  1 u0_a334 u0_a334    0 Jul 25 12:33 authorized_keys
-rw-r--r--  1 u0_a334 u0_a334  175 Jul 25 11:51 known_hosts

Existem duas possibilidades para corrigir o erro.

A primeira possibilidade é copiar chaves privadas solicitadas (possivelmente uma delas ou algumas delas) id_rsa , id_dsa , id_ecdsa no diretório /data/data/com.termux/files/home/.ssh/ .

A segunda possibilidade é instruir explicitamente scp para usar alguma chave privada definida com a opção -i (identity_file), ou seja,

scp -i /path/to/id_rsa file.txt [email protected]:/root

Se você não sabe onde seus arquivos de identidade são armazenados, mas ssh funciona (conforme observado no OP), execute a opção ssh with verbose e localize o caminho do log de conexão ao arquivo de identidade usado por ssh :

ssh -vvv [email protected]