forum.lissyara.su

день добрый уважаемые
описываю ситуацию:
имеется порядка десятка серверов bsd и centos, решил сделать централизованое бекапирование с передачей данных поверх ssh,
написал скриптов, кторые по ssh-же раскладывают задачи бекапирования по серверам с центрального сервера куда все должно сливатся
сгенерил ключи для авторизации, прописал в authorized_keys публичную часть, приватный в /root/.ssh/id_rsa на серверах, оттестировал на паре bsd и centos, все замечательно работает, начал распростронять на остальные сервера
все нормально заработало еще на паре серверов, и напоролся на один centos овский, который отказывается авторизироватся по rsa.
как и везде выполняется типовой скрипты вида
tar -cz -f - /etc | ssh -i /root/.ssh/id_rsa backup@nas.corp "dd of=/mnt/backup1/servers/server.corp/2012-10-31/_etc.tar.gz
просит пароль, ладно думаю попробую руками интерактивно из под рута
ssh -i /root/.ssh/id_rsa backup@nas.corp
опять просит пароль, файл с ключем правильный - точно такой-же на 7 других серверах в том числе других центосах работает
ну, наверно не нравится ключ - генерирую новый ключ ssh-keygen -ом, в отдельные файлы, получаю 2 с приватным и публичным ключами паб пишу в конец authorized_keys на nas.corp
подключаюсь
ssh -i /root/.ssh/id_rsa1 backup@nas.corp
опять пароль просит
для пробы генерирую dsa ключ ssh-keygen -t dsa
паблик опять пишу в authorized_keys
ssh -i /root/.ssh/id_dsa1
все работает, чудеса, сравниваю на работающеи и не работаеющем центосах файлы ssh_config и на всякий sshd_config в /etc/ssh - одинаоково дефолтовые
может кто сталкивался с подобныйм в интернете нашел только http://snippets.pp.ru/blog/sysadmin/110.html
перейти на dsa вариант но совсем запасной, да и нет гарантии что на следующем сервере не окажется обратная ситуация
делать на части серверов rsa на части dsa не вариант совсем т.к. строка бекапа вида
tar -cz -f - /etc | ssh -i /root/.ssh/id_rsa backup@nas.corp "dd of=/mnt/backup1/servers/server.corp/2012-10-31/_etc.tar.gz
генерируется скриптом и рассылается с центрального сервера по крону, и делать разделение на rsa\dsa неудобно совсем
муже есть у кого идеи почему на центосе может не работать rsa, но при этом работать dsa
вот логи выполнения (паравда не из под рута), но суть такая-ж

ssh -v -i /home/nick/.ssh/id_rsa backup@nas.corp
.....
debug1: Found key in /home/nick/.ssh/known_hosts:1
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,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/nick/.ssh/id_rsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Password:
ощющения что приват кей не пытается даже использоватся

для сравнения
ssh -v -i /home/nick/.ssh/id_dsa backup@nas.corp
debug1: Found key in /home/nick/.ssh/known_hosts:1
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,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/nick/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = ru_RU.UTF-8
Last login: Wed Oct 31 09:03:50 2012 from lb.itnet
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.

FreeBSD 8.3-RELEASE (GENERIC) #0: Mon Apr 9 21:23:18 UTC 2012

Welcome to FreeBSD!
......
права на фалы ключей dsa и rsa одинаковые, сгенерированы одинаково разица только в указании типа
[nick@srv .ssh]$ ls -la
итого 28
drwx------ 2 nick nick 4096 Окт 31 09:07 .
drwx------ 4 nick nick 4096 Окт 31 09:00 ..
-rw------- 1 nick nick 668 Окт 31 09:01 id_dsa
-rw-r--r-- 1 nick nick 608 Окт 31 09:01 id_dsa.pub
-rw------- 1 nick nick 1675 Окт 31 08:59 id_rsa
-rw-r--r-- 1 nick nick 400 Окт 31 08:59 id_rsa.pub
-rw-r--r-- 1 nick nick 406 Окт 31 09:00 known_hosts

ну может хоть какие идеи есть?

так а чего сервер говорит?
Это ведь он не принял ключ, значит его логи и надо смотреть.

концовки логов привел выше, все что выше отписывает то от куда и куда подключаюсь и т.д
начало у логов вобщем одинаковое
на самом деле эксперементально выяснил, что сервер принимает ключи сгенеренные только на нем самом
это как-бы решение, но половинчатое
на остальных=то серверах установлен и принимается один и тот-же ключ
сыр бор был из-за того что идея - централизовано приписывать ключи, не заходя на сервера коих не мало, а генерить на каждом индивидуально не очень удобно, но придется так и поступить
так что вот так

А версия SSH какая на этом сервере? И какие на остальных?

день добрый
версии на рабочих и не рабочих серверах были одинаковые - это проверили первым делом вместе с конфиг-файлами sshd-ssh
версия OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
вобщем задача решена:
написан скрипт который с помощью exept -а смотрит на удаленном сервере наличие публичного-приватного ключей, если их нет генерит, и забирает публичный ключ на бекап сервер и конкатирует в authorized_keys, може так и лучьше т.к. везде свои ключи
тему можно закрывать, но блин осадочек от линуха остался...

скрипт с помощью expect-а а не exepta