Открытый ключ SSH не отправляется на сервер

Я боролся с этим в течение пары часов, поэтому любая помощь очень ценится ...

У меня есть 2x сервера, на обоих из которых я могу использовать sshоткрытые ключи от OSX, никаких проблем там нет, поэтому я уверен, что все хорошо sshd_config.

Я пытаюсь настроить задание cron для rsyncсинхронизации двух серверов, и мне нужен сервер B (резервный) для sshподключения к серверу A с помощью открытого ключа.

Я не могу на всю жизнь понять, почему он не находит мои открытые ключи - они находятся ~/.ssh/(т.е. /root/.ssh), и все права доступа к файлам правильны для A & B.

Это вывод:

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug3: no such identity: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

Также обратите внимание, что он ищет закрытые ключи, которые не существуют ...

drwx------. 2 root root 4096 May 25 10:15 .
dr-xr-x---. 4 root root 4096 May 24 18:52 ..
-rw-------. 1 root root  403 May 25 01:37 authorized_keys
-rw-------. 1 root root    0 May 25 01:41 config
-rw-------. 1 root root 1675 May 25 02:35 id_rsa_tm1
-rw-------. 1 root root  405 May 25 02:35 id_rsa_tm1.pub
-rw-------. 1 root root  395 May 25 02:36 known_hosts

Взгляните на вашу страницу ssh:

   -i identity_file
          Selects a file from which the identity (private key) for public
          key authentication is read.  The default is ~/.ssh/identity for
          protocol   version   1,   and  ~/.ssh/id_dsa,  ~/.ssh/id_ecdsa,
          ~/.ssh/id_ed25519 and ~/.ssh/id_rsa  for  protocol  version  2.
          Identity files may also be specified on a per-host basis in the
          configuration file.  It is possible to have multiple -i options
          (and  multiple  identities  specified  in configuration files).

или справочную страницу ssh_config:

   IdentityFile
          Specifies a file from which the user's DSA, ECDSA,  ED25519  or
          RSA   authentication   identity   is   read.   The  default  is
          ~/.ssh/identity for  protocol  version  1,  and  ~/.ssh/id_dsa,
          ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/id_rsa for proto‐
          col version 2.  Additionally, any identities represented by the
          authentication  agent  will  be  used for authentication unless
          IdentitiesOnly is set.

Видите ли, есть несколько специальных имен файлов, которые пробуются, если вы не указали ключ. Это также файлы, которые вы видите в журнале.

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

• укажите файл явно, используя вышеуказанную -iопцию.
• настройте файл в конфигурации клиента, используя вышеуказанную IdentityFileопцию.
• добавьте ключ к вашему агенту, используя ssh-add.

Для интерактивных сессий агент является наиболее гибким. Для вашей работы cron -iвариант, вероятно, самый простой.

Неправильно сформированный файл author_keys на хосте назначения является еще одной причиной, по которой ssh ​​выводит сообщение «мы не отправляли пакет» и запрашивает пароль вместо использования pubkey auth: -

debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
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

Проблема в данном конкретном случае заключалась в том, что в данных открытого ключа, которые были вставлены в .ssh/authorized_keysхост назначения, отсутствовал их первый символ:

sh-rsa AAAA...

Решение было просто добавить недостающие буквы "s".

ssh-rsa AAAA...

И другие:-

debug1: Next authentication method: publickey
debug1: Offering RSA public key: ~/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
...
debug1: Authentication succeeded (publickey).

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

• Удаленная система А .ssh/mykey.pubскопировала в .ssh/authorized_keys.
• Локальная система B имеет .ssh/mykeyправильный закрытый ключ для сопоставления с открытым ключом системы A, но также имеет .ssh/mykey.pubфайл с ошибками, возможно, предыдущую версию замененного ключа.

SSH от B до A ( ssh -i mykey A) не будет работать с сообщениями в вопросе, особенно если вы включите его -vvиз ssh-клиента, вы увидите:

Пробуем закрытый ключ: .ssh / mykey
мы не отправляли пакет, отключаем метод

Это ложь, потому что фактический ключ не был опробован, он, очевидно, использовал файл локального открытого ключа с соответствующим именем, чтобы выяснить, может ли он работать, а затем фактически ничего не делал, когда они были несоответствующими. Никакое количество отладочной информации с обеих сторон на самом деле не намекает на проблему.

Имена файлов по умолчанию, которые ищет ssh, являются id_rsaи id_rsa.pub.

Если вы хотите использовать другие имена файлов, вы должны либо указать их ssh_config( с помощью IdentityFileпараметра) или через SSH командной строки параметра -i.

У меня была такая же проблема на RedHat; проверил логи и обнаружил, что домашний каталог имеет неправильные права пользователя.

sshd[2507]: Authentication refused: bad ownership or modes for directory /home/user

Исправление прав на домашний каталог решило эту проблему.

Простой способ отладки в Debian / Ubuntu: подключитесь с паролем и подключите журнал

tail -f /var/log/auth.log

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

В моем случае каталог / root был 770, а не 700, что является значением по умолчанию. Ошибка была «Отказ в аутентификации: неправильное владение или режимы для каталога / root»

Исправьте это, и все готово.

Пытаться

/sbin/restorecon -r /root/.ssh

Возможная проблема с продажным контекстом

После запуска

ssh-copy-id user@remote-host

обычно это должно работать. Но если это не удается, попробуйте следующее: войдите на удаленный хост как пользователь, которому вы хотите войти в будущем, и выполните:

ssh-keygen

Это помогло мне.

Так что для меня произошло то, что у меня есть 2 виртуальные машины для доступа с моей локальной машины (2 ключа id_rsa.pub и id_rsa2.pub). Я понял, что мое соединение ssh по умолчанию использует id_rsa.pub для любого соединения ssh user@xx.xx.xx.xx. Я решил свою проблему, добавив файл конфигурации и указав идентификатор, который будет использоваться для каждого хоста, как показано ниже:

vi ~/.ssh/config

Add both hostnames and their identity file as follows:

Host server1.nixcraft.com
  IdentityFile ~/Users/.ssh/id_rsa1
Host server2.nixcraft.com
  IdentityFile /backup/home/aymen/.ssh/id_rsa2

клиент:

vim /etc/ssh/ssh_config

#add your key 
IdentityFile ~/.ssh/yourkey

service sshd restart