Рассмотрим следующий сценарий: администратор настроил пару открытого и закрытого ключей для использования при синхронизации файлов между серверами, чтобы избежать запроса пароля. Эта установка отлично работает.
Затем при попытке использовать SSH / SCP система запрашивает пароль.
Вопрос: почему это так, если rsync работает правильно?
Как вы настроили сервер, чтобы разрешить ваш ключ? Поместив свой открытый ключ в .ssh / authorized_keys на сервере? Если это так, он должен работать. Используете ли вы те же имена пользователей (как удаленные, так и локальные) при использовании ssh / scp, что и при использовании rsync?
Да, кстати, я думаю, этот вопрос следует задать на serverfault.com.
Большое спасибо, мне удалось решить проблему с помощью элемента конфигурации
~ / .ssh / config PasswordAuthentication нет
и установка разрешений 700 для каталога .ssh и 600 authorized_keys.
Этот пост был очень полезным
большое спасибо.
Еще одна полезная вещь - запустить сервер в режиме отладки на другом порту. Иногда серверная сторона будет жаловаться, а клиент на самом деле не дает вам понять, почему.
На стороне сервера: /usr/sbin/sshd -Dedd -p 2222
Сторона клиента: ssh -vv -p 2222 server
См. Раздел справочной страницы ssh по аутентификации. Некоторые возможности:
Создавая ключи, вы убедитесь, что вошли в систему как тот же пользователь, с которым создавали ключи. Также убедитесь, что вы правильно импортировали ключи в авторизованные ключи.
На сервере проверьте соответствующий файл журнала, чтобы увидеть, есть ли там какие-либо сообщения. Самая распространенная причина отказа сервера использовать в противном случае правильно настроенные ключи - это ошибки разрешений (ваш домашний каталог, ~/.ssh/ и ~/.ssh/authorized_keys должны иметь достаточно безопасные разрешения, иначе сервер не будет доверять содержимому ~/.ssh/authorized_keys так как они могли быть изменены другим пользователем). Если аутентификация на основе ключа была отклонена по этой причине, она будет зарегистрирована (как и по ряду других причин). Обычно это в /var/log/auth.log (по крайней мере, в Debian и аналогичных системах с конфигурацией SSHD по умолчанию место входа может отличаться).
Еще одна вещь, которую нужно попробовать, чтобы получить больше информации, - это повысить многословность клиента SSH. Если вы используете OpenSSH из командной строки, добавьте -v для более подробного вывода при подключении, и -v снова (или просто -vv так как варианты могут быть сгруппированы таким образом), чтобы он был еще болтливее.
Проверьте журналы аутентификации (возможно, один из / var / log / secure или /var/log/auth.log) на сервере - они обычно немного более подробны, чем клиент (даже если вы добавляете -vvv в ssh команда).
Самая распространенная вещь, которую я видел, - это разрешения на файлы, на которые ссылается SSH из-за StrictModes включен ..
Я бы рекомендовал добавить это в ~ / .ssh / config чтобы никогда не запрашивали пароль. Это не заставит клавиши работать волшебным образом, но сделает скрипт, который дает сбой, немного быстрее и понятнее.
PasswordAuthentication no
Вы уверены, что он не запрашивает парольную фразу для расшифровки ключа, а не имя пользователя и пароль для входа на сервер?
Мы обсуждали это в «Перевод rsync в неинтерактивный режим». Там вы можете прочитать о многих возможных решениях, но вкратце:
rsync -e 'ssh -o "NumberOfPasswordPrompts 0"' source user@target:/path
(Спасибо, гусс!) Что не требует изменения конфигурации, которое могло бы повлиять на некоторые другие варианты использования rsync или ssh на сервере.
Уди