Проверка публичного ключа SSH

Проверяется устройство самого ключа. Тип в начале строки должен совпадать с типом, записанным внутри тела, base64 — декодироваться, длины полей — сходиться, а у каждого типа должны быть все обязательные части: 32 байта открытого ключа у Ed25519, экспонента и модуль у RSA, имя кривой и точка у ECDSA.

Чего страница знать не может: примет ли ключ ваш сервер, какие права стоят на файлах, в тот ли файл он положен и подходит ли к нему ваш приватный ключ. Не все невидимые символы она замечает: неразрывный пробел здесь читается как обычный, хотя сервер на нём спотыкается. Как проверить всё это самому, написано ниже.

• Алгоритм — первое слово ключа. ssh-ed25519 и ssh-rsa — обычные ключи, ecdsa-sha2-nistp256 и соседние — ECDSA на кривых NIST, а всё, что начинается с sk-, живёт на аппаратном ключе FIDO.
• Длина — в битах, прочитанная из самого ключа. У Ed25519 она всегда 256, у RSA — та, что задали при создании.
• Комментарий — хвост строки, обычно имя@компьютер. Это подпись для людей: на вход он не влияет и с именем пользователя на сервере не связан.
• Отпечаток — короткое имя ключа. Его печатает ssh-keygen -lf, и его же сервер пишет в журнал при удачном входе: Accepted publickey for … ssh2: ED25519 SHA256:…. Совпали отпечатки — это один и тот же ключ.
• Примечание под оценкой появляется, когда вставлен блок SSH2 (для authorized_keys его надо перевести в одну строку) или когда ключей несколько.

Если вместо буквы стоит прочерк, причина написана рядом. Что обычно за ней стоит:

• «Длины полей не сходятся с размером» — ключ разорван: в середину base64 попал перенос строки или пробел. Так бывает, когда ключ копируют из письма, мессенджера или документа, где длинная строка переносится.
• «Тип в строке (…) не совпадает с типом внутри ключа (…)» — начало одного ключа склеено с телом другого или первое слово исправили руками.
• «Ключ неполный» — строку обрезали при копировании. Такой обрывок часто выглядит правдоподобно: первое поле говорит ssh-ed25519, длины сходятся. Ранняя версия этой страницы ставила ему A, теперь состав полей сверяется с типом.
• «Не нашлось типа ключа» — вставлен не ключ: например, отпечаток SHA256:… или путь к файлу вместо его содержимого.
• Предупреждение о приватном ключе — вставлен приватный ключ или файл PuTTY .ppk. Он не обрабатывается, поле сразу очищается.

• A — Ed25519, Ed25519 на аппаратном ключе, ECDSA на P-384 или P-521, RSA от 3072 бит.
• B — RSA-2048, ECDSA на P-256. Сегодня приемлемо, запаса на завтра не осталось.
• C — RSA от 1024 до 2047 бит. Ниже нынешнего порога, часть серверов такой ключ уже не принимает.
• D — всё, что короче, и DSA любой длины. Поддержку DSA OpenSSH удалил целиком в 10.0.

Длина читается из самого ключа, а не угадывается по типу: у RSA модуль измеряется побитово, без ведущего нулевого байта, который добавляет формат при поднятом старшем бите. Поэтому число здесь совпадает с ssh-keygen -lf, а не с округлённой догадкой.

Клиенту сервер отвечает одинаково — Permission denied (publickey). Подробности, если они есть, он пишет в свой журнал (journalctl или /var/log/auth.log, смотря по системе). О неверных правах там будет прямая строка, а об испорченной строке ключа обычно ничего: для сервера это просто ключ, которого нет в списке.

Поведение OpenSSH, описанное ниже, мы проверили сами в сентябре 2026 года: сервер — на OpenSSH 10.3 (Alpine Linux), клиент и ssh-keygen — на 10.2 (macOS) и 10.3. Что делают Windows и PowerShell, мы не проверяли: это пересказ документации Microsoft.

Права на ~/.ssh и authorized_keys

Сервер не читает authorized_keys, если его может изменить кто-то, кроме владельца: вдруг ключ подложили. Смотрит он на сам файл, на каталог ~/.ssh и на домашний каталог. У нас вход не прошёл при правах 775 на ~/.ssh, 664 на authorized_keys и 775 на домашнем каталоге, а в журнале появилась строка Authentication refused: bad ownership or modes for directory /home/….

Права 755 и 644 сервер принимает — ему важно лишь, чтобы писать мог только владелец. Проще всего сразу закрыть лишнее:

chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

У клиента то же требование к приватному ключу. Файл, который могут читать другие, ssh не использует: пишет WARNING: UNPROTECTED PRIVATE KEY FILE! и Permissions 0644 … are too open и пробует войти без этого ключа. Лечится командой chmod 600 ~/.ssh/id_ed25519.

На Windows-сервере со встроенным OpenSSH своя ловушка — так описывает её Microsoft. Для пользователей из группы администраторов ключи читаются не из C:\Users\имя\.ssh\authorized_keys, а из C:\ProgramData\ssh\administrators_authorized_keys, и доступ к этому файлу должен быть только у администраторов и SYSTEM.

Переводы строк CRLF и кодировка

Windows-переводы строк в файле .pub и в authorized_keys нашей проверке не помешали: вход прошёл, ssh-keygen -lf ключ прочитал. Эта страница CRLF тоже понимает.

Ломают они приватный ключ в формате OpenSSH — тот, что начинается с -----BEGIN OPENSSH PRIVATE KEY-----. С CRLF, как и без перевода строки в самом конце файла, ssh пишет Load key "…": invalid format (в сборках с OpenSSL — error in libcrypto) и продолжает без этого ключа. Починить можно так:

(umask 077; tr -d '\r' < ~/.ssh/id_ed25519 > ~/.ssh/id_ed25519.new)
mv ~/.ssh/id_ed25519.new ~/.ssh/id_ed25519

Если в конце не хватает перевода строки, допишите его: echo >> ~/.ssh/id_ed25519. Conchshell 2.17.1 приводит CRLF в приватном ключе к обычным переводам строк сам.

Хуже CRLF кодировка. В Windows PowerShell 5.1 операторы > и >> пишут файл в UTF-16, и строку echo ключ >> authorized_keys сервер не прочтёт. Метка BOM, которую там же добавляет -Encoding UTF8, портит первую строку файла: ключ, стоящий в ней, у нас не сработал. Сохраняйте authorized_keys в UTF-8 без BOM.

Лишние пробелы и переносы

Правило authorized_keys простое: один ключ — одна строка. Пробелы в начале строки и несколько пробелов или табуляция между частями ключа не мешают. Мешает перенос строки или пробел внутри base64: сервер молча не находит ключ, а эта страница сообщает, что длины полей не сходятся.

Коварнее всего неразрывный пробел. Его подставляют мессенджеры, почтовые программы и текстовые редакторы, на глаз он неотличим от обычного, но sshd такую строку не читает — а эта страница его не замечает и поставит ключу оценку как ни в чём не бывало. Поэтому ключ лучше брать прямо из файла командой cat ~/.ssh/id_ed25519.pub, а на сервер отправлять командой, которая ничего не перепечатывает:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host

Что сервер видит в файле, проверяется на самом сервере: ssh-keygen -lf ~/.ssh/authorized_keys печатает отпечаток каждого ключа, который смог прочитать, а испорченные строки молча пропускает. Отпечатков меньше, чем ключей в файле, — ищите сломанную строку.

Ключ в формате PuTTY

Приватный ключ PuTTY — файл .ppk, который начинается строкой PuTTY-User-Key-File-3 или PuTTY-User-Key-File-2. OpenSSH его не понимает и отвечает Load key "key.ppk": invalid format или error in libcrypto: unsupported. Эта страница считает .ppk приватным ключом и не обрабатывает его.

Публичный ключ, сохранённый в PuTTYgen кнопкой «Save public key», — это многострочный блок ---- BEGIN SSH2 PUBLIC KEY ---- в формате RFC 4716. Страница его прочтёт, а OpenSSH в authorized_keys — нет: с таким блоком вход у нас не прошёл. В одну строку его переводит ssh-keygen -i -f key.pub, а в самом PuTTYgen готовая строка лежит в поле «Public key for pasting into OpenSSH authorized_keys file».

Перевести ключ в формат OpenSSH целиком можно через меню Conversions → Export OpenSSH key или консольным puttygen из пакета PuTTY:

puttygen key.ppk -O private-openssh -o ~/.ssh/id_ed25519
puttygen key.ppk -O public-openssh -o ~/.ssh/id_ed25519.pub

Conchshell читает .ppk версий 2 и 3 напрямую, в том числе с парольной фразой, так что для него переводить ключ не нужно.

ssh-rsa, SHA-1 и серверы, которые его отключили

Слово ssh-rsa в начале строки — это тип ключа, а не способ подписи. В OpenSSH 8.8 (сентябрь 2021 года) по умолчанию выключили подписи ssh-rsa, то есть RSA с SHA-1, но сами RSA-ключи работают дальше: подписи для них делаются через rsa-sha2-256 или rsa-sha2-512, которые OpenSSH умеет с версии 7.2. Поэтому оценка здесь зависит от длины RSA-ключа, а не от слова ssh-rsa.

Когда сервер «отключил ssh-rsa», ключ обычно менять не нужно: у нас RSA-ключ вошёл на OpenSSH 10.3 с настройками по умолчанию, а отказ получила только принудительная подпись SHA-1. Проблема появляется, когда одна из сторон старая и умеет только SHA-1 — например, сервер на OpenSSH старше 7.2. Тогда новый клиент пишет no matching host key type found. Their offer: ssh-rsa или просто Permission denied (publickey).

Обходной путь — разрешить SHA-1 только для этого сервера, а не для всех:

Host old-server
  HostName old.example.com
  HostKeyAlgorithms +ssh-rsa
  PubkeyAcceptedAlgorithms +ssh-rsa

До OpenSSH 8.5 вторая директива называлась PubkeyAcceptedKeyTypes, и новые версии понимают старое имя. Настоящее решение — обновить сервер и перейти на Ed25519.

Онлайн-проверка приватного ключа — private key checker — плохая идея на любом сайте, включая этот: приватный ключ не должен покидать вашу машину. Всё, что обычно хотят о нём узнать, проверяется одной командой у себя в терминале:

ssh-keygen -y -f ~/.ssh/id_ed25519

Она читает приватный ключ, спрашивает парольную фразу, если ключ зашифрован, и печатает его публичную половину. Напечатала — значит файл цел, OpenSSH понимает формат, права в порядке и фраза верна. Если нет, причина будет в ответе:

• bad permissions вместе с UNPROTECTED PRIVATE KEY FILE! — файл доступен другим, нужен chmod 600;
• invalid format или error in libcrypto — CRLF, нет перевода строки в конце, ключ PuTTY или обрезанный файл;
• incorrect passphrase supplied to decrypt private key — неверная парольная фраза.

Та ли это пара, видно по отпечатку. Команда ниже считает отпечаток публичной половины, вычисленной из приватного ключа:

ssh-keygen -y -f ~/.ssh/id_ed25519 | ssh-keygen -lf -

Сравните его с отпечатком файла .pub на этой странице или со строкой Accepted publickey в журнале сервера. Совпали — пара та самая.

Мой ключ уходит на сервер?

Нет. Ключ разбирается в браузере, отпечаток считает встроенный в браузер WebCrypto, а не сервер. В скрипте страницы нет ни fetch, ни XMLHttpRequest, ни отправки формы, счётчиков на странице нет — откройте вкладку «Сеть» и вставьте ключ: ни один запрос его никуда не несёт.

Можно ли проверить здесь приватный ключ?

Нет, и это сделано намеренно. Текст с признаками приватного ключа или файла .ppk не обрабатывается: поле сразу очищается и появляется предупреждение, а при уходе со страницы поле очищается ещё раз. Приватный ключ проверяется у себя командой ssh-keygen -y -f ~/.ssh/id_ed25519: она читает ключ и печатает его публичную половину, а если что-то не так, называет причину.

Почему сервер отвечает Permission denied (publickey), хотя ключ правильный?

Проверьте по порядку. Права: sshd не читает authorized_keys, если его, каталог ~/.ssh или домашний каталог может изменить кто-то, кроме владельца. Строка: один ключ — одна строка, без переносов и неразрывных пробелов внутри, в UTF-8 без BOM. Формат: блок SSH2 из PuTTYgen сервер OpenSSH не принимает. На Windows-сервере ключ администратора должен лежать в C:\ProgramData\ssh\administrators_authorized_keys.

Сервер отключил ssh-rsa — нужно менять RSA-ключ?

Обычно нет. Отключают подписи ssh-rsa на SHA-1, а RSA-ключ современный клиент подписывает через rsa-sha2-256 или rsa-sha2-512. Менять ключ стоит, если он короче 2048 бит; перейти на Ed25519 при случае всё равно разумно.

Как перевести ключ PuTTY (.ppk) в формат OpenSSH?

Командой puttygen key.ppk -O private-openssh -o ~/.ssh/id_ed25519 для приватного ключа и puttygen key.ppk -O public-openssh -o ~/.ssh/id_ed25519.pub для публичного. В графическом PuTTYgen то же делает меню Conversions → Export OpenSSH key, а строка для authorized_keys лежит в поле «Public key for pasting into OpenSSH authorized_keys file».

Ed25519 лучше RSA?

Для SSH — да. Тело ключа Ed25519 занимает 68 символов, у RSA-4096 — 716, ключ создаётся и подписывает быстрее, а постоянное время выполнения заложено в сам алгоритм, а не держится на аккуратности реализации. RSA от 3072 бит по-прежнему надёжен, RSA-2048 — нижняя граница, и она поднимается.

Почему отпечаток совпадает с ssh-keygen до символа?

Потому что считается так же: SHA-256 по декодированному телу ключа, base64 без выравнивания, с приставкой SHA256:. Мы сверили это на семи ключах — Ed25519, RSA на 2048, 3072 и 4096 бит, ECDSA на P-256, P-384 и P-521: длина и отпечаток совпали с выводом ssh-keygen из OpenSSH 10.2.

Conchshell предпочитает ключи хоста Ed25519 и договаривается об обмене ключами curve25519-sha256. Приватный ключ остаётся лежать там, где лежит, а приложение ссылается на файл — если только у подключения не отмечено «Хранить ключ в хранилище»: тогда ключ запечатывается в зашифрованное хранилище под XChaCha20-Poly1305, которое на Mac открывает ключница системы, а в Windows и Linux — парольная фраза, растянутая через Argon2id.

Что честно знать заранее: входить он умеет по паролю (в том числе когда сервер спрашивает его через keyboard-interactive) и по приватному ключу — OpenSSH или PuTTY .ppk, с парольной фразой и без, а PEM в PKCS#1 или PKCS#8 — без парольной фразы. Если рядом с файлом ключа лежит сертификат <ключ>-cert.pub, он предъявляется первым. Вход возможен и через ssh-agent: на macOS и Linux — из SSH_AUTH_SOCK, в Windows — через встроенный агент OpenSSH (не Pageant). Одноразовый код, который спрашивают через keyboard-interactive, ввести нельзя, а в приложении для телефона агента нет.

Приложение бесплатное; платная в нём одна возможность — синхронизация подключений между своими компьютерами, $19 один раз.

Скачать Conchshell бесплатно

• Проверка ~/.ssh/config — опечатки, повторы, шифры и проверка ключа хоста
• Отпечатки SSH-ключей — SHA256 и MD5 для всего authorized_keys или known_hosts, хэшированные хосты тоже
• Команда ssh-keygen — для перевыпуска, с объяснением каждого флага
• Перевести ключ PuTTY в OpenSSH — и обратно, в браузере
• Сколько весят эти клиенты — замеренные размер и память, с методикой
• Как устроено хранилище учётных данных
• Conchshell: SSH, SFTP, FTPS и RDP в одном окне
• Загрузка