Як виправити SSH Permission denied (publickey)

Що насправді означає Permission denied (publickey)

Permission denied (publickey) означає, що клієнт надіслав один або кілька відкритих ключів, але сервер не прийняв жодного з них. Мережа працює, а sshd запущений: відмова відбувається на останньому етапі автентифікації. Виправлення не потребує припущень, оскільки ssh -v показує, яка з п’яти причин має місце.

Тексти в дужках — це методи, які сервер готовий приймати. Permission denied (publickey) саме по собі означає, що вхід за паролем на цьому сервері вимкнено, тому використати пароль як запасний варіант неможливо. Permission denied (publickey,password) означає, що пароль був доступний, але автентифікацію за ним також не пройдено.

Одне повідомлення охоплює п’ять окремих проблем і навмисно залишається нечітким. Сервер, який відповідав би «такого користувача немає» або «цей ключ не встановлено», допомагав би всім, хто шукає дійсні облікові записи. Тому не починайте навмання змінювати ключі та редагувати конфігураційні файли. Виконайте одну команду, прочитайте три рядки виводу — і п’ять можливих причин звузяться до однієї.

Спочатку виконайте ssh -v і прочитайте три рядки

Повторіть команду, яка завершилася помилкою, додавши -v:

ssh -v deploy@203.0.113.10

Скорочений, але реалістичний результат має такий вигляд:

OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22.
debug1: Connection established.
debug1: Authenticating to 203.0.113.10:22 as 'deploy'
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
deploy@203.0.113.10: Permission denied (publickey).

У цих трьох рядках є вся потрібна інформація.

Authenticating to 203.0.113.10:22 as 'deploy' — це ім’я користувача, яке фактично буде використано. Не те, яке ви планували використати, а те, яке ssh визначив із командного рядка, ~/.ssh/config або імені локального користувача.

Authentications that can continue: publickey — це список методів автентифікації, які сервер приймає. Сервер надсилає його до спроби використати будь-який ключ. Якщо publickey відсутній у цьому першому списку, на сервері вимкнено вхід за відкритим ключем, тому жоден ключ не спрацює.

Offering public key: ... — це окремий рядок для кожного ключа, який клієнт фактично надіслав. У ньому вказано файл, з якого походить ключ, і його відбиток SHA256. Якщо для ключа немає рядка Offering, клієнт не надсилав його серверу.

Тепер розділіть проблему на дві частини:

• Для ключа, який ви очікуєте, немає рядка Offering public key. Проблема на вашому комп’ютері, оскільки сервер взагалі не отримав ваш ключ.
• Ключ запропоновано, але у відповідь знову з’являється Authentications that can continue: publickey. Сервер отримав цей ключ і відхилив його, тому проблема на сервері.

Наведені нижче причини впорядковано за частотою, з якою вони виявляються відповіддю.

Причина 1: ви підключаєтеся під неправильним іменем користувача

Найпоширеніша причина водночас є найменш цікавою. sshd, демон SSH (secure shell), ніколи не повідомляє, що облікового запису не існує. Він виконує весь обмін для вигаданого імені користувача, а наприкінці відхиляє підключення з тим самим повідомленням, оскільки розкриття дійсних імен облікових записів допомагає зловмиснику. Помилка в імені користувача виглядає так само, як несправний ключ.

Спочатку перевірте рядок Authenticating to ... as. Якщо в ньому вказано ім’я для входу на вашому ноутбуці, а не обліковий запис на сервері, ви не вказали ім’я користувача в команді.

ssh -v deploy@203.0.113.10
ssh -v root@203.0.113.10

Обліковий запис за замовчуванням залежить від образу, який створює ваш провайдер. Станом на August 2026 в образах Ubuntu зазвичай використовується обліковий запис ubuntu, в образах Debian — debian або admin, у Rocky Linux і AlmaLinux — rocky та almalinux, а багато VPS-провайдерів натомість одразу встановлюють ваш ключ у root. У панелі керування провайдера зазначено, який обліковий запис він створив. Жодна команда, виконана за межами сервера, не може запитати цю інформацію в нього.

Блок Host у ~/.ssh/config також задає ім’я користувача, і це значення має пріоритет над вашим локальним іменем для входу:

Host vps-prod
  HostName 203.0.113.10
  User deploy

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

Причина 2: ключ, який, на вашу думку, передається, відрізняється від ключа, що фактично передається

За замовчуванням ssh пропонує лише ключі, які зберігаються в ssh-agent, а також фіксований набір файлів у ~/.ssh: id_ed25519, id_ecdsa, id_rsa і апаратні та DSA-варіанти цих імен. Ключ, збережений як ~/.ssh/vps-prod, невидимий для ssh, доки ви явно не вкажете його. Тому докладний вивід не містить для нього рядка Offering public key.

Укажіть файл і забороніть ключам агента підміняти його:

ssh -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@203.0.113.10

Самого -i недостатньо, якщо агент зберігає ключі, оскільки ssh спочатку пропонує ключі агента, а вказаний файл — останнім. Це важливо, оскільки сервер зараховує кожен відхилений ключ до MaxAuthTries, значення якого за замовчуванням становить 6. Агент із сімома ключами може вичерпати ліміт до того, як буде запропоновано правильний ключ. Тоді повідомлення змінюється на:

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

IdentitiesOnly=yes обмежує спробу файлом, який ви вказали. Перегляньте ключі, що зберігаються в агенті, за допомогою ssh-add -l, а якщо агент накопичив старі ключі за кілька років, очистьте їх командою ssh-add -D. Потім збережіть ці параметри в конфігурації, щоб під час наступного входу не довелося згадувати прапорці:

Host vps-prod
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/vps-prod
  IdentitiesOnly yes

Є ще одна проблема на стороні клієнта. ssh відмовляється використовувати приватний ключ, який можуть читати інші облікові записи на вашому комп’ютері. Він виводить попередження, а потім ігнорує ключ. Тому ключ не передається, і сервер його не отримує:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/vps-prod' are too open.

chmod 600 ~/.ssh/vps-prod виправляє це. Права доступу часто втрачаються, коли ключ переносять через USB-накопичувач або спільний ресурс Windows. Розташування ключів і правила їх іменування описано в розділі Основи керування ключами SSH.

Причина 3: відкритий ключ не потрапив до authorized_keys

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

sudo ls -l /home/deploy/.ssh/
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

Команда ssh-keygen -lf для файлу authorized_keys виводить відбиток для кожного запису:

256 SHA256:0eL/8sBw... you@laptop (ED25519)
3072 SHA256:9Tq2yZk... old-laptop (RSA)

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

Ось чотири поширені причини помилки:

• Ви вставили приватний ключ замість файлу .pub. Рядок відкритого ключа починається з ssh-ed25519 або ssh-rsa. Приватний ключ починається з -----BEGIN OPENSSH PRIVATE KEY-----.
• Під час вставлення ключ було перенесено на кілька рядків. Кожен запис має міститися рівно в одному рядку. Перенесений ключ буде прочитано як кілька пошкоджених записів, і жоден із них не збігатиметься.
• Ключ потрапив до /root/.ssh/authorized_keys, а ви входите як deploy, або навпаки. Файл належить конкретному обліковому запису. Спільного файла немає.
• Поле провайдера «додати мій ключ» записало ключ лише для користувача, установленого за замовчуванням в образі. Тому обліковий запис, який ви створили пізніше, має порожній каталог .ssh.

Безпечний спосіб додати ключ через консоль від імені root:

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo tee -a /home/deploy/.ssh/authorized_keys >/dev/null <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere you@laptop
EOF
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

Після цього знову виконайте sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys. Новий відбиток має з’явитися у списку. З машини, на якій ще можна ввійти за паролем, ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 виконує ту саму операцію та правильно встановлює права доступу.

Причина 4: чому sshd ігнорує authorized_keys, якщо права доступу надто широкі

StrictModes yes — стандартне значення sshd. За цього значення sshd відмовляється читати authorized_keys, якщо цей файл, каталог .ssh або домашній каталог облікового запису доступні для запису будь-кому, крім власника. Причина проста: якщо група або всі інші користувачі можуть записувати у ваш домашній каталог, будь-який обліковий запис із таким доступом може замінити authorized_keys і перехопити вхід до системи. sshd розглядає недовірений шлях так, ніби ключа не існує.

Клієнт бачить звичайне повідомлення Permission denied. Журнал сервера містить справжню причину:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh

або, якщо проблема саме у файлі:

Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys

Що приймає sshd:

• Домашній каталог: без права запису для групи та без права запису для всіх інших користувачів. 755, 750 і 700 проходять перевірку. 775 і 777 не проходять.
• ~/.ssh: режим 700.
• ~/.ssh/authorized_keys: режим 600.
• Власник: усі три об’єкти мають належати обліковому запису, під яким ви входите в систему, а не root.

Власник має таке саме значення, як і режим доступу. Файл у /home/deploy/.ssh, власником якого є root, не проходить цю саму перевірку. Таке трапляється, коли ви створюєте його за допомогою sudo nano і забуваєте змінити власника назад. Виправте обидві властивості одразу:

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
ls -ld /home/deploy /home/deploy/.ssh

Остання команда показує результат. Для домашнього каталогу потрібно отримати drwxr-xr-x або суворіші права, а для .ssh — drwx------. Якщо ці рядки поки що незрозумілі, прочитайте як читати рядок прав доступу на кшталт drwxr-xr-x, перш ніж змінювати права на робочому сервері.

У Rocky Linux і AlmaLinux додайте SELinux (security-enhanced Linux) до переліку можливих причин. Каталог .ssh, створений нестандартним способом, може мати неправильну мітку файлу. Через це sshd не отримує доступу на читання, навіть якщо режими доступу правильні. sudo restorecon -Rv /home/deploy/.ssh відновлює мітки, а sudo ausearch -m avc -ts recent показує, чи саме SELinux відмовив у доступі.

Причина 5: sshd налаштований так, щоб відмовляти вам

Читання /etc/ssh/sshd_config недостатньо в сучасній системі Ubuntu або Debian. Цей файл починається з Include /etc/ssh/sshd_config.d/*.conf, а OpenSSH використовує перше знайдене значення для кожного параметра. Тому drop-in-файл, наприклад 50-cloud-init.conf, читається першим і має пріоритет над усіма змінами нижче в основному файлі. Через це зміна може виглядати правильною, але взагалі нічого не змінювати.

Перевірте фактичну конфігурацію, яку використовує sshd:

sudo sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|permitrootlogin|allowusers|allowgroups|denyusers'

Коректна відповідь має такий вигляд:

permitrootlogin prohibit-password
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

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

• pubkeyauthentication no. Жоден ключ ніколи не буде прийнято. Це також відображається в ssh -v як перший список Authentications that can continue: без publickey.
• authorizedkeysfile вказує на інший шлях, наприклад /etc/ssh/authorized_keys/%u. Файл у домашньому каталозі повністю ігнорується, а правила режиму доступу з причини 4 застосовуються до нового шляху.
• Наявний allowusers або allowgroups. Будь-якому обліковому запису, якого немає у списку, буде відмовлено з точно такою помилкою без пояснення. denyusers і denygroups працюють так само, але навпаки.
• permitrootlogin no, якщо ви намагаєтеся ввійти як root. prohibit-password — практичне проміжне значення: root може використовувати ключ, але не пароль.

Блоки Match не відображаються у звичайному sshd -T, оскільки їхній результат залежить від того, хто підключається. Перевірте параметри для конкретного підключення:

sudo sshd -T -C user=deploy,host=vps.example.com,addr=198.51.100.7

Ще один параметр впливає на старі ключі. Починаючи з OpenSSH 8.8, підписи SHA-1 (ssh-rsa) за замовчуванням більше не приймаються. Тому RSA-ключ, який працював роками, може перестати працювати одразу після оновлення сервера. Клієнт прямо повідомляє про це:

debug1: send_pubkey_test: no mutual signature algorithm

Правильне виправлення — створити новий ключ: ssh-keygen -t ed25519 -C "deploy@vps-prod", а потім встановити файл .pub, як показано вище. Параметр PubkeyAcceptedAlgorithms +ssh-rsa на сервері знову дозволяє старі підписи й дає змогу увійти сьогодні. Тому використовуйте його як тимчасовий спосіб отримати доступ до сервера, а не як остаточне рішення. Інші параметри сервера, які варто переглянути, описано в розділі посилення захисту SSH-сервера на VPS.

Як довести, що приватний ключ відповідає встановленому відкритому ключу

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

ssh-keygen -y -f ~/.ssh/vps-prod

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

ssh-keygen -lf ~/.ssh/vps-prod.pub
ssh-add -l

Перша команда виводить відбиток одного файлу відкритого ключа. Друга виводить відбитки ключів, які зберігає ваш агент. Порівняйте чотири представлення одного й того самого рядка: відбиток у рядку Offering public key з ssh -v, відбиток вашого файлу .pub, відбитки у ssh-keygen -lf на сервері в authorized_keys і відбиток у журналі сервера. Місце, де вони перестають збігатися, вказує на вашу помилку.

Переглядайте журнал сервера під час невдалої автентифікації

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

sudo journalctl -u ssh -f

Ubuntu 24.04 не встановлює rsyslog за замовчуванням, тому /var/log/auth.log може бути відсутнім. У Rocky Linux і AlmaLinux unit називається sshd, а ті самі записи також потрапляють до /var/log/secure.

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

Failed publickey for deploy from 198.51.100.7 port 49812 ssh2: ED25519 SHA256:0eL/8sBw...

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

Якщо журнал і далі не дає чіткої відповіді, запустіть другий екземпляр sshd на іншому порту в режимі налагодження. Він працює у foreground, обслуговує одне з’єднання, виводить пояснення своїх дій, а потім завершує роботу:

sudo /usr/sbin/sshd -ddd -p 2222

У консольному сеансі на тому самому сервері підключіться до нього через loopback-адресу:

ssh -p 2222 -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@127.0.0.1

Підключення через 127.0.0.1 не залучає firewall до перевірки. Вивід налагодження містить ім’я відкритого файла, fingerprint, з яким виконувалося порівняння, і точну причину відмови, зокрема такі рядки, як Authentication refused: bad ownership or modes for directory /home/deploy. Натисніть Ctrl+C, коли отримаєте відповідь. Робота основного sshd на порту 22 протягом усієї перевірки не змінюється.

Як не заблокувати собі доступ

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

1. Відкрийте консоль провайдера через serial або VNC (virtual network computing) і переконайтеся, що можете увійти до неї.
2. Переконайтеся, що знаєте робочий локальний пароль для облікового запису з правами sudo. Якщо такого пароля немає, спочатку скиньте пароль root через консоль провайдера.
3. Не закривайте поточний сеанс SSH. Відкритий сеанс переживає systemctl restart ssh, тому він залишиться способом повторно підключитися, якщо нова конфігурація виявиться неправильною.
4. Перевірте синтаксис перед перезапуском: sudo sshd -t не виводить нічого, якщо файл правильний, і виводить файл та номер рядка, якщо в ньому є помилка.
5. Відкрийте другий термінал і виконайте новий вхід, перш ніж закривати перший. Неправильна конфігурація блокує нові входи, але не перериває наявні сеанси, тому поточний сеанс не дає змоги перевірити, чи спрацювала зміна.

Виконайте перезапуск за допомогою sudo systemctl restart ssh у Debian та Ubuntu або sudo systemctl restart sshd у Rocky Linux та AlmaLinux. В Ubuntu 24.04 sshd запускається з socket unit, тому після зміни Port або ListenAddress також потрібно виконати sudo systemctl restart ssh.socket, перш ніж зміна набуде чинності.

FAQ

Чому я отримую Permission denied (publickey), якщо той самий ключ працює на іншому сервері?

Тому що з ключем усе гаразд, а проблема пов’язана з його оточенням. Виконайте ssh -v і знайдіть рядок Offering public key. Якщо вашого ключа немає у списку, ssh його не надсилав: файл не має стандартного імені в ~/.ssh і не завантажений в агент. Додайте його за допомогою -i /path/to/key -o IdentitiesOnly=yes. Якщо ключ є у списку, але сервер усе одно відмовляє, цей ключ відсутній у authorized_keys облікового запису, шлях до нього доступний для запису групі, або конфігурація sshd блокує користувача. Журнал сервера дає змогу розрізнити ці випадки.

Як дізнатися, який ключ SSH фактично надсилає?

ssh -v host виводить один рядок debug1: Offering public key: для кожного ключа. У кожному рядку вказано вихідний файл і відбиток SHA256. ssh-add -l виводить відбитки ключів, які зберігає агент. ssh-keygen -lf ~/.ssh/id_ed25519.pub виводить відбиток окремого файлу ключа, а ssh-keygen -y -f ~/.ssh/id_ed25519 виводить відкритий ключ, який фактично відповідає приватному ключу. Щоб вхід був успішним, відбиток із рядка Offering також має бути присутнім у результаті ssh-keygen -lf, виконаного для authorized_keys сервера.

Чому sshd ігнорує мій файл authorized_keys?

Тому що StrictModes увімкнено за замовчуванням, а файл, каталог .ssh або домашній каталог доступні для запису групі чи всім користувачам або належать неправильному обліковому запису. sshd не довіряє шляху, який може змінити інший користувач, тому працює так, ніби ключа не існує. Встановіть для домашнього каталогу права 755 або суворіші, для .ssh — 700, а для authorized_keys — 600. Усі три об’єкти мають належати обліковому запису для входу. За допомогою LogLevel VERBOSE сервер записує Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

Мій ключ перестав працювати одразу після оновлення сервера. Що змінилося?

Якщо це RSA-ключ, найімовірніша причина — зміна, пов’язана із SHA-1. OpenSSH 8.8 за замовчуванням вимкнув ssh-rsa підписи SHA-1, тому ключ, який може підписувати лише таким способом, тепер відхиляється. Докладний вивід клієнта містить debug1: send_pubkey_test: no mutual signature algorithm. Створіть сучасний ключ за допомогою ssh-keygen -t ed25519 і встановіть його файл .pub. Якщо доступ потрібен негайно, PubkeyAcceptedAlgorithms +ssh-rsa на сервері знову вмикає старі підписи. Після того як новий ключ запрацює, цей рядок слід видалити.

Я відредагував sshd_config і тепер узагалі не можу ввійти. Як відновити доступ?

Скористайтеся консоллю вашого провайдера, яка не використовує SSH. Увійдіть до неї за допомогою локального пароля, виконайте sudo sshd -t, щоб побачити синтаксичну помилку та номер її рядка, скасуйте зміну й перезапустіть службу. Потім перевірте sudo sshd -T, щоб підтвердити активні значення, оскільки файл у /etc/ssh/sshd_config.d/ може перевизначати основну конфігурацію. Якщо локального пароля немає, спочатку скиньте пароль root через консоль, а потім виправте файл.