Проверка ~/.ssh/config

Заполните то, что знаете. Пустые поля не угадываются, а просто не попадают в вывод. Списков алгоритмов в блоке нет: умолчания OpenSSH и есть те, которые стоит иметь, а прибитый список отрезает то, что добавят следующие версии. Каждую строку блока понимает OpenSSH 7.3 и новее, а ключ хоста проверяется обычным порядком: при первом подключении ssh спросит, доверять ли ключу, а сменившийся ключ остановит соединение.

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

• ERROR — ошибка: строка ломает файл, пускает в ход слабую криптографию или выключает проверку ключа хоста. Правьте её первой.
• WARN — замечание: например, повтор, который ssh не применит, осознанный риск вроде PasswordAuthentication yes или директива, на которую ssh ругается при каждом запуске.
• INFO — к сведению: например, старое имя директивы, устаревшая строка, директива Apple, отсутствие IdentityFile. Сюда же попадает «Ciphers не задан», и это хорошая новость: умолчания OpenSSH лучше прибитого списка.

Если находок нет, значит, страница не нашла, к чему придраться, — не больше. Права на файл, метку BOM в начале и порядок блоков она не видит; о них ниже.

• Устаревшие шифры. 3des-cbc, arcfour, blowfish-cbc и всё остальное с окончанием -cbc. За режимом CBC в SSH тянется длинная история атак на дополнение, и OpenSSH перестал предлагать эти шифры по умолчанию много лет назад.
• Слабые MAC. hmac-md5, hmac-sha1, их укороченные варианты -96 и umac-64. Отдельно, уровнем ниже, отмечаются MAC без суффикса -etm@openssh.com: они считают код целостности до шифрования, а не после.
• Обмен ключами. Строка KexAlgorithms, которая задаёт список целиком и не оставляет в нём ни curve25519-sha256, ни другого сильного обмена, или вычёркивает curve25519-sha256 минусом. Любой обмен на SHA-1 — ошибка. Строка, которая сама вычёркивает такой обмен минусом, вроде KexAlgorithms -diffie-hellman-group14-sha1, пока тоже получает эту ошибку — это ложная тревога, строка правильная.
• Проверка ключа хоста. StrictHostKeyChecking со значением no — ошибка; accept-new — замечание; UserKnownHostsFile, направленный в /dev/null, — ошибка, потому что стирает саму память, по которой подмену ключа можно заметить.
• Пароли и агент. PasswordAuthentication yes и ForwardAgent yes — оба замечаниями: это выбор, а не ошибка, но выбор стоит делать осознанно.
• Строение файла. Неизвестная директива — ошибка: из-за неё ssh завершается, не подключаясь ни к одному хосту, если только её не покрывает строка IgnoreUnknown выше. Старые имена и устаревшие директивы отмечаются, но не считаются ошибкой. Ещё незакрытые кавычки, пустые значения и повторы внутри одного блока — кроме директив, которые повторять и положено, вроде IdentityFile и SendEnv.
• macOS. UseKeychain — собственная директива Apple: на маке она законна, поэтому отмечается, а не считается ошибкой, вместе со строкой IgnoreUnknown, с которой тот же файл работает и на других системах.

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

ssh -G edge

Команда разбирает конфиг так же, как при подключении, печатает итоговые настройки для хоста edge и никуда не подключается. Если файл сломан, ssh назовёт строку и причину. Поведение ssh, описанное ниже, мы проверили сами в сентябре 2026 года на OpenSSH 10.2 (macOS) и 10.3 (Alpine Linux); права на файл — только на 10.3. Что делает PowerShell, мы не проверяли: это пересказ документации Microsoft.

Bad owner or permissions on ~/.ssh/config

Конфиг умеет запускать команды — через ProxyCommand или Match exec, — поэтому ssh требует, чтобы писать в него мог только владелец. У нас ssh отказался работать уже при правах 664 — с этой самой строкой и ни к одному хосту. Права 644 и 600 проходят:

chmod 600 ~/.ssh/config

BOM и переводы строк Windows

Переводы строк CRLF OpenSSH в конфиге пропускает: файл с ними прочитался как обычный. А метка BOM в начале файла ломает первую же строку, и выглядит это по-разному. В Linux (мы смотрели Alpine и Debian) и на Mac в локали C ssh печатает метку кодами: Bad configuration option: \357\273\277host. В macOS с обычной локалью UTF-8 метка выводится невидимой, и строка выглядит как Bad configuration option: host. Если ssh ругается на директиву Host, которую вы написали правильно, — дело в BOM. Дальше в обоих случаях terminating, и ssh не подключается никуда. В Windows PowerShell 5.1 такую метку ставит -Encoding UTF8, а операторы > и >> пишут файл и вовсе в UTF-16 — его ssh тоже не читает.

Пересохраните файл в UTF-8 без BOM. Проверить, есть ли метка, можно командой head -c 3 ~/.ssh/config | od -c: BOM выглядит как 357 273 277. Эта страница метку не показывает.

Пробелы и кавычки

Директиву от значения отделяет пробел или знак равенства: Port 22, Port=22 и Port = 22 — одно и то же. А пробел внутри значения делит его на два. Путь к ключу с пробелом без кавычек ssh считает ошибкой — keyword identityfile extra arguments at end of line — и, как с неизвестной директивой, завершается, не подключаясь никуда. Такие пути берите в двойные кавычки:

IdentityFile "~/My Keys/id_ed25519"

Этот случай страница пока не ловит.

Host * в начале файла

OpenSSH берёт первое найденное значение каждой настройки, поэтому общий блок Host * в начале файла перебивает всё, что ниже. У нас User root из верхнего Host * победил User deploy из блока нужного хоста. Общие настройки ставьте в конец файла, а частные — в начало.

То же правило объясняет повторы внутри блока: вторая строка Port ниже первой не делает ничего. Такие повторы страница находит, а спор между разными блоками — нет; итог для конкретного хоста покажет ssh -G.

Ключ PuTTY в IdentityFile

Файл .ppk ssh не прочтёт: он пишет Load key "…ppk": invalid format (в сборках с OpenSSL — error in libcrypto: unsupported) и идёт дальше без этого ключа, так что вход обычно кончается на Permission denied. Переведите ключ в формат OpenSSH:

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

Страница на такую строку не ругается: по имени файла формат не определить.

ssh-rsa для старого сервера

С OpenSSH 8.8 подписи ssh-rsa на SHA-1 выключены по умолчанию. Если старый сервер другого не умеет, разрешите их в блоке этого сервера:

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

В Host * те же строки включают SHA-1 для всех серверов сразу, и страница этого не отметит. Старое имя PubkeyAcceptedKeyTypes (до OpenSSH 8.5) работает по-прежнему, страница помечает его как старое.

Include

Файлы из Include страница не открывает — у неё есть только вставленный текст. Вставляйте каждый файл отдельно или смотрите итог через ssh -G.

Мой .ssh/config уходит на сервер?

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

Как проверить конфиг самим ssh?

Командой ssh -G имя_хоста. Она разбирает конфиг так же, как при подключении, печатает итоговые настройки для этого хоста и никуда не подключается. Если файл сломан, ssh назовёт строку и причину.

Что значит Bad configuration option?

ssh встретил директиву, которой не знает: опечатку, директиву из более новой версии OpenSSH или UseKeychain от Apple на другой системе. Он перечисляет все такие строки, пишет terminating и завершается, не подключаясь ни к одному хосту. Если ssh ругается на первую строку, которую вы написали правильно, например на Host, в начале файла стоит метка BOM. В Linux и на Mac в локали C она видна в сообщении как \357\273\277host, а в macOS с обычной локалью UTF-8 невидима, и строка выглядит как Bad configuration option: host. Пересохраните файл в UTF-8 без BOM.

Почему ssh пишет Bad owner or permissions on ~/.ssh/config?

Потому что в файл может писать кто-то, кроме владельца, а конфиг умеет запускать команды. Исправляется командой chmod 600 ~/.ssh/config. Права эта страница не видит — у неё есть только текст.

Какой порядок Ciphers считается безопасным?

chacha20-poly1305@openssh.com, дальше aes256-gcm@openssh.com, aes128-gcm@openssh.com и aes256-ctr. Шифры с встроенной аутентификацией идут первыми, потому что проверяют целостность сами. Всё, что заканчивается на -cbc, место в конце списка или нигде.

chacha20-poly1305 — это безопасно?

Да, и он стоит у OpenSSH по умолчанию не случайно. Он быстр на машинах без аппаратного AES и несёт проверку целостности сам, поэтому отдельный MAC ему не нужен. Если он выбран в Ciphers, строка MACs к таким сессиям не относится вовсе.

Нужно ли вообще задавать Ciphers?

Обычно нет. Умолчания OpenSSH сегодня хорошие, а прибитый список вы унаследуете на годы вперёд. Задавать его стоит, только если этого требует чей-то стандарт, и пересматривать при каждом обновлении OpenSSH.

Что делает StrictHostKeyChecking=accept-new?

Принимает ключ незнакомого хоста без вопроса и по-прежнему останавливает соединение, если ключ известного хоста сменился. Для одноразовых машин это разумный размен, для серверов, которыми вы дорожите, — плохой. Поэтому проверка помечает его замечанием, а не ошибкой.

Почему повтор директивы считается проблемой?

Потому что OpenSSH берёт в блоке первое значение и молча игнорирует остальные. Вторая строка Port ниже не делает ничего — и это самая частая причина фразы «я же поправил, а не применяется».

Это те же требования, по которым устроено подключение в Conchshell: ключи хоста Ed25519 первыми, обмен ключами через curve25519-sha256, ни CBC, ни обмена ключами на SHA-1, сохранённые пароли под XChaCha20-Poly1305, как только вы согласитесь на хранилище, а подтверждение ключа хоста рисует операционная система, а не приложение. Закрыть это окно, не нажав кнопку, — значит отказать, на любой системе; в версии 2.16.0 и раньше закрытие окна в Windows и Linux и кнопка «Назад» на Android считались согласием, это исправлено в 2.17.0. Несколько послаблений ради старых серверов остаются: MAC без -etm и в конце списка hmac-sha1 в обоих вариантах по-прежнему предлагаются, а ключи хоста ssh-rsa принимаются.

Свой ~/.ssh/config переписывать для него не придётся: Conchshell читает хосты оттуда сам, по правилам OpenSSH — с наследованием от Host *, первым значением и файлами из Include. Переносятся имя, адрес, пользователь, порт, IdentityFile и первый узел ProxyJump; блоки Match пропускаются, а ключи остаются на своих местах.

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

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

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