Занадто багато збоїв аутентифікації для * ім'я користувача *

У мене є обліковий запис хост-менеджера з включеним дозволом ssh. Під час спроби завантажити згенерований файл ключа .pub за допомогою цієї команди:

rsync -av -e "ssh -p2222" /home/user/.ssh/key.pub username@111.222.33.44:.ssh/authorized_keys

Я продовжую отримувати:

Отримано відключення від 111.222.33.44: 2: Забагато помилок аутентифікації для імені користувача
rsync: з'єднання несподівано закрите (0 байтів, отриманих дотепер) [відправник]
Помилка rsync: незрозуміла помилка (код 255) у io.c (601) [sender = 3.0.7]

Я раніше грав із ssh, поки не отримав автентичну помилку. Але зараз здається, що лічильник несправностей аутентичності не скидається (чекали більше 12 годин, технічна підтримка "припускає" його скидає через 30 хв до 1 години, а інший хлопець сказав мені "він скидає кожен раз, коли ви намагаєтесь увійти з ім’я користувача ", jeesh).

Це ганяє мене. У мене навіть це було налаштовано на власному сервері Slicehost і було менше проблем, ніж у цих хлопців.

Якісь поради? Можливо, це щось із боку клієнта, а не з боку сервера.

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

Ви можете переконатися в цьому, додавши -vпрапор до sshкоманди, щоб отримати багатослівний вихід. Ви побачите, що пропонується купа ключів, поки сервер не відхилить з'єднання, кажучи: "Забагато помилок аутентифікації для [користувача]" . Без багатословного режиму ви побачите лише неоднозначне повідомлення "Скидання з’єднання одночасно" .

Щоб запобігти пропонуванню невідповідних ключів, вам слід чітко вказати це у кожному записі хоста у ~/.ssh/configфайлі (на клієнтській машині), додавши IdentitiesOnlyтак:

Host www.somehost.com
  IdentityFile ~/.ssh/key_for_somehost_rsa
  IdentitiesOnly yes
  Port 22

Якщо ви використовуєте ssh-агент, він допомагає запустити, ssh-add -Dщоб очистити особи.

Якщо ви не використовуєте жодної конфігурації хостів ssh, вам слід чітко вказати правильну клавішу в sshкоманді, наприклад:

ssh -i some_id_rsa -o 'IdentitiesOnly yes' them@there:/path/

Примітка: параметр "IdentitiesOnly yes" повинен бути між цитатами.

або

ssh -i some_id_rsa -o IdentitiesOnly=yes them@there:/path/

Я знайшов простіший спосіб зробити це (якщо використовується автентифікація пароля):

ssh -o PubkeyAuthentication=no username@hostname.com

Це змушує неідентифікувати аутентифікацію. Мені вдалося ввійти негайно.

Довідково

Я також отримував цю помилку і виявив, що це відбувається, якщо сервер був налаштований приймати до 6 спроб:

/etc/ssh/sshd_config
...
...
#MaxAuthTries 6

Окрім встановлення IdentitiesOnly yesу вашому ~/.ssh/configфайлі, у вас є ще декілька варіантів.

1. Збільшити MaxAuthTries(на ssh-сервері)
2. видаліть декілька ключових пар, які були у вашому ~/.ssh/каталозі, і запустітьssh-add -D
3. явно пов’язати ключ із заданим хостом у вашому ~/.ssh/configфайлі

Так:

host foo
hostname foo.example.com
IdentityFile /home/YOU/.ssh/foo

1. Мабуть, це не дуже вдалий спосіб вирішити це, враховуючи, що він трохи послабить ваш ssh-сервер, оскільки він тепер прийме більше ключів у даній спробі підключення. Подумайте тут про грубі сили векторів нападу.

2. Це хороший спосіб припустити, що у вас є непотрібні ключі та їх можна назавжди видалити.

3. І підхід до встановлення IdentitiesOnly - це, мабуть, кращі способи вирішення цього питання!

Я додав до ~ / .ssh / config це:

Host *
IdentitiesOnly yes

Він дозволяє опцію IdentitiesOnly = так за замовчуванням. Якщо вам потрібно буде підключитися з приватним ключем, вам слід вказати його за допомогою параметра -i

Якщо ви отримали таку помилку SSH:

$ Received disconnect from host: 2: Too many authentication failures for root

Це може статися, якщо у вашій системі (за замовчуванням у моїй системі) є п'ять або більше файлів посвідчень DSA / RSA, які зберігаються у вашому каталозі .ssh, і якщо параметр '-i' не вказаний у командному рядку.

Клієнт ssh спочатку спробує увійти, використовуючи кожну особу (приватний ключ) та наступний запит на автентифікацію пароля. Однак sshd припиняє з'єднання після п’яти спроб поганого входу (знову ж за замовчуванням може змінюватися).

Якщо у вашому каталозі .ssh є кілька приватних ключів, ви можете відключити "Аутентифікацію відкритих ключів" у командному рядку, використовуючи додатковий аргумент "-o".

Наприклад:

$ ssh -o PubkeyAuthentication=no root@host

Якщо у вас є пароль і ви хочете просто використовувати пароль для входу, ось як це зробити.

Щоб використовувати ТОЛЬКУ автентифікацію пароля і НЕ використовувати відкритий ключ, а НЕ використовувати дезактивні "клавіатурно-інтерактивні" (це суперсеть, включаючи пароль), ви можете зробити це з командного рядка:

ssh -o PreferredAuthentications=password user@example.com

Виходячи з приказки @David, просто додайте це IdentitiesOnly yes до свого .ssh / config, це робить те саме, що іssh -o PubkeyAuthentication=no.

Після входу в систему видаліть .ssh/authorized_keys. Тепер поверніться до локальної машини і введіть наступне

cat ~/.ssh/id_rsa.pub | ssh -o PubkeyAuthentication=no user@IP_ADDR 'cat >> .ssh/authorized_keys'. Це має знову ввімкнути ваш ssh за допомогою відкритого ключа

Я знаю, що це старий потік, але я просто хотів додати сюди, що я наткнувся на те саме повідомлення про помилку, але це викликано власником папки .ssh root, а не користувачем, який використовував ключ. Я виправив проблему, виконавши наступні команди:

sudo chown -R user:user /home/user/.ssh

Я також переконався, що дозволи в папці .ssh були правильними:

sudo chmod 700 /home/user/.ssh

Файли в каталозі .ssh повинні мати дозвіл 600:

sudo chmod 600 /home/user/.ssh/authorized_keys

У моєму випадку проблема полягала в дозволах до каталогу. Це зафіксувало це для мене:

$ chmod 750 ~;chmod 700 ~/.ssh

У моєму випадку це сталося тому, що я використовував ім'я користувача "ubuntu", але ім'я користувача в цьому випадку було "ec2-користувачем"

Після того, як я зробив те, що запропонував "Джон Т", я отримав цю помилку:

Дозвіл відхилено (publickey).

Тоді я знайшов рішення (тобто змінити ім’я користувача на "ec2-користувач") у цій відповіді: https://stackoverflow.com/questions/1454629/aws-ssh-access-permission-denied-publickey-issue

У мене був відкритий ключ .ssh/authorized_keys2, але сервер був налаштований лише на читання .ssh/authorized_keys:

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys

Після переміщення мого файлу до програми .ssh/authorized_keysя можу успішно увійти за допомогою свого ключа.

Занадто багато збоїв аутентифікації

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

Ось кілька пропозицій:

• Додайте, -vщоб побачити, чи це так (ви використовуєте занадто багато посвідчень).
• Список доданих ідентифікаторів від ssh-add -l.
• Видалити відсутність ідентичності від агента по: ssh-add -d.
• Ви також можете видалити всі ідентичності шляхом ssh-add -Dповторного додавання лише відповідних.

• Якщо ви маєте доступ до SSH-сервера, перевірте MaxAuthTriesпараметр (див. man sshd_config:).

  ^{Повідомлення, пов’язане з цим: Що таке з'єднання для sshd_configобмеження "MaxAuthTries"?}

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

Це повідомлення може з’являтися, коли не введено правильне ім’я користувача та пароль.

Спочатку перевірте, чи вказаний користувач:

vim /etc/passwd