Не удается заставить работать аутентификацию с открытым ключом 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.

Таким образом, хотя сервер говорит, что он принимает метод аутентификации publickey, и мой 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, убедитесь, что у вас есть

RSAАутентификация да
PubkeyAuthentication да

2 - проверьте безопасный журнал с удаленной машины, посмотрите подробный журнал ошибок демона sshd. например, в моей Ubuntu

# grep 'sshd' / var / log / secure | grep «В аутентификации отказано» | хвост -5
4 августа 06:20:22 xxx sshd [16860]: в аутентификации отказано: неправильное владение или режимы для каталога / home / xxx
4 августа 06:20:22 xxx sshd [16860]: в аутентификации отказано: неправильное владение или режимы для каталога / home / xxx
4 августа 06:21:21 xxx sshd [17028]: Отказ в аутентификации: неправильное владение или режимы для каталога / home / xxx
4 августа 06:21:21 xxx sshd [17028]: Отказ в аутентификации: неправильное владение или режимы для каталога / home / xxx
4 августа 06:27:39 xxx sshd [20362]: в аутентификации отказано: неправильное владение или режимы для каталога / home / xxx

Затем проверьте владельца и режимы для каталога / home / xxx, возможно, вам нужно запустить этот

chmod 755 / home / xxx

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

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

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

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

PubkeyAuthentication = no

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

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

Я должен был бежать, chown -R $user:$user /home/$userчтобы преодолеть мои ошибки SSH.

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

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

1. Ключи SSH $HOME/.ssh/authorized_keysдоступны для чтения; а также
2. 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 отправляет информацию о ключе, но не распознается сервером (он не совпадает ни с одним из ключей в author_keys)

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