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

На этот вопрос уже есть ответ здесь:

У меня проблемы с настройкой аутентификации с открытым ключом для SSH-сервера на Ubuntu Server 12.04 (A) для аутентификации с Ubuntu Server 13.04 (B).

Что я делаю сейчас (я пытаюсь следовать инструкциям здесь):

  • На B: Создайте новый ключ с помощью ssh-keygen -C "", не используя ключевую фразу, записывая в /.ssh/id_rsa - я не получаю никаких ошибок
  • На B: Запустите ssh-copy-id -i /. ssh/id_rsa user@host-a - также сообщение об успехе
  • На B: ssh -i /.ssh/id_rsa user@host-a - мне все еще нужно ввести пароль для user@host-a

На A я проверил, изменен ли /.ssh/authorized_keys после выполнения ssh-copy-id, и это так. Также на обоих устройствах я добавил следующее в /etc/ssh/sshd_config:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile /.ssh/authorized_keys

Кто-нибудь знает, в чем может быть проблема?


Вот хвост моего /var/log/auth.log на машине A:

Jun 13 22:17:56 laptop-camil sshd[12344]: Server listening on 0.0.0.0 port 22.
Jun 13 22:17:56 laptop-camil sshd[12344]: Server listening on :: port 22.
Jun 13 22:18:27 laptop-camil sshd[12345]: Authentication refused: bad ownership or modes for directory /.ssh
Jun 13 22:18:30 laptop-camil sshd[12345]: Accepted password for camilstaps from 164.138.27.37 port 48407 ssh2
Jun 13 22:18:30 laptop-camil sshd[12345]: pam_unix(sshd:session): session opened for user camilstaps by (uid=0)
Jun 13 22:18:35 laptop-camil sshd[12464]: Received disconnect from 164.138.27.37: 11: disconnected by user
Jun 13 22:18:35 laptop-camil sshd[12345]: pam_unix(sshd:session): session closed for user camilstaps
Jun 13 22:18:42 laptop-camil sshd[12516]: Authentication refused: bad ownership or modes for directory /.ssh
Jun 13 22:18:44 laptop-camil sshd[12516]: Connection closed by <host-b> [preauth]
10
задан 15 November 2017 в 17:05

5 ответов

Каталог ~/.ssh ДОЛЖЕН принадлежать пользователю, а не пользователю root. Так что измени это, и это сработает.

Чтобы не вводить парольную фразу для вашего личного ключа каждый раз, когда вы используете ssh-agent. ssh-add .ssh/id_rsa добавит ключ к агенту, с этого момента агент предоставит ключ для ssh.

0
ответ дан 15 November 2017 в 17:05

Ничто не работало на меня. Я не знаю почему? Я попробовал каждое решение.

Сначала

ssh-copy-id: не скопировал id_rsa и id_rsa.pub

Второй

$SHELL ssh-агента

ssh-добавьте-L

ssh-добавить

ssh-copy-id-i удаленный хост

Оба не работали. Я предполагаю, что я неудачен. Кто-то говорил для изменения разрешения .ssh папка от корня. Я думал, что это будет не более оптимальным вариантом. Что я делал, когда мой выше случая перестал работать. Я создал новый ключ на сервере, и сохраните, это включает GitHub / gitlab. Это - также не прохладный путь. Здесь я попробовал альтернативу, я надеюсь, что она может помочь кому-то.

Сначала я создаю папку на удаленном сервере с теми полномочиями пользователя, кто может записать в него. Затем я следую ниже шагов на моей локальной машине

CD ~/.ssh

scp-r * remote_user@192.168.100. **:path_to_writable_folder_on_remote_server

И затем я вошел в систему на удаленном сервере и затем

CD path_to_that_folder_where_I_copied_keys

И затем

mv * ~/.ssh

(ух) Наконец это работало.

0
ответ дан 15 November 2017 в 17:05

Что-нибудь в файлах журналов, в частности /var/log/auth.log? Вы также можете дважды проверить разрешения для каталога и файлов .ssh.

Мне самому не пришлось изменять sshd_config для такого типа доступа. Мне интересно, если ваша модификация сломала вещи, особенно строку AuthorizedKeysFile. Как правило, вы хотели бы поместить author_keys в $USER/.ssh.

Вот разрешение пользователя на одном из моих серверов:

:~/.ssh$ ls -ld .
drwx------ 2 rrd rrd 4096 May 28 17:57 .

:~/.ssh$ ll
total 280
-rw-r----- 1 rrd rrd   4351 May 22 16:20 authorized_keys
-rw------- 1 rrd rrd   1679 Apr 27  2012 id_rsa
-rw-r--r-- 1 rrd rrd    399 Apr 27  2012 id_rsa.pub
-rw-r--r-- 1 rrd rrd 266138 Jun 13 00:18 known_hosts

Убедитесь, что для отдельных файлов это ограничение по крайней мере.

Как указывает Гантберт, также проверьте, что каталог и файлы принадлежат вам. В противном случае разрешения не будут иметь смысла (или работают).

Кто владеет ключами в author_keys на B? (Бит, который говорит user @ host после ключа.) Это root @ A?

То есть, глядя на ~/.ssh/authorized_keys, что эквивалентно bert@etherbert для вашей установки: [ 1112]

ssh-rsa AAAA...ffsII8dSaDF33 bert@etherbet

Я бы просто отредактировал удаленные .ssh / авторизованные ключи вручную для тестирования, вставив содержимое id_rsa.pub пользователя, с которым вы инициируете соединение.

Убедитесь, что вы пришли от пользователя, у которого есть ключ в удаленном файле author_keys.

0
ответ дан 15 November 2017 в 17:05

Это старый вопрос, на который уже дан ответ, но если у пользователя есть зашифрованный домашний каталог (с использованием ecryptfs или чего-то подобного), демон ssh не сможет увидеть файл ~ / .ssh / authorized_keys. Если это так, следуйте решению, указанному здесь здесь .

Это решение рекомендует изменить конфигурацию sshd (/ etc / ssh / sshd_config) и изменить AuthorizedKeysFile на /etc/ssh/%u/authorized_keys, а также скопировать ваш файл author_keys в файл / etc / ssh / username / author_keys (вместе с соответствующими право собственности на / etc / ssh / username и соответствующие разрешения, как того требует sshd).

0
ответ дан 15 November 2017 в 17:05

Помимо всех других парней предоставил решения, мое дополнительное предложение - Вы, должен сначала проверить регистрирующийся файл: /var/log/secure, то, которое является, куда sshd помещает, входит в систему. Если что-то идет не так, как надо, проверяя то, в чем жаловался sshd /var/log/secure быстро сузит возможные проблемы.

2
ответ дан 15 November 2017 в 17:05

Другие вопросы по тегам:

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