Как использовать SSH-аутентификацию с открытым ключом

17689
Poma

У меня есть 2 сервера Ubuntu 12.04 (бета) (узел 1 и узел 2), и я хочу установить корневой доступ без пароля между ними. Другие пользователи не должны иметь доступа к другим ящикам. Также обратите внимание, что порт ssh по умолчанию изменен на 220.

Вот что я сделал:

sudo -i cd /root/.ssh ssh-keygen -t rsa # with default name and empty password cat id_rsa.pub > authorized_keys

затем скопировал id_rsa & id_rsa.pub в node2 и добавил id_rsa.pub в authorized_keys. Оба хоста имеют одинаковый файл /root/.ssh/config:

Host node1 Hostname 1.2.3.4 Port 220 IdentityFile /root/.ssh/id_rsa  Host node2 Hostname 5.6.7.8 Port 220 IdentityFile /root/.ssh/id_rsa

Теперь проблема в том, что когда я набираю, ssh node2он спрашивает у меня пароль. В чем может быть проблема?

Обновить:

Отладочная информация на клиенте:

debug1: Server host key: RSA *** debug1: Host '[*.*.*.*]:220' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:6 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /root/.ssh/id_rsa ((nil)) debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /root/.ssh/id_rsa debug1: read PEM private key done: type RSA debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password debug2: we did not send a packet, disable method debug1: Next authentication method: password

Отладочная информация на сервере:

debug1: userauth-request for user root service ssh-connection method none [preauth] debug1: attempt 0 failures 0 [preauth] debug1: PAM: initializing for "root" debug1: PAM: setting PAM_RHOST to "*.*.*.*" debug1: PAM: setting PAM_TTY to "ssh" debug1: userauth-request for user root service ssh-connection method publickey [preauth] debug1: attempt 1 failures 0 [preauth] debug1: test whether pkalg/pkblob are acceptable [preauth] debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: trying public key file /root/.ssh/authorized_keys debug1: fd 4 clearing O_NONBLOCK debug1: matching key found: file /root/.ssh/authorized_keys, line 2 Found matching RSA key: **** debug1: restore_uid: 0/0 debug3: mm_answer_keyallowed: key 0x7f0647b0c1b0 is allowed debug3: mm_request_send entering: type 22 debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth] Postponed publickey for root from *.*.*.* port 38887 ssh2 [preauth]

Разрешения:

drwx------ 2 root root 4096 Mar 26 15:34 .ssh  -rw------- 1 root root 840 Mar 26 14:50 authorized_keys -rw-r--r-- 1 root root 225 Mar 26 15:34 config -rw------- 1 root root 1679 Mar 26 14:47 id_rsa -rw-r--r-- 1 root root 2652 Mar 26 14:39 known_hosts

Несколько строк из конфигурационных файлов:

PermitRootLogin without-password RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile %h/.ssh/authorized_keys UsePAM no # also tried yes
5
Вы уже прошли через все остальные вопросы по этому поводу? Есть много предложений относительно того, как решить эту проблему, и это обычно сводится к разрешениям для .ssh / * и / etc / sshd_config Paul 12 лет назад 0
@Paul Да, я прочитал их (не * все *, если честно) и не нашел ничего полезного Poma 12 лет назад 0
Это отладка со стороны клиента? Можете ли вы включить отладку на стороне сервера и посмотреть, что ей не нравится? Paul 12 лет назад 0
Какое разрешение у самого / root? Лучше было бы использовать пары ключей и добавлять открытый ключ к авторизованным ключам удаленной стороны, а не копировать закрытые ключи. Bruno 12 лет назад 1
@Paul добавил отладочную информацию сервера на мой вопрос Poma 12 лет назад 0
Разрешения @Bruno / root как всегда 700 Poma 12 лет назад 0
Пома, ты уверен, что это конец отладки сервера - вставленный журнал не доходит до того места, где он выходит из строя, после откладывания его должно быть больше. Paul 12 лет назад 0
@ Пол да это последняя строка. В этот момент клиент ssh запрашивает пароль. Poma 12 лет назад 0
Я не вижу id_rsa.pub в вашем списке разрешений. У вас есть один на "клиентском" компьютере? Кроме того, согласно рекомендациям root @ machinea копирует свой id_rsa.pub в machineb: /root/.ssh/authorized_keys, а root @ machineb копирует свой id_rsa.pub в machinea: /root/.ssh/authorized_keys. Здесь полезно поле комментария (author_keys, сразу после ключа, пробел, затем комментарий). Также http://askubuntu.com/questions/54670/passwordless-ssh-not-working предполагает, что у пользователя dir (/ root?) Есть разрешение go + rx. maxwellb 12 лет назад 0

5 ответов на вопрос

3
eallrich

Зашифрован ли домашний каталог root (возможно, ecryptfs)?

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

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

+1: спасибо, у меня была проблема с `.Xauthority`, и я подумал, что это связано. Кажется, это первый раз, когда я пытаюсь `ssh` на другой мой компьютер без входа в систему ... Avio 12 лет назад 0
1
Michael Hampton

ssh comes with a command to copy the public key to the remote server, ssh-copy-id. It takes care of any necessary permissions and various other "gotcha" issues.

Example:

ssh-copy-id -i $HOME/.ssh/id_dsa user@server.example.com

After copying with ssh-copy-id you should no longer be asked for a password when you ssh.

0
jakob

Некоторые предложения:

  • Проверьте разрешения вашего /root/.ssh (и его содержимого
  • Проверьте, разрешает ли ssh аутентификацию root-пользователя и / или открытый ключ (/ etc / ssh / sshd_config iirc)
  • используйте ssh -v -v, чтобы увидеть больше результатов отладки
Я уже проверил это. Все выглядит хорошо для меня. Я обновил свой ответ с дополнительной информацией. Poma 12 лет назад 0
0
tuomassalo

Use LogLevel DEBUG in /etc/ssh/sshd_config to debug. One possible gotcha is having the .ssh directory in /home/someuser/, as it should be under /root/.

0
ansi_lumen

I encountered this, because I had one encrypted user on my system. This leads the sshd into the assumption, that every users directory is encrypted and the authorized_keys file is located under /etc/ssh/username/authorized_keys

For me it worked, after I moved the authorized key to /etc/ssh/username/ and then chown -R username:username /etc/ssh/username/. Funny enough, that I had to do this for every user, even the not encrypted ones!

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