Усунення помилки SSH Permission Denied (Publickey): покроковий посібник

Повідомлення про помилку «SSH Permission Denied (publickey)» (Відмова в доступі SSH (відкритий ключ)) — це те, з чим стикалися багато з нас, і це справжня перешкода.

Але помилки — це запорука майстерності.

Часто усунення цієї помилки дає вам розуміння управління сервером і конфігурацій мережі, яке ви б інакше не отримали.

Розуміння основних причин і дотримання систематичного підходу допоможе вам відновити доступ до ваших систем.

ЗМІСТ

Поширені причини помилки «Доступ до SSH відмовлено (publickey)»

Попередні перевірки перед усуненням несправностей

Як діагностувати помилку «Доступ до SSH відмовлено (publickey)»

Рішення для усунення помилки «Доступ до SSH відмовлено (publickey)»

Висновок

ПОШИРЕНІ ПРИЧИНИ ПОМИЛКИ «ДОСТУП ДО SSH ВІДМОВЛЕНО (PUBLICKEY)»

Розуміння причин блокування є першим кроком у вирішенні проблеми. Причини можуть бути різними: від простих помилок, таких як помилка в імені користувача або адресі хоста, до більш складних проблем, таких як неправильні дозволи на файли або конфігурації сервера.

1. НЕВІРНЕ ІМ'Я КОРИСТУВАЧА АБО ХОСТ

Однією з найпростіших причин, через яку може виникнути помилка SSH Permission Denied (Publickey), є введення неправильного імені користувача або адреси хоста.

Завжди перевіряйте, чи використовуєте ви правильне ім'я користувача та підключаєтеся до правильної адреси сервера. Невелика помилка може мати велике значення.

2. ВІДСУТНІСТЬ ПУБЛІЧНОГО КЛЮЧА НА СЕРВЕРІ

Протокол SSH використовує для автентифікації пару ключів: публічний ключ і приватний ключ.

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

Переконайтеся, що ваш відкритий ключ був правильно завантажений на сервер.

3. НЕВІРНІ ПРАВА ДОСТУПУ ДЛЯ КЛЮЧІВ І ПАПОК SSH

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

SSH вимагає, щоб тільки користувач мав права на читання файлу приватного ключа, зазвичай ~/.ssh/id_rsa або подібного шляху.

Якщо права доступу встановлені занадто широко, тобто інші користувачі можуть читати або змінювати ваш приватний ключ, SSH вважатиме це ризиком для безпеки і відмовить у доступі. Ви можете встановити правильні права доступу за допомогою команди chmod в системах на базі UNIX, гарантуючи, що ваші приватні та відкриті ключі доступні тільки вам.

4. КОНФІГУРАЦІЇ СЛУЖБИ SSH

Нарешті, може бути проблема з конфігураціями SSH сервера. Ці налаштування зберігаються у файлі конфігурації, зазвичай у /etc/ssh/sshd_config на сервері.

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

Якщо щось у цьому файлі невірно, це може призвести до помилки SSH Permission Denied (Publickey).

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

ПОПЕРЕДНІ ПЕРЕВІРКИ ПЕРЕД УСУНЕННЯМ НЕСПРАВНОСТЕЙ

Важливо виконати деякі базові перевірки, перш ніж заглиблюватися в більш складні причини помилки SSH Permission Denied (Publickey).

Часто проблему можна вирішити, підтвердивши деякі прості, але важливі деталі. Ось попередні перевірки, які слід виконати, перш ніж продовжувати усунення несправностей:

1. ПЕРЕКОНАЙТЕСЯ, ЩО ВИ ПІДКЛЮЧАЄТЕСЯ ДО ПРАВИЛЬНОГО СЕРВЕРА ТА ПОРТУ

Переконайтеся, що ви підключаєтеся до правильної IP-адреси або доменного імені сервера. Крім того, SSH за замовчуванням працює на порту, зазвичай порту 22. Переконайтеся, що ви підключаєтеся до правильного порту; якщо ваш сервер використовує інший порт для SSH, вам потрібно буде вказати його в команді підключення.

Щоб підключитися до певного порту, ви можете використовувати опцію -p у команді SSH, як показано нижче:

ssh username@hostname -p port_number

2. ПЕРЕВІРТЕ, ЧИ ПРАЦЮЄ СЛУЖБА SSH

Ще одна важлива перевірка — переконатися, що служба SSH працює на сервері. Якщо ні, ви не зможете підключитися, що б ви не робили. Якщо у вас є доступ до сервера, ви можете перевірити стан служби SSH, виконавши таку команду:

У системі на базі Systemd (наприклад, Ubuntu):

sudo systemctl status sshd

У системі на базі Init:

sudo service ssh status

Якщо служба не працює, зазвичай її можна запустити за допомогою:

У системі на базі Systemd:

sudo systemctl start sshd

У системі на базі Init:

sudo service ssh start

3. ПЕРЕВІРКА ІМЕНІ КОРИСТУВАЧА

Переконайтеся, що ви використовуєте правильне ім'я користувача для сервера, до якого намагаєтеся підключитися. Неправильне ім'я користувача призведе до помилки автентифікації.

Якщо ви не впевнені в імені користувача і маєте доступ до сервера, зазвичай можна знайти список облікових записів користувачів, переглянувши файл /etc/passwd або виконавши команду getent passwd.

Ці кроки є надійною відправною точкою для процесу усунення несправностей.

ЯК ДІАГНОСТУВАТИ ПОМИЛКУ «SSH PERMISSION DENIED (PUBLICKEY)»

Коли ви стикаєтеся з помилкою SSH permission denied (publickey), знання того, як діагностувати проблему, є половиною успіху.

1. ВИКОРИСТАННЯ SSH З -V (ОПЦІЯ VERBOSE)

Опція -v з командою SSH забезпечує детальний вивід, показуючи детальні кроки, які SSH виконує під час процесу підключення. Це надзвичайно корисно для точного визначення місця, де процес завершується невдало. Щоб скористатися цією опцією, відкрийте термінал і введіть:

ssh -v username@hostname

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

2. ВИЯВЛЕННЯ ТА ПЕРЕВІРКА ФАЙЛІВ ЖУРНАЛІВ SSH

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

Журнали часто зберігаються в /var/log/auth.log в Ubuntu та інших системах на базі Debian або в /var/log/secure в CentOS та інших системах на базі Red Hat.

Щоб перевірити ці журнали, скористайтеся командами cat або tail:

sudo cat /var/log/auth.log

або

sudo tail -f /var/log/auth.log

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

3. ПЕРЕВІРКА ВІДКРИТОГО КЛЮЧА НА СЕРВЕРІ

Наступним кроком є перевірка, чи знаходиться ваш відкритий ключ там, де він повинен бути на сервері. Ключ зазвичай знаходиться у файлі в каталозі ~/.ssh/ користувача, під ім'ям якого ви намагаєтеся увійти, і зазвичай має назву authorized_keys.

Ви можете перевірити вміст цього файлу за допомогою команди:

cat ~/.ssh/authorized_keys

РІШЕННЯ ДЛЯ ВИПРАВЛЕННЯ ПОМИЛКИ «SSH PERMISSION DENIED (PUBLICKEY)»

Нарешті, настав час розглянути рішення.

1. ВИПРАВЛЕННЯ ІНФОРМАЦІЇ ПРО ІМ'Я КОРИСТУВАЧА ТА ХОСТ

Почніть з подвійної перевірки імені користувача та імені хоста або IP-адреси сервера. Описки або застаріла інформація призводять до цієї помилки.

Перевірте облікові дані та спробуйте підключитися знову.

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

2. ДОДАННЯ ВАШОГО ПУБЛІЧНОГО КЛЮЧА ДО ФАЙЛУ AUTHORIZED_KEYS СЕРВЕРА

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

Ви можете вручну додати свій відкритий ключ до цього файлу за допомогою утиліти ssh-copy-id або додавши його вручну:

ssh-copy-id username@hostname

Або вручну:

echo'your_public_key' >> ~/.ssh/authorized_keys

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

3. ВИПРАВЛЕННЯ ПРАВ ДОСТУПУ ДО ФАЙЛІВ І КАТАЛОГІВ

Неправильні права доступу також можуть спричинити цю помилку. Переконайтеся, що ваш приватний ключ доступний для читання тільки вам і що ваш каталог .ssh має правильні права доступу. Ви можете встановити їх за допомогою команди chmod:

chmod 600 ~/.ssh/id_rsa

chmod 644 ~/.ssh/id_rsa.pub

chmod 700 ~/.ssh

4. НАЛАШТУВАННЯ КОНФІГУРАЦІЙ SSH (SSHD_CONFIG)

Якщо ви маєте root-доступ до сервера, можливо, вам доведеться заглибитися в файл конфігурації демона SSH (/etc/ssh/sshd_config).

Переконайтеся, що такі параметри, як PermitRootLogin та PasswordAuthentication, налаштовані відповідно до ваших потреб. Після внесення змін перезапустіть службу SSH:

sudo systemctl restart sshd

5. ПОВТОРНЕ СТВОРЕННЯ ТА ПОВТОРНЕ РОЗМІЩЕННЯ КЛЮЧІВ SSH

Якщо все інше не допомагає, можливо, ваш ключ пошкоджено. У цьому випадку створіть нові ключі SSH та додайте новий відкритий ключ до вашого сервера.

ssh-keygen -t rsa

ssh-copy-id username@hostname

6. УМОВИ АВТЕНТИФІКАЦІЇ ЗА ПАРОЛЕМ

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

Щоб увімкнути аутентифікацію за паролем, вам потрібно змінити файл конфігурації демона SSH, який зазвичай знаходиться в /etc/ssh/sshd_config. Відкрийте цей файл у текстовому редакторі з правами суперкористувача:

sudo nano /etc/ssh/sshd_config

Знайдіть рядок PasswordAuthentication і змініть його значення на yes:

PasswordAuthentication yes

Якщо рядок закомментований (починається з #), видаліть #, щоб скасувати коментар. Збережіть зміни та закрийте редактор. Нарешті, перезапустіть службу SSH, щоб застосувати нові налаштування:

sudo systemctl restart sshd

Тепер ви повинні мати можливість увійти, використовуючи своє ім'я користувача та пароль.

Однак увімкнення аутентифікації за допомогою пароля піддає ваш сервер потенційним атакам методом грубої сили. Тому це має бути тимчасовим заходом, доки ви не вирішите проблеми, пов'язані з аутентифікацією за допомогою відкритого ключа.

ВИСНОВОК

Вирішення проблеми з відмовою в доступі SSH (publickey) є життєво важливим для забезпечення безпечного та безперебійного доступу до вашого сервера.

Ігнорування або обхід цієї проблеми перериває ваш робочий процес і створює ризик для безпеки.

Ми сподіваємося, що цей посібник буде корисним для діагностики та вирішення цієї поширеної, але вирішуваної проблеми.