Не удается заставить работать аутентификацию с открытым ключом 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-клиент настаивает на этом, я опровергнут. (Обратите внимание на явное отсутствие строки «Предлагающий открытый ключ:» выше.) Есть предложения?

ssh

Убедитесь, что на вашем компьютере Centos есть:

RSAAuthentication yes
PubkeyAuthentication yes

в sshd_config

и убедитесь, что у вас есть соответствующие права доступа к каталогу ~ / .ssh / на машине centos.

chmod 700 ~/.ssh/
chmod 600 ~/.ssh/*

должен сделать свое дело.

У меня была аналогичная проблема - удаленный компьютер не мог использовать аутентификацию с открытым ключом для входа на сервер CentOs 6. Проблема в моем случае была связана с SELinux - в домашнем каталоге пользователя, пытающегося войти в систему, были сообщения о контекстах безопасности. Я решил это, используя restorecon инструмент таким образом:

restorecon -Rv /home

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

Дважды проверьте правильность ваших разрешений и правильность структуры файлов (в частности, орфографии) как для локальных, так и для удаленных машин. URL-адрес, на который вы ссылаетесь, указывает их все, но стоит проверить, соответствует ли то, что у вас есть. Однако обычно разрешения вызывают соответствующую ошибку.

Вы проверили, что sshd_config в вашем поле CentOS 5.3 настроен на разрешение PubkeyAuthentication или RSAAuthentication?

Проверьте журналы сервера SSH в системе CentOS - они могут предоставить дополнительную информацию. Я не уверен, выполняет ли CentOS проверку ssh-ключей из черного списка, как это делает debian, но я видел, что отклонения ssh publickey являются относительно тихими, что касается вывода -vvv, но журналы довольно четко объясняют, что происходит

Понял! Оказывается, это проблема на стороне клиента. (Я думаю, что любая проблема на стороне сервера дала бы более полезный результат отладки.) По неизвестным мне причинам на моем Mac в файле / etc / ssh_config была строка

PubkeyAuthentication = no

Я закомментировал эту строчку, и теперь все работает нормально.

Помимо режимов файлов / каталогов, убедитесь, что владелец правильный! У пользователя должен быть собственный домашний каталог .ssh / и файлы в нем.

Мне пришлось бежать chown -R $user:$user /home/$user чтобы справиться с моими сбоями ssh.

Также проверьте, может ли он автоматически предоставлять ключ или нет, используйте -i path / to / key, если нет, или просто для проверки

Для меня это проблема конфигурации. Как и предположил Дэниел, нужно проверить две вещи:

Ключи SSH в $HOME/.ssh/authorized_keys читаемы; и
SSHd настроен так, чтобы разрешить вход с открытым ключом.

Проверьте имя пользователя, с которым вы пытаетесь войти. По умолчанию это ваше имя пользователя на локальной машине.

Вывод клиента как в ssh -v покажет, что существует проблема на определенном этапе протокола, но когда она связана с чем-то на сервере, клиент не будет проинформирован о причине. Проверьте файлы журнала сервера, чтобы узнать, что случилось. Вам, вероятно, нужно быть root для того, чтобы иметь на это разрешение. Например, для sshd настроен для входа в системный журнал, вы можете найти сообщения в /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

Причиной в данном случае был (глупый) дефолт default из 0002. Это означает, что группе предоставляется право записи. (Groupname = username, но все же.) Демон SSH не будет доверять файлам, которые могут быть изменены кем-то другим, кроме пользователя (ну и root, конечно). Вы можете решить проблему, используя chmod.

chmod 700 ~/.ssh # solve the issue
chmod 720 ~/.ssh # reproduce the issue
# or similar for a file

Я просто попал в ловушку той же проблемы с доступом к Fedora Core 16 до 5,5 центов

журналы и подробное описание выглядели одинаково

проблема заключалась в открытом ключе, он получил какие-то поддельные данные, регенерировал их и разместил на sshd_server, вы sshd_client отправляет информацию о ключе, но не распознается сервером (он не соответствует ни одному из ключей в authorized_keys)

Другой укушен этим. После долгих поисков выяснилось, что я явно скармливаю ssh открытый ключ (с параметром -i) вместо закрытого ключа. Дох!