Comment copier avec SCP entre deux serveurs en utilisant l'authentification par clé?


16

Je peux me connecter via SSH en utilisant l'authentification par clé sur SERVER1 et SERVER2. Cependant, je ne peux pas copier de fichiers entre les deux serveurs. Pourquoi? Comment puis-je copier entre eux? (les données que je dois copier sont plus grandes que le disque dur de mon ordinateur portable)

Mon ordinateur portable fonctionne sous Ubuntu 10.04 LTS et les deux serveurs sont AIX 5300-10-02-0943. Mon ~/.ssh/known_hostsfichier sur mon carnet contient les clés publiques de ces deux serveurs. J'utilise tsockscar je dois utiliser un tunnel SSH pour atteindre ces deux serveurs. Les deux serveurs peuvent se cingler.

[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 ~] 

/ dev / tty existe-t-il? essayez ceci: ben.goodacre.name/tech/Can't_open_/dev/…
vj-

Réponses:


10

C'est très facile à corriger. Vous voyez, le serveur source ne connaît pas le serveur de destination et il ne peut pas vous demander de confirmer l'identité, car vous n'avez pas de terminal ouvert là-bas:

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

Connectez-vous simplement au compte / serveur source et essayez de ssh (ou scp) au compte dest, acceptez la clé d'hôte et annulez la connexion / scp. Vous devriez pouvoir copier.

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

Sinon, essayez:

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

Si vous avez une clé SSH avec accès au serveur de destination et pas le serveur source, l'ajout -o "ForwardAgent=yes"vous permettra de transférer votre agent SSH vers le serveur source afin qu'il puisse utiliser votre clé SSH pour se connecter au serveur de destination.


7

Un petit diagnostic: à partir de là

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

Je soupçonne (suppose) que cela fonctionne de cette façon, la copie de serveur à serveur avec les scpjournaux SERVER1et exécute la scpcommande pour envoyer le fichier SERVER2; ainsi, l'appelant (de SERVER1) doit s'authentifier. Maintenant, cela échoue car il n'est pas interactif (il n'y en a pas /dev/tty) et il n'y a aucun moyen de demander une phrase secrète.

Cela signifie que la copie de la clé SERVER1(je ne peux pas dire si cela est possible dans votre situation) pourrait probablement résoudre le problème (je pense ...) ( S'il n'y a pas de phrase secrète ... ce qui est plutôt mauvais )

Modifier Une solution pourrait être la suivante, utilisez sshfspour accéder aux fichiers que vous souhaitez envoyer, envoyez-les via scpdepuis le sshfsrépertoire -mounted. Cela devrait vous procurer l'interactivité nécessaire (si la supposition ci-dessus était juste) et garder toutes les clés locales.


sshfs n'est pas une option.
LanceBaynes

Le problème est donc que SERVER1 ne peut pas ssh vers SERVER2 avec l'authentification par clé? Existe-t-il des paramètres client ssh pour utiliser la clé sur mon ordinateur portable?
LanceBaynes

2
Aucune idée, j'ai peur. Vous pouvez cependant utiliser ssh SERVER1 scp *args-YOU-specifiy*pour un peu plus de flexibilité. Peut-être qu'une stdinruse pourrait aider ... Je ne suis pas sûr.
sr_

2
La réponse (en utilisant ssh-agent) de @ utopiabound sonne beaucoup mieux questdin ruse.
sr_

3

J'ai essayé cela et cela fonctionne pour moi entre deux systèmes, quelques différences:

  • J'ai un agent SSH en cours d'exécution avec ma clé SSH ajoutée ( ssh-add)
  • J'ai le transfert ssh-agent activé par défaut

Essayez ce qui suit:

ssh-add
scp -v -o "ForwardAgent=yes" -p -r root@SERVER1:/PATH/TO/DIR root@SERVER2:/PATH/TO/DIR  

toujours "La vérification de la clé de l'hôte a échoué."
LanceBaynes

@LanceBaynes Assurez-vous que vous vous êtes connecté à SERVER2 à partir de SERVER1 en tant que root. Peut-être que vous ne l'avez pas dans le fichier d'hôtes connu de root sur SERVER1?
utopiabound

1

vous voudrez peut-être utiliser l' -3option de scp, il dirige le trafic via votre ordinateur portable.

c'est à dire [USER@NOTEBOOK ~] scp -3 root@SERVER1:/PATH/TO/DIR root@SERVER2:/PATH/TO/DIR


0

Essayez ces options pour ssh:

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

Dans mon cas, j'essaye de me connecter avec ssh depuis l'intérieur du SP dans postgreSQL. Échec de la première tentative:

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.

La source du problème: impossible d'écrire dans 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

Sortie de connexion suivante:

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

Succès !!!

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.