Como copiar com o SCP entre dois servidores usando a autenticação de chave?

16

Posso efetuar login via SSH usando a autenticação de chave em SERVER1 e SERVER2. No entanto, não consigo copiar arquivos entre os dois servidores. Por quê? Como posso copiar entre eles? (os dados que tenho que copiar são maiores que o disco rígido do meu notebook)

Meu notebook roda o Ubuntu 10.04 LTS e os dois servidores são o AIX 5300-10-02-0943. Meu ~/.ssh/known_hostsarquivo no meu notebook contém as chaves públicas desses dois servidores. Eu uso tsocksporque tenho que usar um túnel SSH para alcançar esses dois servidores. Os dois servidores podem executar ping um no outro.

[USER@NOTEBOOK ~] tsocks scp -v -i /home/USER/.ssh/id_rsa -p -r root@SERVER1:/PATH/TO/DIR root@SERVER2:/PATH/TO/DIR
Executing: /usr/bin/ssh '-v' '-x' '-oClearAllForwardings yes' '-n' '-l' 'root' 'SERVER1' 'scp -v -r -p' '/PATH/TO/DIR' 'root@SERVER2:/PATH/TO/DIR'
OpenSSH_5.3p1 Debian-3ubuntu7, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to SERVER1 [SERVER1] port 22.
debug1: Connection established.
debug1: identity file /home/USER/.ssh/identity type -1
debug1: identity file /home/USER/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-1024
debug1: identity file /home/USER/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2p1+sas
debug1: match: OpenSSH_5.2p1+sas pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7
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 'SERVER1' is known and matches the RSA host key.
debug1: Found key in /home/USER/.ssh/known_hosts:59
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: Offering public key: /home/USER/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 151
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.utf8
debug1: Sending command: scp -v -r -p /PATH/TO/DIR root@SERVER2:/PATH/TO/DIR
Executing: program /applications/ssh/5.20.15.0/bin/ssh host SERVER2, user root, command scp -v -r -p -t /PATH/TO/DIR
OpenSSH_5.2p1+sas, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to SERVER2 [SERVER2] 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: Remote protocol version 2.0, remote software version OpenSSH_5.2p1+sas
debug1: match: OpenSSH_5.2p1+sas pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
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: read_passphrase: can't open /dev/tty: No such device or address
Host key verification failed.
lost connection
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 1984, received 3848 bytes, in 0.3 seconds
Bytes per second: sent 6903.4, received 13389.2
debug1: Exit status 1


[USER@NOTEBOOK ~] tsocks scp -i /home/USER/.ssh/id_rsa -p -r root@SERVER1:/PATH/TO/DIR root@SERVER2:/PATH/TO/DIR
Host key verification failed.
lost connection
[USER@NOTEBOOK ~]
ssh  scp 
— LanceBaynes
fonte
/ dev / tty existe? tente o seguinte: ben.goodacre.name/tech/Can't_open_/dev/...
— vj-

Respostas:

10

Isso é muito fácil de consertar. Veja, o servidor de origem não conhece o servidor de destino e não pode solicitar que você confirme a identidade, pois você não tem um terminal aberto lá:

debug1: read_passphrase: can't open /dev/tty: No such device or address
Host key verification failed.
lost connection

Portanto, basta fazer login na conta / servidor de origem e tentar ssh (ou scp) na conta de destino, aceitar a chave do host e cancelar o login / scp. Você deve conseguir copiar.

local $ ssh source@src-server
src-server $ ssh dest@dst-server
The authenticity of host 'destination (10.0.0.x)' can't be established.
RSA key fingerprint is 71:ec:c0:86:7f:b6:51:eb:76:c8:1f:2f:ba:0a:f4:20.
Are you sure you want to continue connecting (yes/no)? yes
dest@dst-server's password: ^C
src-server $ exit

local $ scp -r source@src-server:/path/to/files dest@dst-server:/path/to/files

Caso contrário, tente:

local $ scp -r -o "ForwardAgent=yes" source@src-server:/path/to/files dest@dst-server:/path/to/files

Se você tiver uma chave SSH com acesso ao servidor de destino e o servidor de origem não, a adição -o "ForwardAgent=yes"permitirá que você encaminhe seu agente SSH para o servidor de origem, para que ele possa usar sua chave SSH para conectar-se ao servidor de destino.

— alecco
fonte
7

Um pequeno diagnóstico: a partir disso

debug1: Sending command: scp -v -r -p /PATH/TO/DIR root@SERVER2:/PATH/TO/DIR
[...]
debug1: read_passphrase: can't open /dev/tty: No such device or address

Eu suspeitaria (acho) que funciona dessa maneira, a cópia de servidor para servidor com scplogs SERVER1e executa o scpcomando para enviar o arquivo SERVER2; assim, o chamador (de SERVER1) precisa se autenticar. Agora, isso falha porque não é interativo (não existe /dev/tty) e não há como solicitar uma senha.

Isso significa que copiar a chave para SERVER1(eu não sei dizer se isso é possível na sua situação) provavelmente poderia resolver o problema (eu acho ...) ( se não houver uma senha ... o que é bastante ruim )

Editar Uma solução poderia ser a seguinte, use sshfspara acessar os arquivos que você deseja enviar, enviá-los através scpdo sshfsdiretório Montada. Isso deve proporcionar a interatividade necessária (se o palpite acima estiver correto) e manter todas as chaves locais.

— sr_
fonte
O sshfs não é uma opção.
— LanceBaynes
Portanto, o problema é que o SERVER1 não pode ssh para o SERVER2 com autenticação de chave? Existem parâmetros de cliente ssh para que isso use a tecla do meu notebook?
— LanceBaynes
2
Não faço ideia, eu tenho medo. Você pode, no entanto, usar ssh SERVER1 scp *args-YOU-specifiy*um pouco mais de flexibilidade. Talvez alguns stdintruques possam ajudar ... Não tenho certeza.
— sr_
2
A resposta de @ utopiabound (usando ssh-agent) soa muito melhor que stdintruques.
— sr_
3

Eu tentei isso e funciona para mim entre dois sistemas, algumas diferenças:

  • Eu tenho um agente SSH executando com minha chave SSH adicionada ( ssh-add)
  • Eu tenho o encaminhamento de agente ssh ativado por padrão

Tente o seguinte: 

ssh-add
scp -v -o "ForwardAgent=yes" -p -r root@SERVER1:/PATH/TO/DIR root@SERVER2:/PATH/TO/DIR
— sombrio
fonte
ainda "Falha na verificação da chave do host".
— LanceBaynes
@LanceBaynes Verifique se você fez login no SERVER2 a partir do SERVER1 como root. Talvez você não o tenha no arquivo hosts conhecidos da raiz no SERVER1?
— Utopiabound
1

Se você quiser usar a -3opção scp, ele direciona o tráfego através do seu notebook.

ie [USER@NOTEBOOK ~] scp -3 root@SERVER1:/PATH/TO/DIR root@SERVER2:/PATH/TO/DIR

— törzsmókus
fonte
0

Experimente estas opções para ssh:

-o StrictHostKeyChecking=no
-o UserKnownHostsFile=.ssh/known_hosts [OPTIONAL]

No meu caso, eu estou tentando conectar com o ssh de dentro do SP no postgreSQL. Primeira tentativa falhou:

pc_ubuntu_db=# SELECT command('ssh -q -v admin@10.30.134.26 hostname');
debug1: Server host key: RSA 0a:28:83:72:d7:7d:89:93:96:a1:1b:e2:f9:22:85:62 
debug1: read_passphrase: can't open /dev/tty: No such device or address
        Host key verification failed.

A fonte do problema: não é possível escrever no know_host

pc_ubuntu_db=# SELECT command('ssh -v -o StrictHostKeyChecking=no -i admin@10.30.134.26 hostname');
debug1: Server host key: RSA 0a:28:83:72:d7:7d:89:93:96:a1:1b:e2:f9:22:85:62
Warning: Permanently added '10.30.134.26' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
...
Transferred: sent 2672, received 2040 bytes, in 0.0 seconds
Bytes per second: sent 214358.6, received 163657.0
debug1: Exit status 0

Próxima saída de conexão:

debug1: Server host key: RSA 0a:28:83:72:d7:7d:89:93:96:a1:1b:e2:f9:22:85:62
debug1: Host '10.30.134.26' is known and matches the RSA host key.
debug1: Found key in /var/lib/postgresql/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct

sucesso !!!

— GHReyes
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.