Eu estou tentando copiar minha chave ssh da minha vm local para outra caixa, tudo parece funcionar bem, mas quando eu verificar a caixa remota, o arquivo não está lá ...
Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.0 seconds
O scp não parece estar escrevendo nada, mas eu não faço ideia do porquê!
Eu pensei que talvez seja porque a rede interna não está exposta e talvez não seja capaz de falar com a caixa remota através do scp, mas parece estar fazendo algum handshaking ... Quando eu scp para uma caixa na rede ele funciona bem = /
Por que o scp não trabalha aqui?
Eu verifiquei as permissões na caixa remota parece ok ...
Nenhuma mensagem de erro ...
scp -v output
[user] > scp -v my.key.pub [email protected]:.ssh/
Executing: program /usr/bin/ssh host domain.net, user www, command scp -v -t .ssh/
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to domain.net [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'domain.net' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:11
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password
[user] > [email protected]'s password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: scp -v -t .ssh/
Bash Src is loaded!
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0
O que é isso "O Bash Src está carregado!" na saída detalhada? Está vindo do seu ~ / .bashrc, não é? Faça isso ir embora.
Basicamente, é o mesmo que isso: Rsync parece incompatível com .bashrc (causa "é seu shell limpo?") mas com scp em vez de rsync.
Olá, existe até uma entrada no FAQ: link
Se você é incapaz de transferir qualquer arquivos, é provável que seja devido ao seu .bashrc (ou equivalente) fazendo coisas que não deveria durante logins não-interativos (ie quando rsync'ing, scp'ing, etc); nos velhos e maus dias, 'stty' era particularmente notório por causar problemas como esse. Consulte o link para obter algumas dicas sobre como verificar se o seu shell é interativo ou não.
Tags permissions scp remote