Під час підключення до серверу по SSH ви можете отримати помилку "Received disconnect from x.x.x.x port 22:2: too many authentication failures" або "ssh permission denied (publickey)". Якщо коротко, то це означає, що ваш SSH клієнт не зміг авторизуватись на віддаленому сервері тому що закінчився ліміт спроб авторизації.
В цій статті ми розглянемо чому могла виникнути така проблема, як це все працює, а також як її виправити і налаштувати систему щоб такого не траплялось у майбутньому для цього SSH з'єднання. При написанні статті використовувалась Ubuntu 24.04, але інформація має бути актуальною і для інших дистрибутивів.
Зміст
Чому виникає помилка?
SSH підтримує декілька способів авторизації, основні з них авторизація без паролю за допомогою пари відкритого та закритого ключів і звичайна авторизація за допомогою паролю. Звісно, перший варіант більш надійний, зручний та безпечний, оскільки вам не потрібно пам'ятати пароль, а зловмисники які захочуть проникнути на ваш сервер не зможуть навіть спробувати його підібрати.
Тому авторизація по ключу використовується за замовчуванням. В більшості випадків це не є проблемою, тому що сервер повідомляє клієнту які методи які методи авторизації можна використовувати, а клієнт вибирає порядок в якому він буде їх перебирати. Але загальна кількість спроб авторизації обмежена. І якщо щось не співпадає, і клієнт не встигає авторизуватись, тоді виникає така помилка.
Якщо ви так і хотіли авторизуватись по ключу, то тут є три можливі причини проблеми:
- Ваш ключ не доданий на сервер. Для того щоб це працювало на вашому комп'ютері має бути приватний ключ, а на віддаленому відповідний публічний ключ має бути доданий в файл ~/.ssh/authorized_keys.
- Ваш ключ не доданий до агента ssh. Якщо ви переносили ключі з іншого компьютера, то не достатньо просто покласти їх в каталог ~/.ssh. Вони також мають бути додані за допомогою команди ssh-add.
- В вашій системі багато ключів. Якщо навіть ключ доданий, але у вас їх багато, то SSH клієнт пробує перші декілька, і якщо вони не підходять, оскільки на кількість авторизацій є обмеження, ви отримуєте помилку.
Якщо ж ви хочете авторизуватись по паролю, то все трохи інакше:
- Сервер підтримує авторизацію по ключу. Якщо SSH сервер повідомить що він підтримує авторизацію по ключу і у вас багато ключів в системі, то SSH вам навіть не запропонує ввести пароль, і ви зіштовхнетесь з тими ж проблемами, що і вище. Щоб це поправити можна вказати порядок способів авторизації за допомогою опцій команди ssh.
- Ви використовуєте не той механізм авторизації. Існує декілька механізмів авторизації SSH які передбачають введення пароля, як мінімум це password та keyboard-interactive. Якщо ви налаштували використання password перед publickey, а сервер хоче keyboard-interactive, буде та сама помилка.
У будь-якому випадку немає сенсу пробувати здогадатись в чому там проблема. Потрібно подивитись логи. Для цього додайте до вашої команди підключення до сервера по SSH опцію -vvv. Наприклад:
ssh -vvv serhii@192.168.56.124
Така команда покаже не тільки саму помилку, але і процес підключення. Спочатку команда виведе багато інформації про читання конфігурації. Звернути увагу потрібно на стрічку preferred, в якій перечислений порядок механізмів авторизації яку клієнт буде використовувати:
А також на процес авторизації, які ключі (get_agent_identities) використовуються, та де стається помилка:
Як виправити помилку?
В цій статі я не буду розглядати як додати ключ на сервер, налаштувати там права на файл ~/.ssh/authorized_keys, та тому подібне. Припустимо, що сервер налаштований правильно, він готовий авторизувати вас по ключу або по паролю. Тепер залишається зрозуміти як налаштувати SSH клієнт так щоб все запрацювало.
1. Не перебираємо всі ключі
Як я і писав вище, за замовчуванням SSH клієнт намагається авторизуватись за допомогою всіх ключів які доступні в системі, ось:
Ну і відповідно отримує помилку від сервера якщо перші чотири ключі не підходять. Але можна зробити по іншому. За допомогою опції IdentitiesOnly можна повідомити SSH клієнту що ви хочете щоб брались тільки ключі, перечислені за допомогою опції IdentifyFile в конфігурації. Для цього додайте опцію IdentitiesOnly зі значенням yes в файл /etc/ssh/ssh_config:
/etc/ssh/ssh_configIdentitiesOnly=yes
Після цього процес авторизації буде виглядати ось так:
Всі ці ключі перечислені в тому ж файлі /etc/ssh/ssh_config і в наступному пункті розглянемо як налаштувати свій ключ. Вже цей крок може вирішити проблему з "too many authentication failures". Але якщо замість неї явилась помилка "ssh permission denied (publickey)", то рухаємось далі.
2. Вказуємо ключ для авторизації
Ви можете точно вказати який ключ ви хочете використовувати за допомогою опції IdentityFile. В команду підключення треба передати шлях до файлу приватного ключа для авторизації, в моєму випадку ~/.ssh/id_ed25519_7:
ssh -o IdentityFile=~/.ssh/id_ed25519_7 serhii@192.168.124.58
Для того щоб не треба було додавати цю опцію при кожному запускові команди, її можна додати для цього хоста в файлі ~/.ssh/config:
~/.ssh/configHost 192.168.124.58
IdentityFile ~/.ssh/id_ed25519_7
Після цього цей ключ буде використовуватись для всіх SSH підключень до цього хоста.
3. Авторизуємось по паролю
Якщо потрібно авторизуватись по паролю, але в системі є ключі, то відповідно клієнт буде перебирати одразу їх, і пароль ввести не запропонує. Щоб це вирішити можна поміняти порядок способів авторизації для данного підключення за допомогою опції PreferredAuthentications, ну і заодно вимкнути про всяк випадок авторизацію по ключу, і увімкнути по паролю:
ssh -o PubkeyAuthentication=no -o PasswordAuthentication=yes -o PreferredAuthentications=password serhii@192.168.124.58
Це ж саме можна налаштувати для цього хоста в файлі ~/.ssh/config:
~/.ssh/configHost 192.168.124.58
PubkeyAuthentication no
PasswordAuthentication yes
PreferredAuthentications password
4. Вказуємо механізм авторизації
Іноді замість механізму авторизації password сервер може використовувати keyboard-interactive. Зазвичай так відбувається, коли для авторизації використовується не пароль користувача Unix, а пароль з якоїсь зовнішньої служби авторизації. Тоді команда описана в попередньому пункті працювати не буде і потрібно замість неї використовувати таку:
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=keyboard-interactive serhii@192.168.124.58
І відповідно налаштування для ~/.ssh/config будуть трохи відрізнятись:
~/.ssh/configHost 192.168.124.58
PubkeyAuthentication no
PreferredAuthentications keyboard-interactive
Що подивитись на сервері?
1. Логи
Якщо у вас є доступ до сервера, фізичний чи в консолі VPS, то перш за все потрібно подивитись там логи авторизації. Для того щоб увімкнути режим відладки для служби ssh потрібно додати таку стрічку в /etc/sshd_config:
LogLevel VERBOSE
Після цього потрібно перезапустити службу:
sudo systemctl restart ssh
За замовчуванням логи пишуться в файл /var/log/auth.log:
2. Права
Права на файл ~/.ssh/authorized_keys мають бути 600:
ls -l ~/.ssh/authorized_keys
Висновки
В цій статті ми розглянули як виправити помилку too many authentication failures та permission denied (publickey) при підключенні по SSH. Я розповів про те як вирішував подібні проблеми коли вони виникали в моїй роботі. Можливо є і інші випадки не описані в статті які призводять до такої помилки. Якщо ви знаєте інші методи вирішення, діліться в коментарях!
