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


5

У меня есть 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

Вы уже прошли через все остальные вопросы по этому поводу? Есть много предложений относительно того, как решить эту проблему, и это обычно сводится к разрешениям для .ssh / * и / etc / sshd_config
Пол

@Paul Да, я прочитал их (не все, если честно) и не нашел ничего полезного
Poma

Это отладка со стороны клиента? Можете ли вы включить отладку на стороне сервера и посмотреть, что ей не нравится?
Пол

1
Какое разрешение есть для самого root? Лучше было бы использовать пары ключей и добавлять открытый ключ к авторизованным ключам удаленной стороны, а не копировать закрытые ключи.
Бруно

@Paul добавил отладочную информацию сервера к моему вопросу
Poma

Ответы:


3

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

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

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


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

1

ssh поставляется с командой для копирования открытого ключа на удаленный сервер ssh-copy-id. Он позаботится о любых необходимых разрешениях и различных других проблемах.

Пример:

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

После копирования у ssh-copy-idвас больше не должно запрашиваться пароль при вас ssh.


0

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

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

Я уже проверил это. Все выглядит нормально для меня. Я обновил свой ответ с дополнительной информацией.
Пома

0

Использование LogLevel DEBUGв /etc/ssh/sshd_configотладить. Одна из возможных ошибок - наличие .sshдиректории /home/someuser/, как и должно быть /root/.


0

Я столкнулся с этим, потому что у меня был один зашифрованный пользователь в моей системе. Это приводит sshd к предположению, что каждый каталог пользователей зашифрован, а файл author_keys находится в/etc/ssh/username/authorized_keys

У меня это сработало, после того как я переместил авторизованный ключ на /etc/ssh/username/и потом chown -R username:username /etc/ssh/username/. Забавно, что я должен был сделать это для каждого пользователя, даже не зашифрованного!

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.