Здрасти

Знам, че съществуват различни конци за SFTP от тук, но никой не изглежда да се отговори на въпроса ми.

Аз поставих passwordless SFTP между използват публични и частни ключове. Успях да работят ОК между 2 Windows сървъри и при изпращането на файлове от Windows Server (клиент) на Unix сървър. Въпреки това, когато се опитвам то между 2 Unix сървърите го пази ме питат за passord за сървъра (той също да прави това, когато аз trysending от Unix (клиент) за Windows Server. То изглежда, че нещо общо с Unix страна като клиентът се опитва да се свърже ...... Някой да има някакви идеи .......??

Наздравици

П. С. .. Тя създава known_hosts файл ОК на клиента. SSH директорията, но спокойно пита за парола .. също ..... му Solaris ..

Здрасти

Знам, че съществуват различни конци за SFTP от тук, но никой не изглежда да се отговори на въпроса ми.

Аз поставих passwordless SFTP между използват публични и частни ключове. Успях да работят ОК между 2 Windows сървъри и при изпращането на файлове от Windows Server (клиент) на Unix сървър. Въпреки това, когато се опитвам то между 2 Unix сървърите го пази ме питат за passord за сървъра (той също да прави това, когато аз trysending от Unix (клиент) за Windows Server. То изглежда, че нещо общо с Unix страна като клиентът се опитва да се свърже ...... Някой да има някакви идеи .......??

Наздравици

При инсталиране на публичния ключ на сървъра да ServerB, можете да се свържете от сървъра към ServerB. За да се свържете от ServerB на сървъра, ще трябва да инсталирате на публичния ключ на ServerB до сървъра.

Изпрати ми продукцията на SFTP с "-V" опция.

Благодаря за отговора.

Аз просто се опита witha нова двойка ключове. Ключове, генерирани от сървъра, на публичния ключ е на serverB и Im опитва да се свърже от сървъра (Solaris) за ServerB (Windows). Пак ли да го питам за парола. Следва цялата продукция от "SFTP-V":

$ SFTP-V tibco @ ukhlsnomis1
Свързване с ukhlsnomis1 ...
Sun_SSH_1.1, SSH протоколи 1.5/2.0, OpenSSL 0x0090704f
debug1: Четене конфигурация данни / и т.н. / SSH / ssh_config
debug1: Rhosts Удостоверяване с увреждания, с произход пристанище, няма да се има доверие.
debug1: ssh_connect: needpriv 0
debug1: Свързване с ukhlsnomis1 [10.96.130.6] порт 22.
debug1: Връзка установена.
debug1: идентичност файл / u01/app/tibco/.ssh/id_rsa тип 1
debug1: идентичност файл / u01/app/tibco/.ssh/id_dsa тип -1
debug1: Дистанционен протокол версия 2.0, отдалечен софтуер версия OpenSSH_3.8.1p1
debug1: съвпадение: OpenSSH_3.8.1p1 потупване OpenSSH_3.6 *, OpenSSH_3.7 *, OpenSSH_3.8 *
debug1: Разрешаването на режим на съвместимост за протокола 2,0
debug1: Локално версия стринг SSH-2,0-Sun_SSH_1.1
debug1: Неуспех при придобиване GSS-API пълномощията за всякакви механизми (№ пълномощия са били предоставени или пълномощията бяха недостъпни или недостъпен
Неизвестен код 0
)
debug1: SSH2_MSG_KEXINIT изпратено
debug1: SSH2_MSG_KEXINIT получили
debug1: kex: Server-> клиент aes128-CTR hmac-MD5 никой
debug1: kex: клиент-> Server aes128-CTR hmac-MD5 никой
debug1: Пеер прати предложените langtags, ctos:
debug1: Пеер прати предложените langtags, stoc:
debug1: Ние, предложен langtags, ctos: EN-GB
debug1: Ние, предложен langtags, stoc: EN-GB
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST изпратено
debug1: Очакваме SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv ключови бита включен: 138/256
debug1: битов набор: 1039/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT изпратено
debug1: Очакваме SSH2_MSG_KEX_DH_GEX_REPLY
Автентичността на хост "ukhlsnomis1 (10.96.130.6)" не могат да бъдат установени.
RSA ключ дактилоскопичните е дд: 1E: 09: d2: B0: A8: 31:39: BB: 60: AE: 40: B3: F3: EC: 7е.
Сигурни ли сте, че искате да продължите, свързващ (да / не)? да
Предупреждение: Постоянно добавя "ukhlsnomis1, 10.96.130.6" (ЮАР) в списъка на известните Силите.
debug1: битов набор: 1010/2048
debug1: ssh_rsa_verify: подпис правилните
debug1: newkeys: Режим 1
debug1: SSH2_MSG_NEWKEYS изпратено
debug1: Очакваме SSH2_MSG_NEWKEYS
debug1: newkeys: Режим 0
debug1: SSH2_MSG_NEWKEYS получили
debug1: направено: ssh_kex2.
debug1: изпрати SSH2_MSG_SERVICE_REQUEST
debug1: Трябва SSH2_MSG_SERVICE_ACCEPT

**** USAGE ПРЕДУПРЕЖДЕНИЯ ****

Това е частна компютърна система. Тази компютърна система, включваща всички
свързаното с тях оборудване, мрежи и мрежови устройства (включително и специално
Интернет достъп) са предоставени само за оторизиран употреба. Тази компютърна система
могат да бъдат проследявани за всички законни цели, включително и за да се гарантира, че неговото използване
е разрешено, за управление на системата, за да се улесни защитата срещу
неоторизиран достъп, както и да провери процедури за сигурност, оцеляване, и
оперативна сигурност. Мониторинг включва активно атаки от упълномощени лица
за изпитване или проверка на сигурността на тази система. По време на мониторинга, информация
могат да бъдат разгледани, записани, копирани и използвани за разрешени цели. Всички
информация, включително и лична информация, пуснати или изпратени през тази система
могат да бъдат наблюдавани.

Използването на тази компютърна система, разрешено или неразрешено, представлява съгласие
за наблюдение на тази система. Неупълномощен употреба, могат да подлежат на наказателно
преследване. Доказателство за непозволено използване, събрани по време на наблюдението може да бъде
, използван за административни, наказателни, или други нежелани действия. Използването на тази система
съставлява съгласие за мониторинг на тези цели.


debug1: Authentications, които могат да продължат: publickey, парола, клавиатура-интерактивни
debug1: Следващата удостоверяване метод: publickey
debug1: Опитвам публичния ключ: / u01/app/tibco/.ssh/id_rsa
debug1: Authentications, които могат да продължат: publickey, парола, клавиатура-интерактивни
debug1: Опитвам частен ключ: / u01/app/tibco/.ssh/id_dsa
debug1: Следващата удостоверяване метод: клавиатура-интерактивни
debug1: Authentications, които могат да продължат: publickey, парола, клавиатура-интерактивни
debug1: Следващата удостоверяване метод: Парола
tibco @ ukhlsnomis1 паролата:
debug1: Удостоверяване успя (парола)
debug1: FD 6 настройка O_NONBLOCK
debug1: канал 0: нова [клиента сесия]
debug1: изпрати канали отворени 0
debug1: Въвеждане на интерактивна сесия.
debug1: ssh_session2_setup: ID 0
debug1: канал искане 0: ENV
debug1: канал искане 0: ENV
debug1: канал искане 0: ENV
debug1: канал искане 0: ENV
debug1: канал искане 0: ENV
debug1: Връщане подсистема: SFTP
debug1: канал искане 0: подсистема
debug1: канал 0: открит потвърди rwindow 0 rmax 32768
SFTP> чао
debug1: канал 0: прочети <\u003d 0 rfd 6 Лен 0
debug1: канал 0: прочети провали
debug1: канал 0: close_read
debug1: канал 0: въвеждане на открито -> изтичане
debug1: канал 0: ibuf празна
debug1: канал 0: изпрати eof
debug1: канал 0: вход източването -> затворена
debug1: client_input_channel_req: канал 0 rtype излизане статут отговор 0
debug1: канал 0: rcvd eof
debug1: канал 0: изхода отворен -> изтичане
debug1: канал 0: obuf празна
debug1: канал 0: close_write
debug1: канал 0: изход източването -> затворена
debug1: канал 0: rcvd тясно
debug1: канал 0: почти мъртъв
debug1: канал 0: GC: уведомява потребителя
debug1: канал 0: GC: потребител откъснат
debug1: канал 0: изпрати близо
debug1: канал 0: е мъртъв
debug1: канал 0: събиране на боклук
debug1: channel_free: канал 0: клиент-сесия, nchannels 1
debug1: FD 0 клиринг O_NONBLOCK
debug1: Прехвърлени: stdin 0, stdout 0, stderr 0 байта в 5,2 секунди
debug1: Bytes в секунда: stdin 0,0, stdout 0,0, stderr 0,0
debug1: Изход статут 0
$


Наздравици

Може би не е инсталиран на публичния ключ правилно.
Проверка на следния линк да разберем по-добре

Имах подобен проблем днес, но аз се опитвах да направя по-малко парола SSH връзки между две Unix сървъри.

Проблемът беше, че беше мой. SSH папка. Той не е имал право разрешения. След chmod 700 /. SSH / всичко работи правилно.

Аз не знам дали Windows може да има подобен проблем.

Това е вярно. Само потребителят трябва да имат разрешение за писане ". SSH" директория.