SSH Permission Denied (publickey): справжнє виправлення

О 02:10 деплой помер на рядку, який я набирав тисячу разів: ssh deploy@staging → Permission denied (publickey). Ключ був справний. Пропозиція — ні.

TL;DR: Permission denied (publickey) означає, що сервер відхилив кожен ключ, який запропонував клієнт — вердикт переговорів, не одруківка в паролі. Діагностуйте через ssh -vvv (які ключі пропонувалися) і серверний лог journalctl -u ssh (які ключі відхилено і чому). Потім виправте одну з чотирьох причин: не той користувач, ключа немає в authorized_keys, права надто відкриті, або ssh-rsa-ключ, відкинутий OpenSSH 8.8+. ssh-copy-id запобігає більшості повторів.

$ ssh -T [email protected]
[email protected]: Permission denied (publickey).

Помилка — вердикт, не підказка: усе в пропозиції відхилено.

Чому SSH каже «Permission denied (publickey)»?

Публічна автентифікація — переговори «запропонуй-і-відмови». Клієнт пропонує кожен ключ, який може знайти: ідентичності з агента, з ~/.ssh/config, стандартні імена файлів (id_ed25519, id_rsa) і все, що передано через -i. Сервер звіряє кожну пропозицію з ~/.ssh/authorized_keys цільового акаунта. Коли ніщо не збігається, а парольна автентифікація вимкнена чи вичерпана, клієнт друкує єдиний рядок, який вивчив кожен devops-інженер.

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

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

ssh -vvv deploy@staging 2>&1 | grep -iE "offering|identity|denied|authentications"
# debug1: Offering public key: /home/you/.ssh/id_ed25519 RSA-SHA256 (explicit)
# debug1: Authentications that can continue: publickey
# deploy@staging: Permission denied (publickey).

Читайте три рядки: Offering public key (що запропонував клієнт), Authentications that can continue (що сервер ще прийме — якщо password відсутній, запит пароля вже ніколи не прийде) і фінальний вердикт. Якщо ваш призначений ключ узагалі не з’явився у списку пропозицій, проблема клієнтська: кривий шлях -i, забутий IdentityFile у ~/.ssh/config, або агент (ssh-add -l) зі старою ідентичністю, що відповідає першою.

Які чотири справжні причини?

Причина	Ознака	Виправлення
Не той користувач	Ключ працює для root@host, але падає для deploy@host	Ключ мусить бути в ~/.ssh/authorized_keys того користувача
Ключ не встановлено	У серверному логу Failed publickey на кожну пропозицію	ssh-copy-id user@host
Права надто відкриті	Клієнт: WARNING: UNPROTECTED PRIVATE KEY FILE — ключ пропускається і не пропонується	chmod 700 ~/.ssh; chmod 600 ~/.ssh/*
Легасі ssh-rsa	Сервер на OpenSSH 8.8+; старий RSA-ключ ніколи не приймається	Перегенеруйте в ed25519 або оновіть ключ

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

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519 ~/.ssh/authorized_keys

Причина ssh-rsa ловить старіші CI-образи та Raspberry Pi: OpenSSH 8.8 (випущено 2021-10-01, openssh.com/txt/release-8.8) вимкнув ssh-rsa-підписи — варіант на SHA-1 — за замовчуванням. У примітках релізу: “the ssh-rsa signature scheme is … disabled by default”. RSA-ключ 2018 року не зламаний; його формат підпису просто більше не розмовляється. Генерація ed25519-ключа (ssh-keygen -t ed25519) — довговічна відповідь, а хмарні консолі дають serial console, коли ви зачинили себе надвори посеред ремонту.

Як побачити, чому сервер відхилив ключ?

Серверний лог — чесний свідок. На Ubuntu (systemd) sshd логує вердикт на кожну пропозицію:

journalctl -u ssh -n 50 --no-pager | grep -iE "publickey|denied|accepted"
# sshd[4421]: Failed publickey for deploy from 203.0.113.7 port 51422 ssh2: RSA SHA256:...
# sshd[4421]: Accepted publickey for deploy from 203.0.113.7 port 51422 ssh2: ED25519 SHA256:...

Failed publickey з відбитком, якого ви не чекали, означає, що клієнт запропонував інший ключ, ніж ви думали — назад до -vvv. Failed publickey з вашим відбитком означає, що ключ правильний, але не встановлений для того акаунта, або серверні права домашньої теки криві (те саме правило 700/600 стосується серверних ~/.ssh і ~/.ssh/authorized_keys). Якщо sshd не стартує, поки ви правите конфіги — це інше полювання, дивіться systemd service not starting.

Як правильно встановити свій ключ?

ssh-copy-id deploy@staging
# Number of key(s) added: 1
ssh -o BatchMode=yes deploy@staging 'echo ok'   # неінтерактивний доказ

ssh-copy-id дописує публічний ключ у authorized_keys цільового акаунта і ставить розумні права — він існує тому, що ручне вставляння в authorized_keys падає на зайвому переносі рядка чи відсутній теці саме так часто, щоб це втомлювало. Перевірка BatchMode — справжній тест: вона вимикає всі запити, тож успіх означає, що ключ сам зніс логін. Коли ключ працює, scp і rsync успадковують ту саму автентифікацію задарма — вибір між ними про смугу, а не про креденшели (rsync vs scp).

Тріаж за 30 секунд

ssh -vvv user@host 2>&1 | grep -i offering      # 1. які ключі пропонували?
journalctl -u ssh -n 50 | grep -i publickey     # 2. чому відхилені?
ls -ld ~/.ssh ~/.ssh/authorized_keys            # 3. 700 / 600?
ssh-copy-id user@host                           # 4. встановіть, перевірте через BatchMode

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

Чотири команди по черзі — і збій перестає бути містичним: одна з них називає винуватця щоразу. У моєму випадку була стара ідентичність агента, що відповідала раніше за правильний ключ — ssh-add -d, і деплой позеленів о 02:31.