Mogę zalogować się przez SSH przy użyciu uwierzytelniania klucza na SERWER1 i SERWER2. Nie mogę jednak kopiować plików między dwoma serwerami. Dlaczego? Jak mogę kopiować między nimi? (dane, które muszę skopiować, są większe niż dyski twarde moich notebooków)
Mój notebook działa pod kontrolą Ubuntu 10.04 LTS, a dwa serwery to AIX 5300-10-02-0943. Mój ~/.ssh/known_hosts
plik na moim notebooku zawiera klucze publiczne dla tych dwóch serwerów. Używam, tsocks
ponieważ muszę korzystać z tunelu SSH, aby dotrzeć do tych dwóch serwerów. Dwa serwery mogą pingować się nawzajem.
[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 ~]
Odpowiedzi:
Jest to bardzo łatwe do naprawienia. Serwer źródłowy nie zna serwera docelowego i nie może prosić o potwierdzenie tożsamości, ponieważ nie ma tam otwartego terminalu:
Zaloguj się do konta źródłowego / serwera i spróbuj ssh (lub scp) do konta docelowego, zaakceptuj klucz hosta i anuluj logowanie / scp. Powinieneś być w stanie skopiować.
Jeśli nie, spróbuj:
Jeśli masz klucz SSH z dostępem do serwera docelowego, a serwer źródłowy go nie ma, dodanie
-o "ForwardAgent=yes"
pozwoli Ci przesłać agenta SSH do serwera źródłowego, aby mógł użyć Twojego klucza SSH do połączenia z serwerem docelowym.źródło
Mała diagnoza: z tego
Podejrzewam (zgaduję), że działa w ten sposób, kopia serwer-serwer z
scp
logami doSERVER1
i wykonujescp
polecenie wysłania plikuSERVER2
; dlatego osoba dzwoniąca (zSERVER1
) musi się uwierzytelnić. Teraz to się nie udaje, ponieważ jest nieinteraktywne (nie ma/dev/tty
) i nie ma sposobu, aby poprosić o hasło.Oznacza to, że skopiowanie klucza do
SERVER1
(nie wiem, czy jest to możliwe w twojej sytuacji) może prawdopodobnie rozwiązać problem (myślę ...) ( Jeśli nie ma hasła ... co jest raczej złe )Edycja Rozwiązanie może wyglądać następująco: użyj,
sshfs
aby uzyskać dostęp do plików, które chcesz wysłać, wysłać jescp
zsshfs
katalogu -mounted. Powinno to zapewnić niezbędną interaktywność (jeśli powyższe przypuszczenie było słuszne) i zachować wszystkie klucze lokalne.źródło
ssh SERVER1 scp *args-YOU-specifiy*
dla nieco większej elastyczności. Może jakieśstdin
podstępy mogłyby pomóc ... Nie jestem pewien.ssh-agent
) brzmi o wiele lepiej niżstdin
oszustwo.Próbowałem tego i działa dla mnie między dwoma systemami, kilka różnic:
ssh-add
)Spróbuj wykonać następujące czynności:
źródło
możesz użyć
-3
opcji scp, która kieruje ruchem przez twój notebook.to znaczy
[USER@NOTEBOOK ~] scp -3 root@SERVER1:/PATH/TO/DIR root@SERVER2:/PATH/TO/DIR
źródło
Wypróbuj następujące opcje dla ssh:
W moim przypadku próbuję połączyć się z ssh z poziomu SP w postgreSQL. Pierwsza próba nie powiodła się:
Źródło problemu: nie można pisać w know_host
Następne wyjście połączenia:
sukces !!!
źródło