Сервер продолжает запрашивать пароль после того, как я скопировал мой открытый ключ SSH в authorized_keys

На стороне сервера демон ssh будет регистрировать ошибки в /var/log/auth.log, поэтому проверьте этот файл, чтобы увидеть, о чем сообщается.

Со стороны клиента при установлении соединения вы можете добавить флаг -v (или -vv или -vvv), чтобы увеличить детализацию. Возможно, вы сможете определить свою проблему таким образом.

Вот другие вещи, которые нужно проверить.

• Убедитесь, что /home/git/.ssh/authorized_keys принадлежит git.
• Убедитесь, что /home/git/.ssh/authorized_keys имеет режим 600 (-rw-------).

Также проверьте файл /etc/ssh/sshd_config.

• PubkeyAuthentication следует установить на yes
• Существует также директива AuthorizedKeysFile, которая определяет путь, где должны находиться авторизованные ключи. Убедитесь, что он закомментирован или по умолчанию %h/.ssh/authorized_keys.

Также убедитесь, что ваш домашний каталог пользователя (в вашем случае / home / git) доступен только для вас. У меня была эта проблема однажды, потому что мой домашний каталог был доступен для записи в группе. В /var/log/auth.log сказано: «Отказ в аутентификации: неправильное владение или режимы для каталога / home / chuck». (это сделано для того, чтобы убедиться, что он не использует файл author_keys, с которым кто-то кроме вас возился!)

Вы используете ~ / .ssh / config на своем локальном компьютере? Я столкнулся с этой проблемой, когда использую директиву IdentityFile в файле конфигурации и указываю на открытый ключ. Например:

Host Cloud
    Hostname cloud.theclouds.com
    User git
    IdentityFile ~/.ssh/config/mykey # This is correct

    # IdentityFile ~/.ssh/config/mykey.pub # This is incorrect

Еще одна вещь, которую нужно проверить, это наличие в вашем открытом ключе дополнительных возвратов каретки. Я следовал совету выше, чтобы просмотреть /var/log/auth.log и увидел ошибку при чтении ключа. Ключ был длиной около двух строк вместо четырех. В ключ были вложены дополнительные возвраты каретки.

При использовании редактора vi используйте shift-j, чтобы соединить строки и стереть лишний пробел в строке ключа.

Если у вас есть несколько закрытых ключей, используйте ключ -v в команде ssh-соединения, чтобы проверить, используются ли другие первичные ключи для подключения. Если это не так, скажите клиенту ssh использовать их со следующей командой:

ssh-add path/to/private/key

На машине под управлением Ubuntu 18.04.02 LTS предложение установить разрешения от ~/.ssh до 600 у меня не сработало. Я должен был установить разрешения на 700, а затем все работало нормально.

Существуют различные способы решения этой проблемы: вы можете настроить sshd (на стороне сервера) или ssh (на стороне клиента), чтобы не использовать аутентификацию по паролю. Отключение аутентификации по паролю на сервере делает ваш сервер более безопасным, но у вас будут проблемы, если вы потеряете свой ключ.

Чтобы сделать ssh (на стороне клиента) с использованием аутентификации pubkey, добавьте некоторые опции в команду ssh:

ssh -o PubkeyAuthentication=yes -o PasswordAuthentication=no -X git@server

Если это работает, вы можете установить опцию PasswordAuthentication=no на постоянной основе в файл конфигурации клиента ssh /etc/ssh/ssh_config для всей системы или ~/.ssh/config для конкретного пользователя (подробнее см. man ssh_config).

Если ваша домашняя папка зашифрована, то ваш authorized_keys файл не читается до входа в систему. Вы должны переместить его за пределы своего дома.

Здесь объясняется и как это сделать: https://help.ubuntu.com/community/SSH/OpenSSH/Keys#Trou устранение неполадок

Вы также можете добавить свой ключ к агенту SSH:

u@pc:~$ ssh-agent bash
u@pc:~$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/u/.ssh/id_rsa: # ENTER YOUR PASSWORD
Identity added: /home/u/.ssh/id_rsa (/home/u/.ssh/id_rsa)

Также может быть, что вы звоните

sudo git clone gituser@domain:repo.git

, где ключ ssh пользователя root не был добавлен в authorized_keys из gituser

Я имел свой .ssh/каталог и authorized_keys корректные полномочия файла, но встретился, эта "подсказка для пароля" выходят из-за другой, самовызванной проблемы.

я использовал основанное на мыши выделение и скопировать/вставить скопировать информацию с моего локального id_rsa.pub в authorized_keys файл на сервере. Это успешно скопировало данные в как одна строка, но там где нежелательные пробелы в конце видимых строк, которые было трудно видеть при редактировании файла с vi. После того как я удалил эти нежелательные пробелы, в которых я мог ssh очень хорошо.

Таким образом, то, что произошло для меня, - то, что у меня есть 2 VMs к доступу от моей локальной машины (2 ключа id_rsa.pub и id_rsa2.pub). Я понял, что мое соединение SSH использует id_rsa.pub по умолчанию для любого ssh соединения user@xx.xx.xx.xx. Я решил свою проблему путем добавления файла конфигурации, и укажите идентификационные данные, которые будут использоваться для каждого хоста как следующее:

vi ~/.ssh/config

Add both hostnames and their identity file as follows:

Host server1.nixcraft.com
  IdentityFile ~/Users/.ssh/id_rsa1
Host server2.nixcraft.com
  IdentityFile /backup/home/aymen/.ssh/id_rsa2

Я мог видеть следующее сообщение журнала из /var/log/auth.log на удаленном сервере: userauth_pubkey: тип ключа ssh-rsa отсутствует в PubkeyAcceptedKeyTypes

Это говорит о том, что ключ типа ssh-rsa в моей локальной системе не принимается сервером. Поэтому изменили конфигурацию сервера, изменив и добавив значение ssh-rsa к атрибуту / свойству PubkeyAcceptedKeyTypes в файле / etc / ssh / sshd_config на моем сервере и перезапустив демон sshd

. Это решило проблему

TL; DR

На стороне клиента:

• откройте файл конфигурации / etc / ssh / ssh_config ;
• здесь найдите PreferredAuthentication ;
• make обязательно пароль идет после публичного ключа , а не наоборот

В моем случае пароль был написан до публичного ключа , поэтому ssh предложит мне ввести пароль, даже если я скопировал свой pub_key на сервер.

Эту проблему легко решить, используя подробное описание:

ssh -v compute @ compute1 ... ... debug1: аутентификация, которая может продолжаться: открытый ключ, пароль debug1: Следующий метод аутентификации: пароль

Как видите, пароль выбирается перед попыткой использования открытого ключа.

Отредактируйте / etc / ssh / ssh_config , переместив пароль после publickey

PreferredAuthentication интерактивная клавиатура, открытый ключ, пароль , на основе хоста, gssapi-with-mi

Теперь я могу войти в систему без запроса pwd.