Не удается заставить работать аутентификацию с открытым ключом SSH [закрыто]

41

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


источник
просто используйте «ssh -v», вам не нужно больше многословия и
включите
Этот вопрос закрыт, потому что он больше не отвечает, и привлекает низкокачественные ответы.
HopelessN00b

Ответы:

44

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

RSAAuthentication yes
PubkeyAuthentication yes

в sshd_config

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

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

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

Пайхимис
источник
1
правильные права и имена файлов (иногда author_keys2, иногда без 2) очень важны!
brandstaetter
4
Разрешение файла authorized_keys является очень важной подсказкой. Спасибо.
Кейн
7
Вам также может понадобиться, chmod go-w ~/если это не так.
Tylerl
1
Также проверьте, есть ли у вашего домашнего каталога на удаленном сервере разрешения 755(как упоминает Jinyu Liu ниже)
Attila Fulop
1
В других операционных системах файл конфигурации SSH также может находиться под:/etc/ssh/ssh_config
Yoshua Wuyts
17

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

restorecon -Rv /home
Gareth
источник
2
Спасибо, Гарет! "restorecon -Rv /root/.ssh" хорошо справился с задачей.
tbroberg
Чтобы пояснить далее: эта команда говорит SELinux сбросить теги SELinux для файлов в соответствии /homeс тем, для чего они обычно находятся в макете каталога /home.
Ракслице
Если вы restorecon -Rv /root
вошли
13

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
Джинью Лю
источник
1
Проверьте лог-файл системы - очень важный совет.
Кейн
1
Пермь домашнего каталога 755 помог мне - определенно требуется!
Бен
11

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

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

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

Дэниел Лоусон
источник
7

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

PubkeyAuthentication = no

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


источник
4

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

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

Виссер
источник
+1, на одной из моих систем права на .ssh были правильными, но кто-то сделал домашний каталог учетной записи 777.
GargantuChet
2

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

Jimsmithkka
источник
2

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

  1. Ключи SSH $HOME/.ssh/authorized_keysдоступны для чтения; а также
  2. SSHd настроен для разрешения входа с открытым ключом.
sybreon
источник
2

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

Creotiv
источник
1

Вывод клиента, как в 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
Lumi
источник
1

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

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

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

Freaktor
источник
-2

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

Эллерт ван Коперен
источник