Ssh dss что это
OpenSSH implements all of the cryptographic algorithms needed for compatibility with standards-compliant SSH implementations, but since some of the older algorithms have been found to be weak, not all of them are enabled by default. This page describes what to do when OpenSSH refuses to connect with an implementation that only supports legacy algorithms.
For a successful connection, there must be at least one mutually-supported choice for each parameter.
If the client and server are unable to agree on a mutual set of parameters then the connection will fail. OpenSSH (7.0 and greater) will produce an error message like this:
The best resolution for these failures is to upgrade the software at the other end and/or replace the weak key types with safer modern types. OpenSSH only disables algorithms that we actively recommend against using because they are known to be weak. This might not be immediately possible in some cases, so you may need to temporarily re-enable the weak algorithms to retain access.
For the case of the above error message, OpenSSH can be configured to enable the diffie-hellman-group1-sha1 key exchange algorithm (or any other that is disabled by default) using the KexAlgorithms option, either on the command line:
The ‘+’ before the list instructs ssh to append the algorithm to the client’s default set rather than replacing the default. By appending, you will automatically upgrade to the best supported algorithm when the server starts supporting it.
Another example, this time where the client and server fail to agree on a public key algorithm for host authentication:
OpenSSH 7.0 and greater similarly disable the ssh-dss (DSA) public key algorithm. It too is weak and we recommend against its use. It can be re-enabled using the HostKeyAlgorithms configuration option:
Depending on the server configuration, it’s possible for other connection parameters to fail to negotiate. You might find the Ciphers and/or MACs configuration options useful for enabling these. It’s also possible to query which algorithms ssh supports:
SSH returns: no matching host key type found. Their offer: ssh-dss
I am accustomed to using Putty on a Windows box or an OSX command line terminal to SSH into a NAS, without any configuration of the client.
Ubuntu 16.04 attempts to SSH into the NAS (via LAN):
6 Answers 6
The version of OpenSSH included in 16.04 disables ssh-dss. There’s a neat page with legacy information that includes this issue: http://www.openssh.com/legacy.html
You can also add a host pattern in your
/.ssh/config so you don’t have to specify the key algorithm every time:
This has the added benefit that you don’t need to type out the IP address. Instead, ssh will recognize the host nas and know where to connect to. Of course you can use any other name in its stead.
If you came here because Bitbucket returns the following after an update to OpenSSH 8.8:
you should NOT enable DSS (like in the accepted answer), but rather RSA in
Note that PubkeyAcceptedKeyTypes is a backwards compatible alias to PubkeyAcceptedAlgorithms which has been suggested in the article. If you use it, the same configuration can be used with older OpenSSH client versions, e.g. if you share the config with docker containers.
You can do the same for other hosts, or use Host * to allow RSA for any host.
Каждый раз, когда мы подключаемся по протоколу ssh к серверу, ssh клиент проверяет совпадает ли публичный ключ для этого сервера с тем, который был прошлый раз (по крайней мере так рекомендует делать стандарт ssh). В OpenSSH список известных ключей серверов хранится в файле known_hosts. Под катом коротко о том, что и как конкретно там хранится.
Все эксперименты проводились на Linux (Debian/Mint/Ubuntu). За расположение и содержание файлов в других ОС не ручаюсь.
Подключаясь первый раз к ssh серверу, мы видим примерно такое сообщение:
The authenticity of host ‘192.168.0.2 (192.168.0.2)’ can’t be established.
RSA key fingerprint is SHA256:kd9mRkEGLo+RBBNpxKp7mInocF3/Yl/0fXRsGJ2JfYg.
Are you sure you want to continue connecting (yes/no)?
/.ssh/known_hosts добавится такая строка:
|1|CuXixZ+EWfgz40wpkMugPHPalyk=|KNoVhur7z5NAZmNndtwWq0kN1SQ= ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCeiF4OOOUhWvOYrh/e4q91+iz+i9S0s3M2LPq+GAhRlhKt5vKyEVd6x6m26cc98Y+SQXnCB9GWeVYk8jlFHEXnY4YWeWLDwXIhHBJYt5yz3j5Wkg95x+mPvO9FLSBk/Al2GbH5q6F+hZIlLmO6ciISmX4TtcG1sw4SwoTADrrhdM0OJd+c5CU8iqCbc6PznYbLZXCvqPZTWeSbTLUcUu1Ti+7xGwT8DF+tIyLFcU+zxd0QnwJIbNvewkHs0LsMOWFVPz/Nd0XiVXimX+ugCDBZ/4q8NUwH9SGzCMAvnnr+D1I8X2vhSuRsTsQXL5P3vf8elDxPdDrMJzNtlBCbLWzV
Тут через пробел записаны три элемента: хэш от имени сервера, название используемого ассиметричного алгоритма и публичный ключ сервера. Разберём их по очереди.
Имя сервера
На самом деле тут может быть записано и имя хоста в открытом виде или маска, задающая множество допустимых имён. Но у меня по умолчанию сохраняется хэшированое имя. Запись разделена на 3 части символом «|». Первая часть — алгоритм хэширования. «1» соответствует HMAC-SHA1 (других не видел). Вторая часть — соль (ключ для HMAC). Третья часть — собственно хэш (вывод HMAC).
Ассиметричный алгоритм
В RFC-4253 перечислены 4 ассиметричных алгоритма: ssh-dss (по стандарту обязательный, но считается слабым и начиная с OpenSSH7.0 выключен по-умолчанию), ssh-rsa (рекомендуемый), pgp-sign-rsa (опциональный), pgp-sign-dss (опциональный). По умолчанию в Linux генерируются ключи первых двух видов и для не упомянутых в RFC алгоритмов на эллиптических кривых. Предпочтение отдаётся последним, однако клиент может выбрать алгоритм опцией HostKeyAlgorithms.
Публичный ключ
Публичный ключ в known_hosts совпадает с тем, который записан в файле /etc/ssh/ssh_host_rsa_key.pub на сервере (вместо rsa подставить название используемого алгоритма). Если снять Base64 кодирование, то внутри будет ещё раз название алгоритма и собственно компоненты ключа.
Видно, что идут 4 байта, в которые записана длина поля, потом само поле и т.д. Первое поле — название алгоритма, остальные зависят от конкретного алгоритма. В приведённом выше ключе 3 поля:
Проблемы с подключением SSH при помощи ключей
Почему так происходит и как решить возникшую проблему? Об этом я расскажу в своей сегодняшней статье.
Очень часто пользователи заодно с обычными обновлениями своей системы, обновляют и OpenSSH. В OpenSSH 7.0 изменился способ работы с некоторыми устаревающими и более слабыми криптографическими протоколами. Они всё еще поддерживаются OpenSSH, но по умолчанию отключены. В Вашем случае Вы пытаетесь подключиться к серверу, который поддерживает только алгоритм ssh-dss (DSA) с открытым ключом, а его разработчики OpenSSH считают слабым.
Решение состоит в том, чтобы снова включить алгоритм ssh-dss и, поскольку алгоритм слабый, делать это только для таких сайтов, которым это абсолютно необходимо. Если у Вас уже есть запись хоста для этого сайта в файлах /eto/ssh/ssh_oonfig или
/.ssh/config, припишите к ней следующую директиву:
Если ни в одном из этих файлов записи хоста нет, добавьте ее следующим образом:
Если для подключения обычно используется имя хоста, а не IP-адрес, это имя следует поместить в строку Host. Если в файле есть раздел, начинающийся с Host *, надо поместить свою запись выше него. Это связано с тем, что SSH использует первую подвернувшуюся подходящую запись, и если раздел Host * встретится раньше Вашего, то Ваши изменения никакой роли не сыграют. Если это одноразовое подключение и Вы не хотите добавлять хост к своему конфигурационному файлу, можно также включить ключевой алгоритм с командной строки для од но го вызова SSH:
+ перед именем алгоритма означает, что он добавляется к списку доступных алгоритмов. (Если плюс не указать, то весь список заменится на указанный Вами алгоритм.) Это очень важно, потому что когда на сайте окажется доступным более надежный метод, OpenSSH автоматически применит его без какого-либо участия с Вашей стороны. Не указав +, Вы будете прикованы к более слабому методу навсегда. Существуют похожие ограничения на алгоритмы обмена ключами, которые обрабатываются аналогичным образом при посредства параметра KexAlgorithms.
Устранение неполадок SSH: ошибки аутентификации
В первой статье этой серии вы узнали о том, как и в каких ситуациях вы можете попробовать исправить ошибки SSH. Остальные статьи расскажут, как определить и устранить ошибки:
После установления соединения и инициирования протокола система может проверить подключение пользователя к системе. SSH поддерживает множество механизмов аутентификации. В этом руководстве рассмотрены два наиболее распространенных механизма: парольная аутентификация и аутентификация на основе SSH-ключей.
Требования
Основные ошибки
Отказ в доступе (парольная аутентификация)
Примечание: Если вы настроили на сервере SSH-ключи и отключили PasswordAuthentication, сервер не поддерживает паролей. Используйте SSH-ключ, чтобы подключиться к серверу.
Клиенты PuTTY и OpenSSH выдают такое сообщение:
root@111.111.111.111’s password:
Permission denied (publickey,password).
PuTTY Error output
root@111.111.111.111’s password:
Access denied
Server sent disconnect message
type 2 (protocol error):
«Too many authentication failures for root»
Это значит, что аутентификация прошла неудачно. Ошибка может быть вызвана рядом проблем. Вот несколько советов по устранению этой ошибки:
Отказ в доступе (аутентификация на основе SSH-ключей)
Этот метод использует криптографические ключи для аутентификации пользователя.
Читайте также:
Вы можете получить такую ошибку:
Permission denied (publickey).
PuTTY Error output
Disconnected: No supported authentication methods available (server sent: publickey)
Многие наиболее распространенные проблемы, связанные с аутентификацией на основе ключей, вызваны неправильными правами доступа к файлам или правами собственности. Чтобы устранить проблему, попробуйте сделать следующее:
Консоль не поддерживает пароли
Если вы не можете восстановить доступ к консоли, это может указывать на проблемы с файловой системой или конфигурацией в подсистеме PAM, которые влияют на механизм аутентификации. Эта ошибка также повлияет на попытки сбросить пароль root и войти в систему через консоль.
В консоли появляется форма аутентификации:
Ubuntu 14.04.4 LTS server tty1
server Login:
Password:
Но после ввода пароля появляется ошибка:
После сброса пароля вы получите:
You are required to change your password immediately (root enforced)
Changing password for root.
(Current) UNIX Password:
Повторно введите текущий пароль. Если соединение закроется, возможно, вы допустили ошибку, повторно вводя пароль. Повторите попытку.
При успешном завершении вам будет предложено дважды ввести новый пароль:
Enter new UNIX password:
Retype new UNIX password:
Однако если после повторного ввода правильного нового пароля сессия перезапустится (т.е. снова вернется форма для входа в систему) или появится сообщение об ошибке, это означает, что проблема в одном из файлов, в котором хранятся данные аутентификации.
В таком случае рекомендуется обратиться за помощью в службу поддержки хостинг-провайдера, подготовить сервер к повторному развёртыванию или исправить ошибки в настройках PAM.
Устранение неполадок
Проверка доступных методов аутентификации
Если вы используете подробный вывод или следите за логами SSH-клиента, убедитесь, что в сообщении, описывающем методы аутентификации, указаны password и/или publickey.
debug1: Authentications that can continue: publickey,password
Если вы не нашли в списке метод аутентификации, который хотите использовать, откройте файл /etc/ssh/sshd_config. В нём часто допускается ошибка: PasswordAuthentication имеет значение yes, а PermitRootLogin – no или without-password для пользователя root.
Исправьте эту ошибку, перезапустите сервис.
Настройка прав доступа и собственности
Сервер и клиент OpenSSH имеют строгие требования к привилегиям и правам собственности на файлы ключей.
Сервер и клиент OpenSSH должны иметь следующие права:
./ssh должен принадлежать текущему аккаунту.
/.ssh/authorized_keys должен принадлежать текущему аккаунту.
Кроме того, клиент должен также иметь такие права:
Эти изменения можно внести с помощью консоли.
Проверка открытого и закрытого ключа
Если вы забыли, какой закрытый ключ соответствует тому или иному открытому ключу, инструменты OpenSSH и PuTTY помогут вам сгенерировать открытый ключ на основе зарытого ключа. Полученный результат вы можете сравнить с файлом
Чтобы восстановить открытый ключ на основе закрытого ключа в среде OpenSSH, используйте ssh-keygen и укажите путь к закрытому ключу.
/.ssh/id_rsa
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfBiMwCU1xoVVp0VbSYV3gTDV/jB57IHdILQ8kJ2622//Lmi4gDPlxA6HXVKq8odkGD/5MjqUw85X2rwEbhoBul74+LCToYJvvvBaDPCgg5z1icCKIJ1m/LJBrGNqPKCgqFWu0EH4/EFP2XIQqWqX1BZtJu/2YWrTr+xFOE/umoYmOd+t3dzQqMsv/2Aw+WmA/x/B9h+41WrobDgCExYNLPYcD0PO7fpsa8CcrZCo+TUWCe7MgQQCSM6WD4+PuYFpUWGw3ILTT51bOxoUhAo19U8B2QqxbMwZomzL1vIBhbUlbzyP/xgePTUhEXROTiTFx8W9yetDYLkfrQI8Q05+f
Импортировав ключ, вы увидите окно с разделом Public key for pasting into OpenSSH authorized_keys file. В нём и будет искомый открытый ключ. Выделите текст и вставьте его в файл. Он сгенерирует открытый ключ.
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfBiMwCU1xoVVp0VbSYV3gTDV/jB57IHdILQ8kJ2622//Lmi4gDPlxA6HXVKq8odkGD/5MjqUw85X2rwEbhoBul74+LCToYJvvvBaDPCgg5z1icCKIJ1m/LJBrGNqPKCgqFWu0EH4/EFP2XIQqWqX1BZtJu/2YWrTr+xFOE/umoYmOd+t3dzQqMsv/2Aw+WmA/x/B9h+41WrobDgCExYNLPYcD0PO7fpsa8CcrZCo+TUWCe7MgQQCSM6WD4+PuYFpUWGw3ILTT51bOxoUhAo19U8B2QqxbMwZomzL1vIBhbUlbzyP/xgePTUhEXROTiTFx8W9yetDYLkfrQI8Q05+f imported-openssh-key
Можно проигнорировать комментарий после открытого ключа (imported-openssh-key).
В любом случае этот открытый ключ нужно добавить в файл
OpenSSH 7 и устаревшие ключевые алгоритмы
В системах с OpenSSH 7 (FreeBSD и CoreOS по умолчанию) старые ключи DSA не поддерживаются.
Ключи ssh-dss считаются слабыми, вместо них рекомендуют использовать более надёжные современные алгоритмы.
Следовательно, в данном случае лучшим решением будет создать новые ключи и добавить их на хосты.
Однако в качестве обходного пути вы можете установить в PubkeyAcceptedKeyTypes значение +ssh-dss в файле /etc/ssh/sshd_config.
Заключение
Если у вас не получается самостоятельно настроить аутентификацию SSH, вы можете обратиться за помощью к службе поддержки своего хостинг-провайдера.