Puedo iniciar sesión a través de SSH usando la autenticación de clave para SERVER1 y SERVER2. Sin embargo, no puedo copiar archivos entre los dos servidores. ¿Por qué? ¿Cómo puedo copiar entre ellos? (los datos que tengo que copiar son más grandes que los discos duros de mis portátiles)
Mi computadora portátil ejecuta Ubuntu 10.04 LTS y los dos servidores son AIX 5300-10-02-0943. Mi ~/.ssh/known_hosts
archivo en mi cuaderno contiene las claves públicas para estos dos servidores. Lo uso tsocks
porque tengo que usar un túnel SSH para llegar a estos dos servidores. Los dos servidores pueden hacer ping entre sí.
[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 [email protected]
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 ~]
Respuestas:
Esto es muy fácil de arreglar. Vea, el servidor de origen no conoce el servidor de destino y no puede pedirle que confirme la identidad, ya que no tiene una terminal abierta allí:
Tan solo inicie sesión en la cuenta / servidor de origen e intente ssh (o scp) en la cuenta de destino, acepte la clave de host y cancele el inicio de sesión / scp. Deberías poder copiar.
Si no, intente:
Si tiene una clave SSH con acceso al servidor de destino y el servidor de origen no, la adición
-o "ForwardAgent=yes"
le permitirá reenviar su agente SSH al servidor de origen para que pueda usar su clave SSH para conectarse al servidor de destino.fuente
Un pequeño diagnóstico: de esto
Sospecho (supongo) que funciona de esta manera, la copia de servidor a servidor con
scp
registrosSERVER1
y ejecuta elscp
comando para enviar el archivoSERVER2
; así, la persona que llama (desdeSERVER1
) tiene que autenticarse a sí misma. Ahora esto falla ya que no es interactivo (no hay/dev/tty
) y no hay forma de pedir una frase de contraseña.Esto significa que copiar la clave en
SERVER1
(no puedo decir si esto es posible en su situación) probablemente podría solucionar el problema (creo ...) ( Si no hay una frase de contraseña ... lo cual es bastante malo )Editar Una solución podría ser la siguiente, usar
sshfs
para acceder a los archivos que desea enviar, enviarlosscp
desde elsshfs
directorio montado. Esto debería proporcionarle la interactividad necesaria (si la suposición anterior era correcta) y mantener todas las claves locales.fuente
ssh SERVER1 scp *args-YOU-specifiy*
para un poco más de flexibilidad. Quizás algúnstdin
truco podría ayudar ... No estoy seguro.ssh-agent
) suena mucho mejor que elstdin
engaño.He intentado esto y me funciona entre dos sistemas, algunas diferencias:
ssh-add
)Intenta lo siguiente:
fuente
es posible que desee utilizar la
-3
opción de scp, que dirige el tráfico a través de su computadora portátil.es decir
[USER@NOTEBOOK ~] scp -3 root@SERVER1:/PATH/TO/DIR root@SERVER2:/PATH/TO/DIR
fuente
Pruebe estas opciones para ssh:
En mi caso, intento conectarme con ssh desde SP dentro de postgreSQL. Primer intento fallido:
La fuente del problema: no se puede escribir en know_host
Siguiente salida de conexión:
éxito !!!
fuente