Не удается подключиться через SSH и publickey и пользователя B (пользователь A может)

Question

Решаемые. Это был бит для записи группы в домашнем каталоге user_B , который обманул меня.

У меня заканчиваются идеи по этому вопросу. Каждый намек будет высоко оценен.

Рассмотрим эту настройку:

• Сервер S управлением Ubuntu, пользователи boldewyn , user_A и user_B
• Два ноутбука A и B , каждый с локальным пользователем boldewyn (имеет ключ id_rsa для входа в S) и второй ключ id_rsa_A / id_rsa_B . Все ключи хранятся в /home/boldewyn/.ssh . Оба работают на Ubuntu.

• user_A и user_B на S имеют пустые пароли, вход в систему возможен только через publickey и SSH.

  +--------+            +-------------------+            +--------+
  | laptop |            |       server      |            | laptop |
  |   A    |            |         S         |            |   B    |
  |        |            |                   |            |        |
  +--------+    SSH     +-------------------+    SSH     +--------+
  |id_rsa_A|------------|< user_A   user_B >|------------|id_rsa_B|
  +--------+            +-------------------+            +--------+
  |id_rsa  |------------|<    boldewyn     >|------------|id_rsa  |
  +--------+            +-------------------+            +--------+
  

Что работает:

• Войдите с любого ноутбука как boldewyn (используя id_rsa и S:/home/boldewyn/.ssh/authorized_keys

• Войдите с ноутбука A как пользователь user_A (используя id_rsa_A и S:/home/user_A/.ssh/authorized_keys: ssh -i id_rsa_A user_A@S)

Моя проблема: на ноутбуке B точно такая же настройка не выполняется для user_B . Я не могу войти на S , потому что по какой-то причине ключ не принят, и появляется запрос пароля (user_B не имеет пароля, это не вариант).

Что я проверил:

• На ноутбуке B:

  • Проверил права ~/.ssh и весь его контент
  • поместить открытую часть id_rsa_B в boldewyn s .authorized_keys и ssh -i id_rsa_B boldewyn@S: работает (ключ не поврежден или около того)
  • ssh -vvv: Ну, не очень полезно: просто скажу мне, что сейчас пропускает метод publickey . Причина не указана.

• На сервере S:

  • Тройно проверенный файл user_B s .authorized_keys
  • Проверил права на /home/*/.ssh и все их содержимое (особенно сравнил user_A и user_B)
  • Проверено, что $HOME установлен (через sudo -u user_B -i)
  • Проверено, что все пользователи находятся в /etc/ssh/sshd_config s AllowUsers (и, кстати , AllowGroups)

Другие вещи:

Единственное различие, которое я могу придумать между user_A и user_B заключается в том, что я создал последний с adduser -M (не создавайте домашний каталог; он уже существовал ранее). Однако я трижды проверил, что /home/user_B и все соответствующие дочерние элементы принадлежат user_B и его основной группе.

Answer 1

Тройно ли вы проверили, что /home/user_B (а также /home/user_B/.ssh и /home/user_B/.ssh/authorized_keys) имеют надлежащие разрешения: недоступно для записи, кроме пользователя, то есть в режиме 755 или более ограничительный?

Answer 2

Я думаю, это может быть связано с тем, как вы генерировали эти ключи. Я бы попробовал еще раз. Ключи генерируются с помощью средства ssh-keygen. Возможно, когда был сгенерирован один набор ключей, в процессе генерации использовалась ключевая фраза. Вы можете попробовать нажать клавишу ввода, когда вас попросят ввести фразу-пароль. Скопируйте часть ключа этого паба в Ubuntu. Убедитесь, что вы удалили ошибочную запись в файле .ssh/authorized_keys. Вторая мысль: если cat cat file pub, убедитесь, что вы используете >> (добавление), а не> (replace_, когда копируете файл pub в файл authorized_keys. (Cat id_rsa.pub >> .ssh/authorized_keys).

Я немного удивлен. Я использовал свои методы на работе, используя Solaris и Cygwin, а дома на своем Linux Lan, состоящем из Centos, Slackware, Debian и Ubuntu. Возможно ли, что ваш закрытый ключ не совпадает с открытым? Когда вы генерируете свои ключи, вы получаете пару, публичная копия будет традиционно скопирована в файл .ssh/ авторизованных ключей в домашнем каталоге целевой машины. Если вы заново сгенерируете ключи, новый .pub файл должен быть скопирован. Новый закрытый ключ не будет сочетаться со старым открытым. Я заметил, что у вас, похоже, есть папка .authorized_keys в домашнем каталоге. Я никогда не пробовал это. Я думаю, что нормальное размещение находится в папке /home/user_name/.ssh/authorized_keys. У меня никогда не было проблем с использованием какой-либо версии Solaris от 6 и выше, Freebsd и различных версий и разновидностей Linux. Удачи

Алан