Не удается заставить работать аутентификацию с открытым ключом SSH [закрыто]
На моем сервере работает CentOS 5.3. Я использую Mac под управлением Leopard. Я не знаю, кто за это отвечает:
Я могу войти на свой сервер с помощью аутентификации по паролю. Я выполнил все шаги по настройке PKA (как описано на http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-ssh-beyondshell.html ), но когда я использую SSH, он отказывается даже пытаться проверить открытый ключ. Используя команду
ssh -vvv user@host
(где -vvv повышает уровень детализации до максимального), я получаю следующий соответствующий вывод:
debug2: key: /Users/me/.ssh/id_dsa (0x123456)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred keyboard-interactive,password
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
, за которым следует запрос моего пароля. Если я попытаюсь вызвать проблему с помощью
ssh -vvv -o PreferredAuthentications=publickey user@host
, я получу
debug2: key: /Users/me/.ssh/id_dsa (0x123456)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred publickey
debug3: authmethod_lookup publickey
debug3: No more authentication methods to try.
Итак, даже если сервер говорит, что принимает метод аутентификации с открытым ключом, и мой клиент SSH настаивает на этом, я опровергнут. (Обратите внимание на явное отсутствие строки «Предлагающий открытый ключ:» выше.) Есть предложения?
Двойная проверка, чтобы Ваши полномочия были корректной и файловой структурой (конкретно записывающий) корректна, и для локальных и для удаленных машин. URL, к которому Вы обращаетесь, указывает им всем, но стоит проверить это, что у Вас есть соответствия. Обычно полномочия бросят соответствующую ошибку все же.
Вы проверили, что sshd_config на Вашем поле CentOS 5.3 установлен разрешить PubkeyAuthentication или RSAAuthentication?
Проверьте, что сервер SSH входит в систему CentOS - это может предоставить больше информации. Я не уверен, делает ли CentOS помещенный в черный список ssh ключ, проверяющий, что debian делает, но я видел ssh отклонения с открытым ключом, которые относительно тихи насколько-vvv вывод идет, но журналы довольно ясно объяснили, что продолжалось
Получил его! Оказывается, что это была клиентская проблема. (Я думаю, что любая проблема серверной стороны привела бы к более полезному выводу отладки.) По причинам, неизвестным мне, на моем Mac, файл/etc/ssh_config имел строку
PubkeyAuthentication = no
Я прокомментировал ту одну строку, и теперь все хорошо работает.
Также проверьте, что это может автоматическое предоставление ключ или нет, использовать путь/к/ключ-i если не или только протестировать
1-проверяют Ваш/etc/ssh/sshd_config, гарантируют, чтобы Вы имели
RSAAuthentication yes PubkeyAuthentication yes
2-проверяют безопасный журнал от удаленной машины, поиск деталь sshd журнал ошибок демона. например, в моей Ubuntu
# grep 'sshd' /var/log/secure | grep 'Authentication refused' | tail -5 Aug 4 06:20:22 xxx sshd[16860]: Authentication refused: bad ownership or modes for directory /home/xxx Aug 4 06:20:22 xxx sshd[16860]: Authentication refused: bad ownership or modes for directory /home/xxx Aug 4 06:21:21 xxx sshd[17028]: Authentication refused: bad ownership or modes for directory /home/xxx Aug 4 06:21:21 xxx sshd[17028]: Authentication refused: bad ownership or modes for directory /home/xxx Aug 4 06:27:39 xxx sshd[20362]: Authentication refused: bad ownership or modes for directory /home/xxx
Затем проверьте владение и режимы для каталога,/home/xxx, возможно, Вы должны выполнить это
chmod 755 /home/xxx
У меня была аналогичная проблема - удаленный компьютер не мог использовать аутентификацию с открытым ключом для входа на сервер CentOs 6. Проблема в моем случае была связана с SELinux - в домашнем каталоге пользователя, пытающегося войти в систему, были сообщения о контекстах безопасности. Я решил эту проблему с помощью инструмента restorecon таким образом:
restorecon -Rv /home
Вывод клиента, как в ssh -v , покажет, что существует проблема на определенном этапе в протоколе, но когда это связано с чем-то на сервере клиент не будет проинформирован о причине. Проверьте файлы журнала сервера, чтобы узнать, что случилось. Скорее всего, вам понадобится root , чтобы иметь на это разрешения. Например, для sshd , настроенного для ведения журнала в syslog, вы можете найти сообщения в / var / log / secure . Как эти:
Authentication refused: bad ownership or modes for directory /home/you/.ssh
Authentication refused: bad ownership or modes for file /home/you/.ssh/authorized_keys
Причина в этом случае была (глупая) по умолчанию по умолчанию из 0002 . Это означает, что группе предоставляется право записи. (Groupname = username, но все же.) Демон SSH не будет доверять файлам, которые могут быть изменены кем-то другим, кроме пользователя (ну и root , конечно). Вы можете решить эту проблему с помощью chmod .
chmod 700 ~/.ssh # solve the issue
chmod 720 ~/.ssh # reproduce the issue
# or similar for a file
Я только что столкнулся с той же проблемой при доступе с ядром Fedora от 16 до 5,5 центов
журналы и подробные данные выглядели точно так же
проблема была с открытым ключом, он получил некоторые поддельные данные, регенерируйте их и отправьте на sshd_server, вы sshd_client отправляет ключевую информацию, но не распознает сервер (он не соответствует ни одному из ключей в authorized_keys)
Check username with wich you are trying to log in. By default it's your username on local machine.
Помимо режимов файлов / каталогов, убедитесь, что право собственности указано правильно! Пользователь должен владеть своим собственным домашним каталогом .ssh / и файлами в нем.
Мне пришлось запустить chown -R $ user: $ user / home / $ user , чтобы справиться с моими сбоями ssh.
Еще один укушенный этим. После долгих поисков выяснилось, что я явно скармливаю ssh открытый ключ (с параметром -i) вместо закрытого ключа. Дох!