Відкритий ключ 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 man:

   -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варіант, мабуть, найпростіший.

Неправильно сформований файл дозволених ключів на хості призначення є ще однією причиною, коли ssh видає повідомлення "ми не надіслали пакет" і запитує пароль замість використання автентичності pubkey: -

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).

Цей точний рядок повідомлень про помилки у запитанні також може виникнути у випадку пропущеної пари приватних / відкритих ключів на локальній стороні . Ні, це не має сенсу, але я просто виривав волосся надовго, намагаючись зрозуміти, що відбувається.

• Віддалена система A .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: Підключення з паролем та хвостом журналу

хвіст -f /var/log/auth.log

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

У моєму випадку каталог / root був 770, а не 700, що за замовчуванням. Помилка була "Відхилена автентифікація: неправильне володіння або режими для каталогу / root"

Виправте це, і ви закінчите.

Спробуйте

/sbin/restorecon -r /root/.ssh

Можлива проблема з продажем контексту

Після бігу

ssh-copy-id user@remote-host

зазвичай це має працювати. Але якщо це не вдалося, спробуйте це: увійдіть до віддаленого хоста як користувача, у якого ви хочете ввійти у майбутнє та запустіть:

ssh-keygen

Це мені допомогло.

Тож у мене сталося те, що у мене є 2 VM для доступу з моєї локальної машини (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