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

Question 1

У этого вопроса уже есть ответ здесь: ssh больше не разрешает проверку открытого ключа 9 ответов

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

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

В B: Создайте новый ключ с ssh-keygen -C "", не используя кодовую фразу, записывая /.ssh/id_rsa - У меня нет ошибок. В B: Запустите ssh-copy-id -i /.ssh/id_rsa user@host-a - также сообщение об успешном завершении On 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]

Question 2

Каталог ~/.ssh ДОЛЖЕН быть владельцем пользователя, а не root. Поэтому измените это, и оно будет работать.

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

Question 3

Question 4

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

Question 5

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

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

Question 6

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

Первый

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

Первый

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

ssh-add -L ssh-add ssh-copy-id -i remote-host

ssh-agent $ SHELL

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

ssh-add -L

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

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

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

cd ~ / .ssh [ ! d15] mv * ~ / .ssh

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

guntbert · Answer 1 · 24 May 2018 в 21:05

Каталог ~/.ssh ДОЛЖЕН быть владельцем пользователя, а не root. Поэтому измените это, и оно будет работать.

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

3

ответ дан guntbert 24 May 2018 в 21:05

1

Это показывает прогресс! :), но теперь я должен вводить кодовую фразу и пароль для удаленного хоста каждый раз, когда я открываю SSH-соединение .. – Keelan 14 June 2013 в 01:47
2

@CamilStaps, см. Мой обновленный ответ. – guntbert 14 June 2013 в 01:51
3

К сожалению, это не помогает :( (Примечание: мне пришлось делать этот ) – Keelan 14 June 2013 в 01:58
4

Если вы входите в систему графически, вы можете добавить кольцо для ключей, чтобы ключ для вашего ssh был автоматически добавлен каждый раз, когда вы входите в систему. Если вы входите на эту машину, вам больше не нужно добавлять пароль после этого. Если вы не выходите из системы, вам нужно добавить этот пароль еще раз. Если у вас возникли проблемы с подключением, попробуйте ssh -v -v -v -v (да, много -v), чтобы получить больше логарифмов, которые случаются при подключении с клиента. Читайте и смотрите на странные сообщения. /var/log/auth.log - это сообщения на стороне сервера, вы всегда должны смотреть туда. – Anders 14 June 2013 в 23:24

Meow · Answer 2 · 24 May 2018 в 21:05

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

Извините, но этот файл даже не существует на моих установках. — Keelan, 22 January 2016 в 17:14

journeyer · Answer 3 · 24 May 2018 в 21:05

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

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

Vineet · Answer 4 · 24 May 2018 в 21:05

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

Первый

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

Первый

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

ssh-add -L ssh-add ssh-copy-id -i remote-host

ssh-agent $ SHELL

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

ssh-add -L

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

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

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

cd ~ / .ssh [ ! d15] mv * ~ / .ssh

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

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

4 ответа

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

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