it-swarm-ru.tech

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

(где -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 [email protected]

Я получил

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

41
Trey Parkman

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

RSAAuthentication yes
PubkeyAuthentication yes

в sshd_config

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

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

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

44
pyhimys

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

restorecon -Rv /home
17
Gareth

1- проверьте ваш/etc/ssh/sshd_config, убедитесь, что у вас есть

 RSAAuthentication да 
 PubkeyAuthentication да 

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

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

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

 chmod 755 /home/xxx
13
Jinyu Liu

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

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

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

11
Daniel Lawson

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

PubkeyAuthentication = no

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

7
Trey Parkman

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

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

4
Visser

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

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

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

2
Creotiv

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

2
Jimsmithkka

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

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

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

1
Freaktor

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

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