Почему я все еще получаю подсказку пароля с ssh с аутентификацией с открытым ключом?

Я работаю от URL, который я нашел здесь:

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

Моим ssh клиентом является Ubuntu 64 бита, 11,10 рабочих столов и мой сервер являются Centos 6.2 64 бита. Я следовал за направлениями. Я все еще получаю подсказку пароля на ssh.

Я не уверен, что сделать затем.

493
12.01.2017, 19:17
12 ответов

Удостоверьтесь полномочия на ~/.ssh каталог и его содержание являются надлежащими. Когда я сначала настроил своего ssh ключевого автора, я не имел ~/.ssh папка правильно настроила, и она вопила на меня.

  • Ваш корневой каталог ~, Ваш ~/.ssh каталог и ~/.ssh/authorized_keys файл на удаленной машине должен быть перезаписываем только Вами: rwx------ и rwxr-xr-x прекрасны, но rwxrwx--- не хороший ¹, даже если Вы - единственный пользователь в своей группе (если Вы предпочитаете числовые режимы: 700 или 755, нет 775).
    Если ~/.ssh или authorized_keys символьная ссылка, канонический путь (с расширенными символьными ссылками) проверяется.
  • Ваш ~/.ssh/authorized_keys файл (на удаленной машине) должен быть читаемым (по крайней мере 400), но Вам будет нужен он, чтобы быть также перезаписываемы (600), если Вы будете больше добавлять ключи к нему.
  • Ваш файл секретных ключей (на локальной машине) должен быть читаем и перезаписываем только Вами: rw-------, т.е. 600.
  • Кроме того, если SELinux установлен на осуществление, Вы, возможно, должны работать restorecon -R -v ~/.ssh (см., например, ошибка Ubuntu 965663 и отчет об ошибках Debian № 658675; это исправляется в CentOS 6).

¹ За исключением некоторых дистрибутивов (Debian и производные), которые исправили код для разрешения группы writability, если Вы - единственный пользователь в своей группе.

591
27.01.2020, 19:28
  • 1
    за указание restorecon. Я царапал голову в точно этой проблеме некоторое время теперь. –  Richard Barrell 03.12.2012, 16:56
  • 2
    Достаточно странно у меня были проблемы с учетной записью друг, настроенный на его получении VPS pubkey подлинная работа. Я думал, что все полномочия были корректны, но важно помнить это /home/USER должен быть 700 или 755 –  Rob 25.01.2013, 21:22
  • 3
    Также не забудьте проверять владельца и настройки группы, я использовал RSYNC для копирования по authorized_keys файлу и не заметил, что владелец/группа был установлен на 1 000 вместо корня! –  nak 16.02.2013, 19:23
  • 4
    также, добавляют-v к Вашей команде ssh для наблюдения то, что происходит с тем ключом. ssh -v user@host. –  tedder42 17.02.2014, 21:38
  • 5
    chmod -R 700 ~/.ssh работавший для меня для встречи ограничений этого ответа (RHEL 7) –  scottyseus 16.11.2015, 22:33

Эти шаги должны выручить Вас. Я регулярно использую это среди многих машин Ubuntu 10.04 на 64 бита.

[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'

Вы могли поместить это в сценарий с некоторыми подсказками и вызвать его как

script_name username remote_machine
1
27.01.2020, 19:28
  • 1
    Там уже существует ssh-copy-id который делает последние два шага автоматически. –  jofel 17.04.2012, 16:05
  • 2
    @jofel имеет в виду, что во многих системах ssh-copy-id не существует. @Sriharsha после mkdir необходимо добавить там chmod 700 .ssh также и btw Вы не должны быть таким образом подробные с ~/.ssh, просто .ssh достаточно, так как команды выполняются в корневом каталоге так или иначе –  janos 17.04.2012, 21:09

Два комментария: это перезапишет исходный файл. Я просто скопировал бы сгенерированный открытый ключ и сделал бы что-то как:

cat your_public_key.pub >> .ssh/authorized_keys

Это добавит ключ, который Вы хотите использовать для существующего ранее списка ключей. Кроме того, некоторые системы используют файл authorized_keys2, таким образом, это - хорошая идея сделать жесткую ссылку, указывающую между authorized_keys и authorized_keys2, на всякий случай.

4
27.01.2020, 19:28
  • 1
    Да, я заметил, что также о перезаписи, но у меня не было никого, таким образом, она не имела значения. Я создал символьную ссылку на authorized_keys2, но это не помогло. –  Thom 16.04.2012, 17:46
  • 2
    Кроме того, проверьте полномочия файла/каталога. Они описаны на веб-сайте, который Вы обеспечили. –  Wojtek Rzepala 16.04.2012, 18:00
  • 3
    Ваш ~/.ssh dir должен быть 700 Вашими файлами секретных ключей, должен быть 600 Вашими файлами с открытым ключом, должны быть 644 Ваших подлинных файла (на удаленном), должны быть 644 –  Rob 16.04.2012, 18:03
  • 4
    @Rob, который был проблемой. Если бы Вы отправили бы это как ответ, я принял бы его. –  Thom 17.04.2012, 12:08

Я столкнулся с трудностями, когда корневой каталог на удаленном не имеет соответствующих полномочий. В моем случае пользователь изменил домашний dir на 777 для некоторого локального доступа с в команде. Машина не могла соединиться с ssh ключами больше. Я изменил разрешение на 744, и оно начало работать снова.

28
27.01.2020, 19:28
  • 1
    , у Нас была эта проблема также - 755 на домашних директорах, зафиксировал ее –  davidfrancis 18.07.2012, 17:52
  • 2
    мне установили полномочия на 777 и это было проигнорировано, Спасибо!!! –  ka_lin 04.07.2016, 16:56

Ваш домашний dir шифруется? Если так, для Вашей первой ssh сессии необходимо будет обеспечить пароль. Вторая ssh сессия к тому же серверу работает с подлинным ключом. Если это верно, Вы могли переместить Ваш authorized_keys к незашифрованному dir и изменению путь в ~/.ssh/config.

То, что я закончил тем, что делал, было, создают a /etc/ssh/username папка, принадлежавшая имени пользователя, с корректными полномочиями, и помещенный authorized_keys зарегистрируйте там. Затем измененный директива AuthorizedKeysFile в /etc/ssh/config к:

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

Это позволяет многочисленным пользователям иметь этот ssh доступ, не ставя под угрозу полномочия.

55
27.01.2020, 19:28
  • 1
  • 2
    Этот ответ является существенным и помог мне - для любого задающегося вопросом, является ли это проблемой - можно видеть "pam_ecryptfs: файл Пароля, перенесенный" в Ваш auth.log; так или иначе этого не было достаточно, чтобы предложить мне помнить, что homedir был зашифрован. Также можно найти, что первый вход в систему просит пароли, последующие сессии не делают (так как он дешифрован, пока другие сессии открываются). –  pacifist 20.06.2014, 11:21
  • 3
    Святое дерьмо я искал wayyyy на долго, чтобы решить тот вопрос, заправить Вас так! –  h3. 13.02.2015, 19:33

Если у Вас есть корневой доступ к серверу, простой способ решить такие проблемы состоит в том, чтобы выполнить sshd в режиме отладки путем издания чего-то как /usr/sbin/sshd -d -p 2222 на сервере (полный путь к sshd требуемому исполняемому файлу, which sshd может помочь), и затем соединяющийся от клиента с ssh -p 2222 user@host. Это вынудит демона SSH остаться на переднем плане и отобразить отладочную информацию о каждом соединении. Ищите что-то как

debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/

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

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

(В зависимости от Вашего дистрибутива Linux сначала / последняя строка могла бы быть systemctl stop sshd.service / systemctl start sshd.service вместо этого.)

152
27.01.2020, 19:28
  • 1
    я просто попробовал это... и это хорошо работает, когда я работаю sshd -d, но сбои, после того как я на самом деле работаю service sshd start. Я уверен, что это просто, но я не гуру Linux. Какие-либо мысли? –  N Rohler 30.11.2012, 07:18
  • 2
    Для ссылки это сообщение объясняет решение SELinux, которое решило мою проблему. –  N Rohler 30.11.2012, 07:36
  • 3
    я также испытывал затруднения заставить аутентификацию с открытым ключом работать и я был вполне уверен, что полномочия каталога не были проблемой. После выполнения SSH в режиме отладки я быстро узнал, что был неправ, и полномочия были проблемами. –  ub3rst4r 14.05.2014, 08:36
  • 4
    Большой совет, моя пользовательская папка, был с неправильными полномочиями. –  gdfbarbosa 18.12.2014, 12:23
  • 5
    . Из всех причин моему пользователю не разрешили войти в систему, потому что оболочка, указанная ansible (/bin/zsh) на пользовательском создании, не существовала. Я никогда не предполагал бы это. –  chishaku 27.10.2015, 02:56

В/etc/selinux/config файле, изменяющем SELINUX на отключенный от осуществления сделанного ssh без пароля, работают успешно.

Ранее я могу сделать это на одном пути. Теперь от bothways я могу сделать ssh без пароля.

3
27.01.2020, 19:28

Гарантируйте это AuthorizedKeysFile точки к правильному местоположению, использовать %u как заполнитель для имени пользователя:

# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys

Может случиться так, что просто необходимо не прокомментировать строку:

AuthorizedKeysFile .ssh/authorized_keys

Следите за этим, необходимо перезагрузить ssh сервис для изменений для происхождения:

service sshd reload
6
27.01.2020, 19:28

Просто попробуйте эти после команд

  1. ssh-keygen

    Нажмите клавишу Enter, пока Вы не получите подсказку

  2. ssh-copy-id -i root@ip_address

    (Это однажды попросит пароль хост-системы),

  3. ssh root@ip_address

    Теперь необходимо смочь войти в систему без любого пароля

31
27.01.2020, 19:28
  • 1
    На котором сервере? –  Amalgovinus 17.06.2014, 22:47
  • 2
    @Amalgovinus, Очевидно, Вы выполняете это на клиенте, не машине, которую Вы подключаете с - Вы не хотите копию своего закрытого ключа на сервере! :) –  nevelis 24.09.2014, 19:09
  • 3
    Обратите внимание на то, что обычно разрешение удаленных корневых логинов не является рекомендуемой практикой безопасности. –  arielf 22.06.2015, 21:21

Мое решение состояло в том, что учетная запись была заблокирована. Сообщение показало в/var/log/secure: Пользователь не позволил, потому что учетной записью является заблокированное Решение: дайте пользователю новый пароль.

4
27.01.2020, 19:28
  • 1
    я зафиксировал его путем изменения поля пароля в /etc/shadow для этого пользователя от ! кому: *. После того, как та аутентификация по паролю все еще невозможна, но пользователь больше не блокируется. –  user3132194 07.04.2016, 14:53

После копирования ключей к удаленной машине и вставлению их authorized_keys необходимо сделать что-то вроде этого:

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa
35
27.01.2020, 19:28
  • 1
    На самом деле не Вы не делаете. ssh автоматически использует ~/.ssh/id_rsa (или id_dsa), не имея необходимость использовать ключевой агент. –  Patrick 07.11.2013, 03:29
  • 2
    Это может все еще быть полезным советом, если нужно было указать по-другому именованный ключ ~/.ssh/config (например, на хосте *.mydomain.org... IdentityFile ~/.ssh/some_limited_use.pub - ssh-добавляет ~/.ssh/some_limited_use.pub). –  89c3b1b8-b1ae-11e6-b842-48d705 03.02.2014, 14:11

У меня была подобная проблема с ssh. В моем случае проблема состояла в том, что я установил hadoop cloudera (от об/мин на песнях 6), и он создал пользователя hdfs с корневым каталогом

/var/lib/hadoop-hdfs (не стандартный /home/hdfs).

Я изменился в/etc/passwd /var/lib/hadoop-hdfs кому: /home/hdfs, перемещенный корневой каталог к новому местоположению и теперь я могу соединиться с аутентификацией с открытым ключом.

1
27.01.2020, 19:28

Теги

Похожие вопросы