Ssh dss: SSH returns: no matching host key type found. Their offer: ssh-dss

У меня возникли проблемы с созданием ключей для GitHub. Я следую инструкциям из раздела Как использовать TortoiseGit . При создании ключа SSH для GitHub : Откройте PuTTygen, сгенерируйте ключ и…

Я следовал процессу help.github.com/win-set-up-git/ и продолжал получать сообщение Host key verification failed без каких-либо подсказок при тестировании ссылки ssh. Я работаю над Windows XP с…

На сайте GitHub есть ссылка… https:/ / help.github.com / статьи / generating-ssh-keys … и в нем говорится… Если вы решили не использовать рекомендуемый метод HTTPS, мы можем использовать ключи…

У меня есть РЕПО github, и мне было интересно, можно ли удалить возможность толкать репо без ключа ssh. Я посмотрел и ничего не вижу о том, что у меня есть только ssh-ключ, который позволит мне…

Я пишу приложение, размещенное на Heroku, которое выполняет операции чтения/записи в частных GitHub размещенных репозиториях. Я сделал следующее Сгенерировал ключ SSH, используя тот же email, что и…

Возможно,я не совсем понял использование ключа SSH в Github. Я последовал за Github docs [ https:/ / help.github.com / articles/generating-ssh-keys/] , чтобы создать ключ SSH на моем ноутбуке и…

Я очень мало знаю о SSH и т. д. Я пытался добавить новый ключ SSH на Github. Для этого я следовал этой процедуре: На Terminal work@Nirvair:~$ ssh-keygen -t rsa Generating public/private rsa key…

Я прошел через процесс генерации ssh ключей и отправки открытого ключа в github. Вчера вечером я смог протолкнуться к своему РЕПО github. Но сегодня на работе мне пришлось нажать на репо моей…

Привет, разработчики, я новичок в git, и у меня есть несколько вопросов о GitHub. Пожалуйста, ответьте, если это возможно. Q1)может ли кто-нибудь войти в мое РЕПО, если оно является публичным и если…

В нашем GitHub у нас есть около 20 репозиториев. Для CI-сборки у нас есть возможность Git избирательных включен. Наш мастер Jenkins присоединился с несколькими узлами. Для Git опроса мы обычно…

Подключение к целевой системе Linux из Visual Studio

• 01/8/2021
• Чтение занимает 8 мин

В этой статье

Вы можете настроить проект Linux для использования на удаленном компьютере или в подсистеме Windows для Linux (WSL).You can configure a Linux project to target a remote machine or the Windows Subsystem for Linux (WSL). Для работы на удаленных компьютерах и в WSL необходимо настроить в Visual Studio 2017 удаленное подключение к ним.For both remote machines and for WSL, you need to set up a remote connection in Visual Studio 2017.

Вы можете настроить проект Linux для использования на удаленном компьютере или в подсистеме Windows для Linux (WSL).You can configure a Linux project to target a remote machine or the Windows Subsystem for Linux (WSL). Для работы на удаленном компьютере необходимо настроить в Visual Studio удаленное подключение к нему.For a remote machine, you need to set up a remote connection in Visual Studio. Сведения о подключении к WSL см. в разделе Подключение к WSL.To connect to WSL, skip ahead to the Connect to WSL section.

При использовании удаленного подключения Visual Studio создает проекты Linux C++ на удаленном компьютере.When using a remote connection, Visual Studio builds C++ Linux projects on the remote machine. Неважно, является ли он физическим компьютером, виртуальной машиной в облаке или WSL.It doesn’t matter if it’s a physical machine, a VM in the cloud, or WSL. Для сборки проекта Visual Studio копирует исходный код на удаленный компьютер Linux.To build the project, Visual Studio copies the source code to your remote Linux computer. Затем код компилируется в соответствии с параметрами Visual Studio.Then, the code gets compiled based on Visual Studio settings.

Примечание

Visual Studio 2019 версии 16.5 и более поздних версий также поддерживает безопасные совместимые с FIPS 140-2 криптографические подключения к системам Linux для удаленной разработки.Visual Studio 2019 version 16.5 and later also supports secure, Federal Information Processing Standard (FIPS) 140-2 compliant cryptographic connections to Linux systems for remote development. Чтобы использовать FIPS-совместимое подключение, выполните действия, описанные в статье Set up FIPS-compliant secure remote Linux development (Настройка совместимой с FIPS безопасной удаленной разработки для Linux).To use a FIPS-compliant connection, follow the steps in Set up FIPS-compliant secure remote Linux development instead.

Настройка сервера SSH в удаленной системеSet up the SSH server on the remote system

Если сервер SSH еще не настроен и не запущен в вашей системе Linux, выполните следующие действия по его установке.If ssh isn’t already set up and running on your Linux system, follow these steps to install it. В примерах в этой статье используется Ubuntu 18.04 LTS с сервером OpenSSH версии 7.6.The examples in this article use Ubuntu 18.04 LTS with OpenSSH server version 7.6. Для всех дистрибутивов с относительно недавней версией OpenSSH следует придерживаться одинаковых инструкций.However, the instructions should be the same for any distro using a moderately recent version of OpenSSH.

1. В системе Linux установите и запустите сервер OpenSSH.On the Linux system, install and start the OpenSSH server:

   sudo apt install openssh-server
   sudo service ssh start
   

2. Чтобы сервер SSH автоматически запускался при загрузке системы, выполните команду systemctl.If you’d like the ssh server to start automatically when the system boots, enable it using systemctl:

   sudo systemctl enable ssh
   

Настройка удаленного подключенияSet up the remote connection

1. Чтобы в Visual Studio открыть диалоговое окно Параметры, в строке меню выберите Сервис > Параметры.In Visual Studio, choose Tools > Options on the menu bar to open the Options dialog. Затем выберите Кроссплатформенный > Диспетчер подключений, чтобы открыть диалоговое окно диспетчера подключений.Then select Cross Platform > Connection Manager to open the Connection Manager dialog.

   Если подключение в Visual Studio не было настроено ранее, это диалоговое окно откроется при первом создании проекта.If you haven’t set up a connection in Visual Studio before, when you build your project for the first time, Visual Studio opens the Connection Manager dialog for you.

2. В диалоговом окне диспетчера подключений нажмите кнопку Добавить, чтобы добавить новое подключение.In the Connection Manager dialog, choose the Add button to add a new connection.

   В любом сценарии отображается окно Подключение к удаленной системе.In either scenario, the Connect to Remote System window is displayed.

3. Введите следующую информацию.Enter the following information:

   ВводEntry	ОписаниеDescription
   Имя узлаHost Name	Имя или IP-адрес целевого устройстваName or IP address of your target device
   ПортPort	Порт, в котором работает служба SSH, обычно 22Port that the SSH service is running on, typically 22
   Имя пользователяUser name	Пользователь для проверки подлинностиUser to authenticate as
   Тип проверки подлинностиAuthentication type	Поддерживается и пароль, и закрытый ключPassword and Private Key are both supported
   ПарольPassword	Пароль для указанного имени пользователяPassword for the entered user name
   Файл закрытого ключаPrivate key file	Закрытый ключ, созданный для подключения по SSHPrivate key file created for ssh connection
   Парольная фразаPassphrase	Парольная фраза, используемая с закрытым ключом, выбранным вышеPassphrase used with private key selected above

   Вы можете использовать для проверки подлинности пароль или файл ключа с парольной фразой.You can use either a password or a key file and passphrase for authentication. Для многих сценариев разработки вполне достаточно проверки подлинности на основе пароля, но файлы ключей более надежны.For many development scenarios, password authentication is sufficient, but key files are more secure. Если у вас уже есть пара ключей, ее можно использовать повторно.If you already have a key pair, it’s possible to reuse it. Сейчас для удаленных подключений Visual Studio поддерживает только ключи RSA и DSA.Currently Visual Studio only supports RSA and DSA keys for remote connections.

4. Нажмите кнопку Подключить, чтобы попытаться подключиться к удаленному компьютеру.Choose the Connect button to attempt a connection to the remote computer.

   Если соединение будет установлено успешно, Visual Studio настроит IntelliSense для использования удаленных заголовков.If the connection succeeds, Visual Studio configures IntelliSense to use the remote headers. Подробнее см. раздел об использовании IntelliSense для заголовков в удаленных системах.For more information, see IntelliSense for headers on remote systems.

   Если подключение установить не удастся, будут выделены красным цветом поля, информацию в которых нужно изменить.If the connection fails, the entry boxes that need to be changed are outlined in red.

   Если вы используете для аутентификации файлы ключей, убедитесь, что сервер SSH на целевом компьютере работает и настроен правильно.If you use key files for authentication, make sure the target machine’s SSH server is running and configured properly.

Поддерживаемые алгоритмы SSHSupported SSH algorithms

Начиная с Visual Studio версии 16.9, была удалена поддержка старых и незащищенных алгоритмов SSH, используемых для шифрования данных и обмена ключами.Starting in Visual Studio version 16.9, support for older, insecure SSH algorithms used to encrypt data and exchange keys, has been removed. Поддерживаются только следующие алгоритмы.Only the following algorithms are supported. Они поддерживают обмен данными как в направлении «клиент-сервер», так и в направлении «сервер-клиент» по протоколу SSH:They are supported for both client-to-server and server-to-client SSH communication:

Настройка сервера SSHConfigure the SSH server

Сначала немного теории.First, a little background. Вам не удастся выбрать алгоритм SSH для использования в Visual Studio.You can’t select the SSH algorithm to use from Visual Studio. Алгоритм определяется во время первоначального подтверждения с помощью сервера SSH.Instead, the algorithm is determined during the initial handshake with the SSH server. Каждая сторона (клиент и сервер) предоставляет список поддерживаемых алгоритмов, а затем выбирается первый алгоритм, общий для обоих.Each side (client and server) provides a list of algorithms it supports, and then the first algorithm common to both is selected. Если имеется хотя бы один алгоритм, общий для Visual Studio и сервера для шифрования, HMAC, обмена ключами и т. д., соединение будет работать.As long as there is at least one algorithm in common between Visual Studio and the server for encryption, HMAC, key exchange, and so on, the connection will succeed.

Открытый файл конфигурации SSH (sshd_config) не определяет, какой алгоритм использовать по умолчанию.The Open SSH configuration file (sshd_config) doesn’t configure which algorithm to use by default. Если алгоритмы не указаны, сервер SSH должен использовать безопасные значения по умолчанию.The SSH server should use secure defaults when no algorithms are specified. Эти значения по умолчанию зависят от версии и поставщика сервера SSH.Those defaults depend on the version and vendor of the SSH server. Если Visual Studio не поддерживает эти значения по умолчанию или сервер SSH настроен на использование алгоритмов, которые не поддерживаются в Visual Studio, то, скорее всего, появится сообщение об ошибке следующего вида: Не удалось подключиться к удаленной системе. Не найден алгоритм HMAC, общий для клиента и сервера.If Visual Studio doesn’t support those defaults, or the SSH server is configured to use algorithms that Visual Studio doesn’t support, you’ll likely see an error like: Could not connect to the remote system. No common client to server HMAC algorithm was found.

В большинстве современных дистрибутивов Linux сервер SSH, настроенный по умолчанию, должен работать в среде с Visual Studio.A default SSH server on most modern Linux distributions should work out-of-the-box with Visual Studio. Ниже объясняется, как выполнить обновление до более безопасных версий, если вы используете более старый сервер SSH, который настроен на использование старых, незащищенных алгоритмов.But if you’re running an older SSH server that is configured to use older, insecure algorithms, the following explains how to update to more secure versions.

В следующем примере сервер SSH использует небезопасный алгоритм hmac-sha1, который не поддерживается в Visual Studio 16.9.In the following example, the SSH server uses the insecure hmac-sha1 algorithm, which isn’t supported by Visual Studio 16.9. Если сервер SSH использует OpenSSH, можно внести изменения в файл /etc/ssh/sshd_config, как показано ниже, чтобы включить более защищенные алгоритмы.If the SSH server uses OpenSSH, you can edit the /etc/ssh/sshd_config file as shown below to enable more secure algorithms. Дополнительные сведения о настройке других серверов SSH см. в документации по серверу.For other SSH servers, refer to the server’s documentation for how to configure them.

Во-первых, убедитесь, что набор алгоритмов, используемых сервером, включает алгоритмы, поддерживаемые Visual Studio.First, verify that the set of algorithms your server is using includes algorithms supported by Visual Studio. На удаленном компьютере выполните следующую команду, в которой будут перечислены алгоритмы, поддерживаемые сервером.Run the following command on the remote machine, and it will list the algorithms supported by the server.

$ ssh -Q cipher; ssh -Q mac; ssh -Q kex; ssh -Q key

Результат будет выглядеть следующим образом.It will produce output like:

3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
...
[email protected]
[email protected]

Будут перечислены все алгоритмы шифрования, HMAC, обмена ключами и алгоритмы ключей узла, поддерживаемые сервером SSH.This output will list all the encryption, HMAC, key exchange, and host key algorithms supported by your SSH server. Если в этом списке не указаны алгоритмы, поддерживаемые Visual Studio, обновите сервер SSH, прежде чем продолжать работу.If this list doesn’t include algorithms supported by Visual Studio, then you’ll need to upgrade your SSH server before proceeding.

Включить алгоритмы, поддерживаемые Visual Studio, можно путем изменения /etc/ssh/sshd_config на удаленном компьютере.You can enable algorithms supported by Visual Studio by editing /etc/ssh/sshd_config on the remote machine. В следующих примерах показано, как добавить различные типы алгоритмов в этот файл конфигурации.The following examples show how to add various types of algorithms to that configuration file.

Эти примеры можно добавить в любое место в /etc/ssh/sshd_configThese examples can be added anywhere in /etc/ssh/sshd_config. в отдельных строках.Ensure that they are on their own lines.

После редактирования файла перезапустите сервер SSH (sudo service ssh restart в Ubuntu) и попробуйте снова подключиться из Visual Studio.After editing the file, restart the SSH server (sudo service ssh restart on Ubuntu) and attempt to connect again from Visual Studio.

Пример шифраCipher example

Добавьте: Ciphers <algorithms to enable>Add: Ciphers <algorithms to enable>
Пример: Ciphers aes128-cbc,aes256-cbcFor example: Ciphers aes128-cbc,aes256-cbc

Пример HMACHMAC example

Добавьте: MACs <algorithms to enable>Add: MACs <algorithms to enable>
Пример: MACs hmac-sha2-256,hmac-sha2-512For example: MACs hmac-sha2-256,hmac-sha2-512

Пример обмена ключамиKey exchange example

Добавьте: KexAlgorithms <algorithms to enable>Add: KexAlgorithms <algorithms to enable>
Пример: KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384For example: KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384

Пример ключа узлаHost key example

Добавьте: HostKeyAlgorithms <algorithms to enable>Add: HostKeyAlgorithms <algorithms to enable>
Пример: HostKeyAlgorithms ssh-dss,ssh-rsaFor example: HostKeyAlgorithms ssh-dss,ssh-rsa

Ведение журнала для удаленных подключенийLogging for remote connections

Вы можете включить ведение журнала для устранения проблем с подключением.You can enable logging to help troubleshoot connection problems. В строке меню выберите Сервис > Параметры.On the menu bar, select Tools > Options. В диалоговом окне Параметры выберите Кроссплатформенный > Ведение журнала.In the Options dialog, select Cross Platform > Logging:

Журналы сохраняют все попытки подключения, все отправленные на удаленный компьютер команды (строка команды, код завершения и время выполнения), а также все данные, выводимые из Visual Studio в оболочку.Logs include connections, all commands sent to the remote machine (their text, exit code and execution time), and all output from Visual Studio to the shell. Ведение журналов поддерживается в Visual Studio для любого кроссплатформенного проекта CMake или проекта Linux на основе MSBuild.Logging works for any cross-platform CMake project or MSBuild-based Linux project in Visual Studio.

Вы можете настроить вывод данных в файл или на панель кроссплатформенного ведения журнала в окне вывода.You can configure the output to go to a file or to the Cross Platform Logging pane in the Output window. В проектах Linux на основе MSBuild команды MSBuild, передаваемые на удаленный компьютер, не отправляются в окно вывода, так как они порождаются вне основного процесса.For MSBuild-based Linux projects, MSBuild commands sent to the remote machine aren’t routed to the Output Window because they’re emitted out-of-process. Такие команды сохраняются в отдельный файл с префиксом «msbuild_».Instead, they’re logged to a file, with a prefix of «msbuild_».

Служебная программа командной строки для диспетчера подключенийCommand-line utility for the Connection Manager

Visual Studio 2019 версии 16.5 или более поздней: ConnectionManager.exe — это программа командной строки для управления подключениями удаленной разработки вне Visual Studio.Visual Studio 2019 version 16.5 or later: ConnectionManager.exe is a command-line utility to manage remote development connections outside of Visual Studio. Ее удобно использовать для выполнения таких задач, как подготовка нового компьютера разработчика.It’s useful for tasks such as provisioning a new development machine. Кроме того, с ее помощью можно настроить Visual Studio для непрерывной интеграции.Or, you can use it to set up Visual Studio for continuous integration. Примеры и полные справочные сведения по командам ConnectionManager см. в статье Справка по ConnectionManager.For examples and a complete reference to the ConnectionManager command, see ConnectionManager reference.

Перенаправление TCP-портовTCP Port Forwarding

Поддержка Linux в Visual Studio зависит от перенаправления TCP-портов.Visual Studio’s Linux support has a dependency on TCP port forwarding. Если в удаленной системе отключено перенаправление TCP-портов, это повлияет на rsync и gdbserver.Rsync and gdbserver are affected if TCP port forwarding is disabled on your remote system. Если эта зависимость влияет на вас, вы можете оставить свое предложение на сайте Сообщества разработчиков.If you’re impacted by this dependency, you can upvote this suggestion ticket on Developer Community.

С помощью rsync в проектах Linux на основе MSBuild и проектах CMake можно копировать заголовки, которые будут использоваться в IntelliSense, из удаленной системы в Windows.rsync is used by both MSBuild-based Linux projects and CMake projects to copy headers from your remote system to Windows for use by IntelliSense. Если вы не можете включить перенаправление TCP-портов, отключите автоматическое скачивание удаленных заголовков.When you can’t enable TCP port forwarding, disable the automatic download of remote headers. Для этого последовательно выберите Сервис > Параметры > Кроссплатформенный > Диспетчер подключений > Диспетчер удаленных заголовков IntelliSense.To disable it, use Tools > Options > Cross Platform > Connection Manager > Remote Headers IntelliSense Manager. Если для удаленной системы не включено перенаправление TCP-портов, то при скачивании удаленных заголовков для IntelliSense будет отображаться приведенное ниже сообщение об ошибке.If the remote system doesn’t have TCP port forwarding enabled, you’ll see this error when the download of remote headers for IntelliSense begins:

Кроме того, rsync используется при реализации поддержки CMake в Visual Studio для копирования исходных файлов в удаленную систему.rsync is also used by Visual Studio’s CMake support to copy source files to the remote system. Если вы не можете включить перенаправление TCP-портов, используйте SFTP в качестве метода копирования источников из удаленного расположения.If you can’t enable TCP port forwarding, you can use sftp as your remote copy sources method. SFTP обычно работает медленнее, чем rsync, но не зависит от перенаправления TCP-портов.sftp is often slower than rsync, but doesn’t have a dependency on TCP port forwarding. Управлять методом копирования источников из удаленного расположения можно с помощью свойства remoteCopySourcesMethod в редакторе параметров CMake.You can manage your remote copy sources method with the remoteCopySourcesMethod property in the CMake Settings Editor. Если в удаленной системе отключено перенаправление TCP-портов, то при первом вызове rsync в окне выходных данных CMake появится сообщение об ошибке.If TCP port forwarding is disabled on your remote system, you’ll see an error in the CMake output window the first time it invokes rsync.

С помощью gdbserver можно выполнять отладку на встроенных устройствах.gdbserver can be used for debugging on embedded devices. Если вы не можете включить перенаправление TCP-портов, необходимо использовать gdb для всех сценариев удаленной отладки.If you can’t enable TCP port forwarding, then you must use gdb for all remote debugging scenarios. gdb используется по умолчанию при отладке проектов в удаленной системе.gdb is used by default when debugging projects on a remote system.

Подключение к WSLConnect to WSL

В Visual Studio 2017 подключение к WSL выполняется так же, как к удаленному компьютеру Linux.In Visual Studio 2017, you use the same steps to connect to WSL as you use for a remote Linux machine. Укажите localhost в качестве имени узла.Use localhost for the Host Name.

В Visual Studio 2019 версии 16.1 добавлена собственная поддержка для использования C++ с подсистемой Windows для Linux (WSL).Visual Studio 2019 version 16.1 added native support for using C++ with the Windows Subsystem for Linux (WSL). Это значит, что сборка и отладка локальной установки WSL выполняются напрямую.That means you can build and debug on your local WSL installation directly. Больше не нужно добавлять удаленное подключение или настраивать SSH.You no longer need to add a remote connection or configure SSH. Дополнительные сведения об установке WSL можно найти здесь.You can find details on how to install WSL here.

Чтобы настроить установку WSL для работы с Visual Studio, потребуется установить следующие средства: gcc or clang, gdb, make, ninja-build (требуется только для проектов CMake с использованием Visual Studio 2019 версии 16.6 и более поздней), rsync и zip.To configure your WSL installation to work with Visual Studio, you need the following tools installed: gcc or clang, gdb, make, ninja-build (only required for CMake projects using Visual Studio 2019 version 16.6 or later), rsync, and zip. Их можно установить на дистрибутивах, использующих apt, с помощью этой команды, которая также устанавливает компилятор g++:You can install them on distros that use apt by using this command, which also installs the g++ compiler:

sudo apt install g++ gdb make ninja-build rsync zip

Ознакомьтесь с дополнительными сведениями о скачивании, установке и настройке рабочей нагрузки для Linux.For more information, see Download, install, and set up the Linux workload.

Сведения о настройке проекта MSBuild для WSL см. в статье Настройка проекта Linux.To configure an MSBuild project for WSL, see Configure a Linux project. Сведения о настройке проекта CMake для WSL см. в статье Настройка проекта Linux CMake.To configure a CMake project for WSL, see Configure a Linux CMake project. Пошаговые инструкции по созданию простого консольного приложения с помощью WSL приводятся в ознакомительной публикации блога о C++ в Visual Studio 2019 и подсистеме Windows для Linux (WSL).To follow step-by-step instructions for creating a simple console application with WSL, check out this introductory blog post on C++ with Visual Studio 2019 and the Windows Subsystem for Linux (WSL).

См. также:See Also

Настройка проекта LinuxConfigure a Linux project
Настройка проекта Linux CMakeConfigure a Linux CMake project
Развертывание, запуск и отладка проекта LinuxDeploy, run, and debug your Linux project
Настройка сеансов отладки CMakeConfigure CMake debugging sessions

Обновление ssh и очередное отключение устаревших алгоритмов – youngblogger на hoster-ok.com

Время идёт и постепенно старые алгоритмы шифрования становятся небезопасными. Разрабочики софта конечно же постепенно их отключают. Но для админа-то обычно это просиходит внезапно и ой как не вовремя и становится чертовски неприятным сюрпризом, особенно если обновления накатываются атоматически. Так обновление на Fedora 23 подарило мне пару незабываемых часов когда я не мог достучаться на большую часть серверов которыми управляю. Казалось бы что обновление openssl, openssh в любом виде должно стать красной тряпкой, но пока что стереотип поведения не сложился. И последнее обновление openssh.i686 7.2p1-2.fc23, openssh-server.i686 7.2p1-2.fc23, openssh-clients.i686 7.2p1-2.fc23 снова подарило неожиданный сюрприз в виде невозможности залогиниться на клиентский mikrotik.

[user001@localhost ~]$ ssh [email protected]
ssh_dispatch_run_fatal: Connection to 192.168.88.1 port 22: DH GEX group out of range

И как обычно бывает в свежих случаях гугл и яндекс не показали ничего интересного.
— Упс, сказал я и полез в мануал.

В мануале man ssh_config в секции KexAlgorithms приведены следующие умолчания:

KexAlgorithms
             Specifies the available KEX (Key Exchange) algorithms.  Multiple algorithms must be comma-separated.  Alternately if the specified value
             begins with a ‘+’ character, then the specified methods will be appended to the default set instead of replacing them.  The default is:

                   [email protected],
                   ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,
                   diffie-hellman-group-exchange-sha256,
                   diffie-hellman-group-exchange-sha1,
                   diffie-hellman-group14-sha1

             The list of available key exchange algorithms may also be obtained using the -Q option of ssh(1) with an argument of “kex”.

Я решил что по сравнению с предыдущей версией был отключён какой-то алгоритм поэтому полез посмотреть что из полного списка отключено. ssh -Q kex показал список и я выделил те что включены по умолчанию.

* [email protected]
  diffie-hellman-group1-sha1
* diffie-hellman-group14-sha1
* diffie-hellman-group-exchange-sha1
* diffie-hellman-group-exchange-sha256
* ecdh-sha2-nistp256
* ecdh-sha2-nistp384
* ecdh-sha2-nistp521
  gss-gex-sha1-
  gss-group14-sha1-
  gss-group1-sha1-

Теперь нужно включить отладку и найти какие Кекс алгоритмы предлагают клиент и сервер. Достаточно будет второго уровня отладки опция -vv

[user001@localhost ~]$ ssh -vv [email protected] 2>&1
debug2: local client KEXINIT proposal
debug2: KEX algorithms: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: [email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-dss
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-dss
debug2: ciphers ctos: aes192-cbc,aes128-cbc,aes256-cbc,blowfish-cbc,3des-cbc
debug2: ciphers stoc: aes192-cbc,aes128-cbc,aes256-cbc,blowfish-cbc,3des-cbc
debug2: MACs ctos: hmac-sha1,hmac-md5
debug2: MACs stoc: hmac-sha1,hmac-md5
debug2: compression ctos: none
debug2: compression stoc: none
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-dss
debug1: kex: server->client cipher: aes128-cbc MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes128-cbc MAC: hmac-sha1 compression: none
debug1: kex: diffie-hellman-group-exchange-sha256 need=20 dh_need=20
debug1: kex: diffie-hellman-group-exchange-sha256 need=20 dh_need=20
debug1: SSh3_MSG_KEX_DH_GEX_REQUEST(2048<7680<8192) sent
debug1: got SSh3_MSG_KEX_DH_GEX_GROUP
ssh_dispatch_run_fatal: Connection to 192.168.88.1 port 22: DH GEX group out of range

Если сопоставить строки клиента и сервера то видно, что совпадают только 3 алгоритма и первым в порядке очерёдности идёт алгоритм diffie-hellman-group-exchange-sha256 именно его и клиент и серверо принимают и начинают обмен после чего происходит ошибка DH GEX group out of range. Так как следующий алгоритм автоматически не проверяется я подставлял их вручную и искал тот который сработает. Вторым стоит diffie-hellman-group-exchange-sha1 но с ним такая же проблема. Третьим стоит diffie-hellman-group14-sha1, и он стал спасением от даунгрейда ssh клиента. Я пока не понимаю баг это или фича поэтому буду держать этот вопрос на контроле.
Так как ключ найден то стоит привязать этот Кекс алгоритм к этому микротику. Для этого пропишем в конфиг ${HOME}/.ssh/config следующую секцию:

mcedit ~/.ssh/config
Host 192.168.88.1
        PubkeyAcceptedKeyTypes +ssh-dss
        HostKeyAlgorithms=+ssh-dss
        KexAlgorithms diffie-hellman-group14-sha1

После этого можно нормально подключиться к микротику по ssh, и побовать обновить его прошивку если прошивка для него существует. Лично я предпочитаю OpwnWRT, что и другим советую. Хотя на мой взгляд среди проприетарных прошивок mikrotik имеет лучшие даже если их сравнивать с Linksys. Чего никак не скажешь о всём остальном “домашне-офисном” сетевом оборудовании.

Конечно внимательный читатель заметил опцию ssh-dss которая добавляется (+) к существующим по умолчанию или добавленным в конфиге ранее. Эта опция появилась после обновления на Fedora 23 и была вызвана следующей ошибкой:

Unable to negotiate with 192.168.88.1 port 22: no matching host key type found. Their offer: ssh-dss

Обновляя ssh клиент имейте запасной старый, чтобы не попасть “под раздачу” когда в этот самый момент у клиента что-то упадёт и потребует оперативного вмешательства. Не менее важно ведение учёта всех хостов с которыми вы работаете и автоматизация тестирования стандартных процедур, например логина для ssh клиентов и серверов.

Опцию можно передать также и в командной строке.

ssh -oKexAlgorithms=diffie-hellman-group14-sha1 192.168.88.1

Как я могу заставить SSH дать ключ RSA вместо ECDSA?

Просто для того, чтобы улучшить ответ Свиночника, который содержит мертвую ссылку для поиска старого списка алгоритмов.

Сначала определитесь со списком алгоритмов. Чтобы найти старый список, используйте ssh -vv:

ssh -vv somehost

И найдите две строки, например «алгоритмы ключа хоста: …», где первая — это предложение сервера, а вторая — клиентская. Или, чтобы выбрать эти две строки автоматически, попробуйте это (и для выхода нажмите Ctrl + D):

ssh -vv somehost 2>&1 | grep "host key algorithms:"

Теперь отфильтруйте его … вы должны удалить все dss / dsa, поскольку они давно устарели, и вы также хотели удалить ecdsa (как я), например, если у вас было:

[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

В итоге вы должны получить:

[email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

Теперь отредактируйте ваш конфиг. Для вашей собственной конфигурации:

vim ~/.ssh/config

Для общесистемной конфигурации:

sudo vim /etc/ssh/ssh_config

Добавить новую строку, либо глобально:

HostKeyAlgorithms [email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

или для конкретного хоста (не идеально для конфигурации сервера):

Host somehost
    HostKeyAlgorithms [email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

Вместо введенного мною списка вставьте список, полученный из вывода ssh -vv, не включая часть «алгоритмы ключа хоста:».

ssh запрашивает пароль, хотя у меня есть мои ключи

I’m working with a some git repositories in a gitlab server inside my company. Today I installed opensuse on my machine and when I tried to clone the repos through ssh, gitlab kept asking me for a password I did not have. Before opensuse I had ubuntu and everything worked just fine.

I have generated my keys and updated my public one to the gitlab server (which I have no access to).

I tried using my gitlab password and I get nothing but:

Permission denied, please try again

And on the third try I get:

Permission denied (publickey,password). fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

This is my open ssh version:

OpenSSH_6.6.1p1, OpenSSL 1.0.1k-fips 8 Jan 2015

My suse version:

openSUSE 13.2 (Harlequin) (x86_64) 64-bit

And this is the trace for sshing gitlab:

OpenSSH_6.6.1, OpenSSL 1.0.1k-fips 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to gitlab.enterprise.it [10.254.150.182] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/facundo/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/facundo/.ssh/id_rsa type 1
debug1: identity file /home/facundo/.ssh/id_rsa-cert type -1
debug1: identity file /home/facundo/.ssh/id_dsa type -1
debug1: identity file /home/facundo/.ssh/id_dsa-cert type -1
debug1: identity file /home/facundo/.ssh/id_ecdsa type -1
debug1: identity file /home/facundo/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/facundo/.ssh/id_ed25519 type -1
debug1: identity file /home/facundo/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH_6.6.1* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "gitlab.enterprise.it" from file "/home/facundo/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/facundo/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSh3_MSG_KEXINIT sent
debug1: SSh3_MSG_KEXINIT received
debug2: kex_parse_kexinit: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],[email protected],[email protected],[email protected],ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: setup [email protected]
debug1: kex: server->client aes128-ctr [email protected] none
debug2: mac_setup: setup [email protected]
debug1: kex: client->server aes128-ctr [email protected] none
debug1: sending SSh3_MSG_KEX_ECDH_INIT
debug1: expecting SSh3_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA f3:57:5c:28:52:8c:de:0a:58:6e:34:be:bf:72:90:e4 [MD5]
debug3: load_hostkeys: loading entries for host "gitlab.enterprise.it" from file "/home/facundo/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/facundo/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "10.254.150.182" from file "/home/facundo/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/facundo/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'gitlab.enterprise.it' is known and matches the ECDSA host key.
debug1: Found key in /home/facundo/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSh3_MSG_NEWKEYS sent
debug1: expecting SSh3_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSh3_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSh3_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSh3_MSG_SERVICE_ACCEPT received
debug2: key: /home/facundo/.ssh/id_rsa (0x7f6873bd97a0),
debug2: key: /home/facundo/.ssh/id_dsa ((nil)),
debug2: key: /home/facundo/.ssh/id_ecdsa ((nil)),
debug2: key: /home/facundo/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/facundo/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/facundo/.ssh/id_dsa
debug3: no such identity: /home/facundo/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/facundo/.ssh/id_ecdsa
debug3: no such identity: /home/facundo/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/facundo/.ssh/id_ed25519
debug3: no such identity: /home/facundo/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected]'s password:

I have googled a lot yet I did not find a solution for my problem. Do you know what could be happening?

I updated the ssh connection trace to gitlab as I was told I was attempting to connect with two possible keys, now there should be just one RSA key.

I tried cloning from a bitbucket repository and I succeded. I also succeded at connecting to an other computer through SSH so I’m almost shure SSH is not the issue here, am I right?

Also, I compared an other computer’s ssh trace to gitlab (that can connect to it) and they start to differ in these final lines:

Succesful computer:

[...]
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/username/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp f4:73:b3:7d:49:0d:4d:2b:a3:42:32:6c:49:c7:cf:e9
debug3: sign_and_send_pubkey: RSA f4:73:b3:7d:49:0d:4d:2b:a3:42:32:6c:49:c7:cf:e9
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to gitlab.enterprise.it ([10.254.150.182]:22).
debug2: fd 5 setting O_NONBLOCK
debug1: channel 0: new [client-session]
[...]

My computer:

[...]
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/facundo/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/facundo/.ssh/id_dsa
debug3: no such identity: /home/facundo/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/facundo/.ssh/id_ecdsa
debug3: no such identity: /home/facundo/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/facundo/.ssh/id_ed25519
debug3: no such identity: /home/facundo/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected]'s password:

OpenSSH: устаревшие параметры

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

Когда клиент SSH подключается к серверу, каждая сторона предлагает списки подключений. параметры к другому.Это с соответствующими ключевое слово ssh_config:

• KexAlgorithms : методы обмена ключами, которые используются для генерации ключи для каждого соединения
• HostkeyAlgorithms : алгоритмы открытого ключа, принятые для SSH сервер для аутентификации на SSH-клиенте
• Ciphers : шифры для шифрования соединения
• MAC-адреса : коды аутентификации сообщений, используемые для обнаружения трафика модификация

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

Если клиент и сервер не могут согласовать общий набор параметров тогда соединение не будет установлено. OpenSSH (7.0 и выше) создаст сообщение об ошибке, подобное этому:

Невозможно согласовать с legacyhost: не найдено подходящего метода обмена ключами.
Их предложение: diffie-hellman-group1-sha1
 

В этом случае клиент и сервер не смогли согласовать ключ алгоритм обмена. Сервер предлагал только один метод Диффи-Хеллман-Группа1-Sha1 .OpenSSH поддерживает этот метод, но не включает его по умолчанию, потому что он слабый и в пределах теоретического дальность так называемой атаки Logjam.

Несколько связанных опций вступят в игру позже во время аутентификации пользователя.

• PubkeyAcceptedKeyTypes (ssh / sshd): открытый ключ алгоритмы, которые будут предприняты клиентом и приняты сервером для аутентификации с открытым ключом (например, через .ssh / authorized_keys )
• HostbasedKeyTypes (ssh) и HostbasedAcceptedKeyTypes (sshd): типы ключей, которые будут предприняты клиентом и приняты сервер для аутентификации на основе хоста (.например через .rhosts или .shosts )

Несоответствие между клиентом и сервером во время аутентификации вызовет аутентификация не удалась, несмотря на то, что она кажется настроенной. Например, ключ пользователя ssh-dss может быть указан в .ssh / authorized_keys , но может не пройти аутентификацию, потому что, по умолчанию sshd не принимает этот тип ключа.

Лучшее решение для этих сбоев — обновить программное обеспечение на другой конец и / или заменить слабые ключевые типы более безопасными современными типами.OpenSSH отключает только те алгоритмы, которые мы активно не рекомендую использовать, потому что они известны своей слабостью. В некоторых случаях это может быть не сразу возможно, поэтому вам может потребоваться временно повторно включите слабые алгоритмы, чтобы сохранить доступ.

В случае вышеупомянутого сообщения об ошибке OpenSSH можно настроить для включения diffie-hellman-group1-sha1 алгоритм обмена ключами (или любой другой, отключенный по умолчанию) с использованием параметр KexAlgorithms , либо в командной строке:

ssh -oKexAlgorithms = + diffie-hellman-group1-sha1 пользователь @ legacyhost
 

или в ~ /.ssh / config файл:

Хост somehost.example.org
KexAlgorithms + diffie-hellman-group1-sha1
 

‘+’ Перед списком указывает ssh на добавить алгоритм по умолчанию установленный клиентом, а не заменять дефолт. Добавив, вы автоматически обновитесь до лучшего поддерживаемый алгоритм, когда сервер начинает его поддерживать.

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

Невозможно согласовать с legacyhost: соответствующий тип ключа хоста не найден.Их предложение: ssh-dss
 

OpenSSH 7.0 и выше аналогичным образом отключают ssh-dss (DSA) алгоритм открытого ключа. Он тоже слабый, и мы не рекомендуем его использовать. Его можно повторно включить с помощью конфигурации HostKeyAlgorithms . вариант:

ssh -oHostKeyAlgorithms = + пользователь ssh-dss @ legacyhost
 

или в файле ~ / .ssh / config :

Хост somehost.example.org
HostKeyAlgorithms + ssh-dss
 

В зависимости от конфигурации сервера возможно другое подключение параметры, которые невозможно согласовать.Вы можете найти Ciphers и / или MAC-адреса Параметры конфигурации , полезные для их включения. Это также можно запросить, какие алгоритмы поддерживает ssh:

ssh -Q cipher # Список поддерживаемых шифров
ssh -Q mac # Список поддерживаемых MAC-адресов
ssh -Q key # Список поддерживаемых типов открытых ключей
ssh -Q kex # Список поддерживаемых алгоритмов обмена ключами
 

Наконец, также можно запросить конфигурацию, которая на самом деле является ssh использование при попытке подключения к определенному хосту с помощью -G вариант:

ssh -G пользователь @ somehost.example.com
 

в котором будут перечислены все параметры конфигурации, включая выбранные значения для Ciphers , MACs , HostKeyAlgorithms и KexAlgorithms параметров.

веб-хостинг — Невозможно согласовать с XX.XXX.XX.XX: соответствующий тип ключа хоста не найден. Их предложение: ssh-dss

Хочу немного поработать с решением для серверной части. Итак, сервер говорит, что не поддерживает DSA, это потому, что клиент openssh не активирует его по умолчанию:

OpenSSH 7.0 и выше аналогичным образом отключают алгоритм открытого ключа ssh-dss (DSA). Он тоже слабый, и мы не рекомендуем его использовать.

Итак, чтобы исправить это на стороне сервера, я должен активировать другие ключевые алгоритмы, такие как RSA или ECDSA. У меня просто была такая проблема с сервером в локальной сети. Предлагаю следующее:

Обновите openssh:

  yum обновить openssh-server
  

Объедините новые конфигурации в sshd_config, если есть sshd_config.rpmnew.

Убедитесь, что в / etc / ssh / есть ключи хостов.Если не сгенерировать новые, см. man ssh-keygen .

  $ ll / etc / ssh /
всего 580
-rw-r - r--. 1 root root 553185 3 марта 2017 модули
-rw-r - r--. 1 root root 1874 3 марта 2017 г. ssh_config
drwxr-xr-x. 2 root root 4096 17 апр, 17:56 ssh_config.d
-rw -------. 1 root root 3887 3 марта 2017 г. sshd_config
-rw-r -----. 1 корень ssh_keys 227 30 августа 15:33 ssh_host_ecdsa_key
-rw-r - r--. 1 root root 162 30 августа 15:33 ssh_host_ecdsa_key.pub
-rw-r -----. 1 корень ssh_keys 387 30 августа 15:33 ssh_host_ed25519_key
-rw-r - r--.1 root root 82 30 августа 15:33 ssh_host_ed25519_key.pub
-rw-r -----. 1 корень ssh_keys 1675 30 августа 15:33 ssh_host_rsa_key
-rw-r - r--. 1 root root 382 30 августа 15:33 ssh_host_rsa_key.pub
  

Проверьте в / etc / ssh / sshd_config конфигурацию HostKey. Это должно позволить настройку RSA и ECDSA. (Если все они закомментированы по умолчанию, это также разрешит RSA, см. В man sshd_config часть HostKey).

  # HostKey для версии протокола 1
#HostKey / etc / ssh / ssh_host_key
# HostKeys для версии протокола 2
HostKey / и т. Д. / Ssh / ssh_host_rsa_key
#HostKey / etc / ssh / ssh_host_dsa_key
HostKey / и т. Д. / Ssh / ssh_host_ecdsa_key
HostKey / и т. Д. / Ssh / ssh_host_ed25519_key
  

Для клиентской стороны создайте ключ для ssh (не DSA, как в вопросе), просто выполнив следующие действия:

  ssh-keygen
  

После этого, поскольку существует больше опций, чем ssh-dss (DSA), клиент openssh (> = v7) должен подключиться с помощью RSA или лучшего алгоритма.

Вот еще одна хорошая статья.

Это мой первый ответ на вопрос, я приветствую предложения: D.

— RSA против DSA для ключей аутентификации SSH

Математика может не иметь значения. Эта ветка кажется еще до Сноудена. Вот статья Рейтер от 20 декабря 2013 г .:

(Рейтер) — как ключевая часть кампании по внедрению программного обеспечения для шифрования. что он может взломать широко используемые компьютерные продукты, США Агентство национальной безопасности заключило секретный контракт на 10 миллионов долларов с RSA, одна из самых влиятельных фирм в области компьютерной безопасности промышленность, как стало известно Рейтер.

Документы, просочившиеся бывшим подрядчиком АНБ Эдвардом Сноуденом, показывают, что АНБ создало и обнародовало ошибочную формулу генерации случайных числа, чтобы создать «черный ход» в продуктах для шифрования, Нью-Йорк Об этом сообщает Times в сентябре. Позже агентство Reuters сообщило, что RSA стала самый важный распространитель этой формулы, превратив ее в программный инструмент под названием Bsafe, который используется для повышения безопасности в персональные компьютеры и многие другие товары.

До сих пор не разглашалось, что RSA получила 10 миллионов долларов в результате сделки, которая установить формулу NSA как предпочтительный метод или метод по умолчанию для числа поколения в программном обеспечении BSafe, согласно двум знакомым источникам с контрактом.Хотя эта сумма может показаться ничтожной, она представляла более трети дохода соответствующего подразделения RSA данные по ценным бумагам были приняты в течение всего предыдущего года.

Во время этого подкаста Science Friday Ира спрашивает Мэтта Грина, Мартина Хеллмана (изобретателя криптографии с открытым ключом) и Фила Циммермана (создателя PGP), что, по их мнению, взломало АНБ:

(около 17:26)

Ира : Какие из известных нам вещей взломано АНБ?

Мэтт : Итак, мы слышали ряд вещей, которым, вероятно, можем доверять.… Генераторы случайных чисел… мы знаем что АНБ через NIST … весьма вероятно, открыло лазейки в некоторых из тех стандартных алгоритмов, которые позволяют им существенно нарушить эти системы целиком.

Ира : Вы имеете в виду, что АНБ создало эти лазейки?

Мэтт : Совершенно верно. Итак, NIST работает с АНБ — и они обязаны это делать по закону. Мы думали, что АНБ помогает NIST, разрабатывая больше безопасные стандарты для использования американцами. Теперь мы подозреваем — и имеем веские доказательства, чтобы поверить — что ситуация была именно такой противоположный; что NIST использовался для разработки стандартов, которые АНБ может сломаться.

Принимая во внимание эти недавние открытия, сила алгоритмов кажется в значительной степени несущественной. RSA, похоже, была частной компанией, каким-то образом купленной АНБ, а DSA была создана самим NIST, который, по мнению этих экспертов, в значительной степени является прикрытием для криптографических исследований АНБ.

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

Выберите тот, который является самым быстрым для того, что вы хотите.В моем случае я повторно использую один и тот же ключ для множества вещей, поэтому более высокая скорость генерации DSA менее желательна. Кроме того, возможно, есть какая-то дикая вероятность, что RSA на самом деле была независимой организацией от NIST и NSA, тогда как мы знаем, что DSA был создан NIST.

Лично я просто использую 1028-битные ключи, потому что, как мы видели, это действительно не имеет значения, если только кто-то не предъявляет к вам каких-либо требований, которые все еще полагают, что более крупные ключи защитят вас. Все это в значительной степени просто раздражает любого, кто пытается проникнуть внутрь.

для SSH, неспособного согласовать ошибки

Это краткое руководство, которое может помочь не только тестерам на проникновение, но и сетевым инженерам, администраторам и другим специалистам, которые работают с сетевым оборудованием, старыми хранилищами, встроенными системами, киосками и множеством других устаревших систем с интерфейсом SSH (tcp / 22).

Мы собираемся поговорить о проблемах совместимости с SSH и о том надоедливом SSH, который не может согласовать ошибки входа в систему, об ошибках, связанных с ключом хоста, и многом другом.И в конце мы представим решение, как исправить все эти ошибки раз и навсегда.

Введение

Поскольку этот веб-сайт в первую очередь посвящен тестированию на проникновение, я собираюсь описать проблему с точки зрения тестера на проникновение.

Одним из типичных действий, выполняемых во время тестов на проникновение в инфраструктуру, являются атаки входа в систему на интерфейсы SSH (также известный как брутфорс входа в систему через SSH).

Идея перебора входа в систему SSH состоит в том, чтобы идентифицировать системы и устройства в сети, настроенные со слабыми учетными данными и / или учетными данными по умолчанию.

В сети всегда есть системы, которые можно взломать таким образом. И это верно даже для зрелой среды. Пентестеры обычно находят такие случаи с помощью автоматических инструментов, таких как:

• Metasploit
• Medusa
• Hydra
• Nmap
• …

Теперь, чем больше среда, тем больше обычно обнаруживаются действительные учетные данные. Следующий список определенно не редкость, чтобы найти в среде среднего или большего размера:

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

Итак, как нам это сделать? Я не знаю, как вы это делаете, но я обычно вручную проверяю каждый экземпляр с помощью стандартного клиента ssh (OpenSSH), доступного в моей системе (обычно Kali Linux), и исследую каждый случай вручную.

Проблема

Но проблема в следующем: много раз клиент SSH не может подключиться к удаленной системе из-за ошибки согласования SSH.Вот некоторые из типичных сообщений об ошибках:

• Соответствующий шифр не найден. Их предложение: aes256-cbc, aes192-cbc, aes128-cbc, 3des-cbc
• Не найдено подходящего метода обмена ключами. Их предложение: diffie-hellman-group1-sha1
• Соответствующий тип ключа хоста не найден. Их предложение: ssh-dss
• DH GEX group вне диапазона

Например:

  # ssh [адрес электронной почты защищен]
Невозможно согласовать с 10.5.21.113 порт 22: не найден соответствующий тип ключа хоста. Их предложение: ssh-dss  

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

Эти устаревшие устройства поддерживают только слабые и устаревшие наборы шифров, устаревшие методы обмена ключами и т. Д. А наш ssh-клиент больше не доверяет этим старым методам (по умолчанию), поэтому мы не можем подключиться.

Итак, что нам делать?

Хорошая новость заключается в том, что обычно мы всегда можем найти обходной путь (решение) в Интернете, которое решает нашу конкретную проблему с подключением к устройству — обычно путем добавления дополнительной опции к клиенту ssh в командной строке:

  # ssh -oHostKeyAlgorithms = + ssh-dss [адрес электронной почты защищен]  

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

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

Примеры ошибок входа по SSH

Вот некоторые из типичных проблем совместимости входа в систему SSH и их обходные пути.

Соответствующий метод обмена ключами не найден. Их предложение: diffie-hellman-group1-sha1

Типичное сообщение об ошибке SSH:

  # ssh [адрес электронной почты защищен]
Невозможно согласовать с портом 22 10.200.180.62: не найдено подходящего метода обмена ключами.Их предложение: diffie-hellman-group1-sha1  

Обходной путь (здесь):

  # ssh -oKexAlgorithms = + diffie-hellman-group1-sha1 [адрес электронной почты защищен]  

Соответствующий шифр не найден. Их предложение: aes256-cbc, aes192-cbc, aes128-cbc, 3des-cbc

Типичное сообщение об ошибке SSH:

  # ssh [адрес электронной почты защищен]
Невозможно согласовать с 192.168.2.44 порт 22: соответствующий шифр не найден. Их предложение: aes256-cbc, aes192-cbc, aes128-cbc, 3des-cbc  

Обходной путь (здесь):

  # ssh -c aes256-cbc [защита электронной почты]  

Соответствующий тип ключа хоста не найден.Их предложение: ssh-dss

Типичное сообщение об ошибке SSH:

  # ssh [адрес электронной почты защищен]
Невозможно согласовать с 192.168.2.100 порт 22: соответствующий тип ключа хоста не найден. Их предложение: ssh-dss  

Обходной путь (можно найти здесь или здесь):

  # ssh -oHostKeyAlgorithms = + ssh-dss [адрес электронной почты защищен]  

Группа DH GEX вне допустимого диапазона

Типичное сообщение об ошибке SSH:

  # ssh [адрес электронной почты защищен]
ssh_dispatch_run_fatal: подключение к 10.2.100.41 порт 22: группа DH GEX вне допустимого диапазона  

Обходной путь (можно найти здесь или здесь):

  # ssh -o KexAlgorithms = diffie-hellman-group1-sha1, [электронная почта защищена], ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group-exchange-sha256, diffie -hellman-group14-sha1 [адрес электронной почты защищен]  

Иногда эти обходные пути решают одну проблему только для того, чтобы обнаружить, что есть еще одна / другая проблема, после чего мы должны снова гуглить и добавлять другой параметр командной строки.

Но не более того! Вот как мы можем решить все эти проблемы согласования входа в систему SSH раз и навсегда.

Окончательное решение для входа по SSH (исправить все)

Чтобы исправить все эти проблемы совместимости с SSH, мы можем просто временно включить все устаревшие методы шифрования, которые в настоящее время поддерживает наш SSH-клиент. Это означает включить все:

• Коды аутентификации сообщений (MAC)
• Методы обмена ключами
• Алгоритмы ключей хоста
• Шифры

Чтобы получить список всех поддерживаемых алгоритмов, шифров и методов, которые в настоящее время поддерживает наш SSH-клиент, мы можем использовать ‘-Q ‘вариант вроде этого:

  ssh -Q mac
ssh -Q kex
ssh -Q ключ
ssh -Q шифр  

Например:

И теперь все, что нам нужно сделать, это немного переформатировать его и поместить в файл конфигурации нашего SSH-клиента в нашей папке HOME ~ /.ssh / config .

Итак, вот — окончательное исправление всех ошибок согласования входа в SSH :

  {
echo -n 'Шифры'
шифр ssh -Q | tr '\ n' ',' | sed -e 's /, $ //'; эхо

echo -n 'MAC-адреса'
ssh -Q mac | tr '\ n' ',' | sed -e 's /, $ //'; эхо

echo -n 'HostKeyAlgorithms'
ключ ssh -Q | tr '\ n' ',' | sed -e 's /, $ //'; эхо

echo -n 'KexAlgorithms'
ssh -Q kex | tr '\ n' ',' | sed -e 's /, $ //'; эхо

} >> ~ / .ssh / config  

Приведенная выше команда добавит следующие параметры в конфигурацию вашего SSH-клиента:

  Шифры 3des-cbc, aes128-cbc, aes192-cbc, aes256-cbc, [защита электронной почты], aes128-ctr, aes192-ctr, aes256-ctr, [защита электронной почты], [защита электронной почты], [защита электронной почты]
MAC-адреса hmac-sha1, hmac-sha1-96, hmac-sha2-256, hmac-sha2-512, hmac-md5, hmac-md5-96, [защита электронной почты], [защита электронной почты], [защита электронной почты], [электронная почта защищенный], [электронный адрес защищен], [электронный адрес защищен], [электронный адрес защищен], [электронный адрес защищен], [электронный адрес защищен], [электронный адрес защищен]
HostKeyAlgorithms ssh-ed25519, [защита электронной почты], ssh-rsa, ssh-dss, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, [защита электронной почты], [защита электронной почты], [защита электронной почты] , [электронная почта защищена], [электронная почта защищена]
KexAlgorithms diffie-hellman-group1-sha1, diffie-hellman-group14-sha1, diffie-hellman-group14-sha256, diffie-hellman-group16-sha512, diffie-hellman-group18-sha512, diffie-hellman-group-exchange-sha1 , diffie-hellman-group-exchange-sha256, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, curve25519-sha256, [защита электронной почты], [защита электронной почты]  

В зависимости от конкретной версии клиента SSH он может выглядеть немного иначе, но дело в том, что он активирует ВСЕ методы и шифры, которые поддерживает ваш текущий клиент SSH.

Теперь мы должны иметь возможность без проблем подключаться к любому устаревшему устройству или системе в сети.

Заключительные слова

Убедитесь, что это временное решение — никогда не используйте его в производственной системе в качестве долгосрочного решения. Обязательно отмените изменения, если они вам больше не понадобятся.

Представленное здесь решение работает путем включения всех шифров, методов и алгоритмов обмена ключами, которые были отключены в нашем клиенте OpenSSH из-за их недостатков и недостатков безопасности.

Если это решение все еще не устранило вашу конкретную проблему входа в систему согласования SSH, вам просто нужно получить другую (старую) версию клиента OpenSSH или получить другой клиент SSH.

Если этот пост был полезен для вас и вы хотели бы получить больше подобных советов, подпишитесь на нашу рассылку, подпишитесь на нас в Twitter и Facebook и получайте уведомления о новых дополнениях!

Соответствующий ключ хоста не найден

Я не могу настроить ssh-ключ между моей машиной и битбакетом.Я думаю, это как-то связано с тем, как генерируется ключ и используется шифр, но мне неясно, как это исправить.

команда для генерации ключа:

 ssh-keygen -t rsa 

Я помещаю ее в битбакет, и она принимает ключ без проблем, но когда я ее проверяю:

 `Невозможно согласовать с 18.205.93.2 порт 22: соответствующий тип ключа хоста не найден. Их предложение: ssh-dss, ssh-rsa` 

Я четко указал rsa. Я думаю, что по умолчанию должен использоваться rsa2.Моя версия ssh:

OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 января 2017 г.

, когда я просто выполняю ssh -vvv git @ bitbucket.org, я получаю следующее:

 OpenSSH_7.4p1, OpenSSL 1.0 .2k-fips 26 января 2017 г. 
 debug1: чтение данных конфигурации / etc / ssh / ssh_config 
 debug1: / etc / ssh / ssh_config строка 58: Применение параметров для * 
 debug2: разрешение порта 22 "bitbucket.org" 
 debug2: ssh_connect_direct : needpriv 0 
 debug1: Подключение к bitbucket.org [18.205.93.2] порт 22. 
 debug1: Соединение установлено.
 debug1: файл идентификаторов /home/kyleh/.ssh/id_rsa тип 1 
 debug1: key_load_public: нет такого файла или каталога 
 debug1: файл идентификаторов /home/kyleh/.ssh/id_rsa-cert тип -1 
 debug1: key_load_public: Нет такого файла или каталога 
 debug1: файл идентификаторов /home/kyleh/.ssh/id_dsa type -1 
 debug1: key_load_public: Нет такого файла или каталога 
 debug1: файл идентификаторов /home/kyleh/.ssh/id_dsa-cert type - 1 
 debug1: key_load_public: нет такого файла или каталога 
 debug1: файл идентификации / home / kyleh /.ssh / id_ecdsa type -1 
 debug1: key_load_public: нет такого файла или каталога 
 debug1: identity file /home/kyleh/.ssh/id_ecdsa-cert type -1 
 debug1: key_load_public: нет такого файла или каталога 
 debug1: identity file /home/kyleh/.ssh/id_ed25519 type -1 
 debug1: key_load_public: Нет такого файла или каталога 
 debug1: файл идентификации /home/kyleh/.ssh/id_ed25519-cert type -1 
 debug1: Включение режима совместимости для протокола 2.0 
 debug1: строка локальной версии SSH-2.0-OpenSSH_7.4 
 debug1: версия удаленного протокола 2.0, версия удаленного программного обеспечения conker_1.1.31-8625750 app-131 
 debug1: нет совпадения: conker_1.1.31-8625750 app-131 
 debug2: настройка fd 3 O_NONBLOCK 
 debug1: аутентификация на bitbucket.org: 22 как 'git' 
 debug3: отправить пакет: тип 20 
 debug1: SSh3_MSG_KEXINIT отправлен 
 debug3: получить пакет: тип 20 
 debug1: SSh3_MSG_KEXINIT получил 
 debug2: предложение KEXINIT локального клиента 
 debug2: KEX curve-shams19-25, curve sha256 @ libssh.org, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group-exchange-sha256, diffie-hellman-group16-sha512, diffie-hellman-group18-sha512, diffie-hellman- group-exchange-sha1, diffie-hellman-group14-sha256, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1, ext-info-c 
 debug2: ключевые алгоритмы хоста: ssh-ed25519 
 debug2: ciphers ctos : chacha20-poly1305 @ openssh.com, aes128-ctr, aes192-ctr, aes256-ctr, aes128-gcm @ openssh.com, aes256-gcm @ openssh.com, aes128-cbc, aes192-cbc, aes256-cbc 
 : ciphers stoc: chacha20-poly1305 @ openssh.com, aes128-ctr, aes192-ctr, aes256-ctr, aes128-gcm @ openssh.com, aes256-gcm @ openssh.com, aes128-cbc, aes192-cbc, aes256-cbc 
 debug2: MAC-64 ctos: umac -etm @ openssh.com, umac-128-etm @ openssh.com, hmac-sha2-256-etm @ openssh.com, hmac-sha2-512-etm @ openssh.com, hmac-sha1-etm @ openssh.com , umac-64 @ openssh.com, umac-128 @ openssh.com, hmac-sha2-256, hmac-sha2-512, hmac-sha1 
 debug2: MACs stoc: umac-64-etm @ openssh.com, umac- 128-etm @ openssh.com, hmac-sha2-256-etm @ openssh.com, hmac-sha2-512-etm @ openssh.com, hmac-sha1-etm @ openssh.com, umac-64 @ openssh.com, umac-128 @ openssh.com, hmac-sha2-256, hmac-sha2-512, hmac-sha1 
 debug2: сжатие ctos: none, zlib @ openssh.com, zlib 
 debug2 : сжатие stoc: none, zlib @ openssh.com, zlib 
 debug2: languages ​​ctos: 
 debug2: languages ​​stoc: 
 debug2: first_kex_follows 0 
 debug2: зарезервировано 0 
 debug2: одноранговый сервер Предложение KEXINIT 
 debug2: алгоритмы KEX- curve25519 sha256 @ libssh.org, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1 
 debug2: алгоритмы ключей хоста: ssh-dss, ssh-rsa 
 debug2: шифры ctos: aes128-ctr, aes192-ctr, aes256-ctr, aes128-gcm @ openssh.com, chacha20-poly1305 @ openssh.com, arcfour256, arcfour128 
 debug2: ciphers stoc: aes128-ctr, aes192-ctr, aes256-ctr, aes128-gcm @ openssh.com, chacha20-poly1305 @ openssh256.com, arcfour128.com, arcfour128.com 
 debug2: MAC-адреса ctos: hmac-sha2-256-etm @ openssh.com, hmac-sha2-256, hmac-sha1, hmac-sha1-96 
 debug2: MACs stoc: [email protected] , hmac-sha2-256, hmac-sha1, hmac-sha1-96 
 debug2: сжатие ctos: нет 
 debug2: сжатие stoc: нет 
 debug2: languages ​​ctos: 
 debug2: languages ​​stoc: 
 debug2: first_kex_follows 0 
 debug2: зарезервировано 0 
 debug1: kex: algorithm: curve25519-sha256 @ libssh.org 
 debug1: kex: алгоритм ключа хоста: (нет совпадения) 
 Невозможно согласовать с 18.205.93.2 порт 22: соответствующий тип ключа хоста не найден. Их предложение: ssh-dss, ssh-rsa 

Я не совсем уверен, почему происходит отключение, и некоторые пояснения были бы полезны.

Ура

Простое проникновение в ваш (веб) сервер и сеть — или почему раскрытие ~ / .ssh / — плохая идея | Себастьян Ниф

В прошлом году я провел небольшое исследование того, как экспонируется ~ /.ssh / на веб-сервере может привести к полному pwnage. Вот сделка:

• Я видел это в дикой природе.
• На реальных веб-серверах.
• Эксплуатируется крупными компаниями.

Поскольку это становится простым способом RCE для вашего веб-сервера, я здесь, чтобы поделиться своими знаниями, чтобы вы могли защитить себя.

Папка ~ / .ssh / обычно является местом, где клиент и сервер SSH хранят некоторые (конфигурационные) файлы:

• SSH-сервер использует ~ /.ssh / authorized_keys , чтобы проверить, какой открытый ключ разрешен для подключения.
• SSH-клиент использует ~ / .ssh / id_ * (т.е. id_rsa , id_dsa , id_ed25519 ) для хранения открытых / закрытых пар ключей по умолчанию.
• SSH-клиент использует ~ / .ssh / known_hosts , чтобы запомнить, к каким хостам он подключился и каков их hostkey.
• Клиент SSH использует ~ / .ssh / config для настройки соединений на основе имен хостов, т.е.е. чтобы установить другое имя пользователя.

Поскольку большинство серверов в Интернете используют сервер SSH для удаленного администрирования, определенно существуют некоторые веб-серверы, которые также могут это делать.

Кроме того, существуют веб-серверы, на которых пользователь www-data имеет эти файлы. Для некоторых из них домашний каталог www-data — это DocumentRoot , так что становится доступным ~ / .ssh / .

Это становится проблемой, когда учетная запись www-data использовалась для запуска SSH на:

• клонировать репозиторий через SSH
• отправить «горячие исправления» обратно в удаленный репозиторий через SSH
• позволяет разработчикам подключаться к серверу как www-data напрямую
• выполнить любую другую операцию на основе SSH

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

Давайте рассмотрим различные файлы и информацию, которую они передают злоумышленнику. Поскольку файлы находятся в домашнем каталоге www-data , злоумышленнику нужно всего лишь отправить несколько запросов, чтобы проверить, существуют ли файлы:

• GET /.ssh/id_rsa et al.
• GET /.ssh/authorized_keys
• GET /.ssh/known_hosts
• ПОЛУЧИТЬ /.ssh / config

id_ * закрытые ключи

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

• id_rsa
• id_dsa
• id_ecdsa
• id_ed25519

Чтобы проверить, является ли полученный файл действительным ключом, можно проверить ----- BEGIN OPENSSH PRIVATE KEY ----- и ----- END OPENSSH PRIVATE KEY ----- В нем струн.Это легко.

На этом этапе администраторам необходимо полагаться на вторую линию защиты: защиту паролем. При создании пары ключей ssh-keygen запрашивает у вас парольную фразу. Судя по собранным мною данным, не более 45% ключей имели парольную фразу . В этом случае злоумышленник должен прибегнуть к грубой силе, чтобы взломать доступное частное лицо. Хотя офлайн-атаки методом перебора коротких паролей становятся все более эффективными и рентабельными.Утечка ключей должна считаться скомпрометированной и заменяться, даже если они были защищены паролем. Пока он не расколется, это вопрос времени.

Это означает, что у злоумышленника есть шанс 50/50 найти пару ключей без ключевой фразы. Вот простой способ проверить, установлен ли пароль:

Следующий ключ не имеет пароля, поэтому ssh-keygen показывает открытую часть:

  [gehaxelt @ LagTop tmp] $ echo "nopw" | ssh-keygen -y -f / tmp / testkey_nopw; эхо $?
SSH-RSA AAAAB3NzaC1yc2EAAAADAQABAAABgQDChfRt3oUp // tmtBN7Unb6fITrsVt / UT6s6tshhwUMn6d + KJNXjuwSPUj5Hl5jGMPTaWm8wHqbg / bPTZsrBTxA1UAwIcPbo267S3wHUzWNIr / ZT + cAEHV94gfnjKEZG6d9SRREZwxeVRobCWpP6gTY3z + 2ZhGSlFasbWUHdSikPjZPB73Wn / GsTISXveL5 + Qj / iTTMpkBU5httK / 2O10OzqpCP5 / 0U8nb089DHYX6QO68zW7wtZ8JpumuK5ogcOBzYEMHSSvY6jDOtRY3lOCQE2bebHxvoCni3jc + Q4prpaOciz / o2fgjclfsz9KrplWIfmgySDw9h3UZrfZOanKqG6HpEOKu8qIrUgX3BwewV3DoSyjHTMVktrTGaWmfYIRMaGGYjqoDLXhizZDy + 6j4ywi3q5ikSg5p0ZOYQhUfpj7L1NdY1vXI9TA9PhPtvbclPAbu5fQ8KTpk3GD + zYeGhD6OT1l22BWWlI / yljBh6mEDySaqSMEsewqYIB40xjrE = gehaxelt @ LagTop
0
  

Если ключ защищен паролем, то эта операция (по праву) не выполняется:

  [gehaxelt @ LagTop tmp] $ echo "nopw" | ssh-keygen -y -f / tmp / testkey_pw; эхо $?
Загрузить ключ "/ tmp / testkey_pw": для расшифровки закрытого ключа предоставлена ​​неверная кодовая фраза.
255
  

На этом этапе злоумышленник выполнил самую сложную часть цепочки эксплойтов и успешно получил действительную пару ключей SSH.

authorized_keys

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

Формат довольно прост и очень легко проверить, является ли загруженный файл /.ssh/authorized_keys действительным или нет:

  SSH-RSA AAAAB3NzaC1yc2EAAAADAQABAAABAQC6MyNlJORnZ4txf3HuVRDTkRGAJ / KkWDOvDSFHja3mUX0KP + 4b8qUDIRSAZ / MMxClbRxZ / raa4vxBWbUa2GHdyHGC6u / iOqJkpKaFihrsujS1gmIcypuPTFEQN6DY2Gf3cQqKmUUATuOkqTBaICzvQQJX7b3bbil / dPfuxbFb8xHp5mZ0EsMt / N7onXLaoWM8nRr9IfvviP + tqXjzYRJ2Ys6XDF4qL9V1W + 64HPfb3fnCXID1iMVk4RR8A9Sb9VPKA1f / k5Y10CPB16 + ZvU0gXcUA8oKXJedcIXPyFhgsqEEbi7QFg4oDLdAzpQnFEAtUcfparO3GFfO2LB / lLWclX путешествия @ путешествия-рс
  

Большинство записей в этом файле начинаются с ssh-rsa , ssh-dss , ssh-ed25519 , ssh-ecdsa .Предполагая, что большинство ключей SSH имеют достаточное количество бит (обычно 4096), попытка факторизации открытых ключей может быть не лучшей идеей.

Однако злоумышленник получит обзор того, сколько (разных) ключей (и разработчиков / администраторов) имеют доступ к серверу, и он может использовать полученную информацию для проведения целевых атак против конкретных разработчиков с целью украсть соответствующий закрытый ключ. .

В некоторых случаях злоумышленник удастся найти открытый ключ полученного закрытого ключа в списке авторизованных ключей.

Теперь ей нужно только угадать правильное имя пользователя, которое обычно бывает любым из них:

• www-данные
• nginx
• apache
• root
  В некоторых случаях ~ / .ssh / config может предоставлять некоторые имена пользователей или подсказки.

В случае успеха злоумышленник получит полноценный SSH-доступ к веб-серверу и сможет выполнить любую команду. Я видел по крайней мере 15 хостов, где это было возможно, но я не буду здесь называть никаких компаний.Буквально это ИГРА НАШЕ , и вся остальная (веб) безопасность нарушена.

known_hosts

Но еще интереснее, если будет открыт файл ~ / .ssh / known_hosts . Если этот файл существует, это означает, что закрытый ключ на сервере использовался для подключения к другим системам.

В зависимости от имен хостов или IP-адресов в этом файле злоумышленник может использовать эту информацию и закрытый ключ для компрометации других систем. Например, она могла бы подключиться к github / gitlab / etc.или постановка, отладка, системы баз данных и т. д.

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

• SSH-RSA
• ssh-dss
• ecdsa-sha2-nistp256
• SSH-ED25519

  raspberrypi.local ECDSA-SHA2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBL7M2qw8pKPjyT0Pq1Mbq / wDsVfjpU846u0n5Pqmub2E96VKvLu8LUJz8dhqZi7bLzlCVgkDNkPmY30mZU3 + OR0 =

| 1 | Nbo4zQcI82GnFf / IgsQtQB3MZDQ = | eabVTCOPm51 + нФ + OvoTJF / qkU4A = SSH-RSA AAAAB3NzaC1yc2EAAAABIwAAAQEAvJ3c8N + oIKcoFty8MboBB2oKjfpTyfa7xb6mXntYUjiisJ + tyGqOhU7bn5EkW412lg6Fze6JnW2UvEXq2YlmqOXDSzS7QqsJS1 / syhytiYI + q0uPbECj3qPXE3QLuBoYI7rzDahiYi3dwlLVNu9n74uBI + ykCFi97 / hVdslgDVb1CCR + 6SMXhqwnUh5LC + ULorkFiFtzTiniKw6X8PIjwkaViCdmaHJRLKQwskhnDfUzrzb7rEwqx977KZetXE44oc7jHNlSRKhQQgOGpQn7mYa + OQMpnU432iFb63Mb85hrBj0npIfOP6zkJvjoUcANSpmzt / 38yvy / G5xAEAEPXQ ==
  

В последнем случае имя хоста хешируется и злоумышленник не может прочитать его напрямую. raspberrypi.local может не быть интересной целью, потому что IP-адрес неизвестен, но злоумышленник может использовать ранее скомпрометированный веб-сервер в качестве узла перехода. Но злоумышленнику лучше найти системы с общедоступными IP-адресами, к которым он может получить доступ из своей системы с помощью скомпрометированного закрытого ключа. 32), но все же достаточно, чтобы немного замедлить злоумышленника, поскольку каждая запись known_hosts имеет свою уникальную соль.Я предположил, что я не первый, кто пришел к идее взломать записи known_hosts , поэтому я погуглил и нашел многообещающее репозиторий на github.

Используя атаку по маске, предоставленную репозиторием, я смог взломать почти 50% записей:

Это неплохие шансы найти другие системы, которые может взломать злоумышленник.

конфигурация

Файл конфигурации клиента SSH обычно содержит такую ​​информацию, как:

• Имена хостов
• Псевдонимы
• Имена пользователей
• Порты

Таким образом, если этот файл раскрывается, он дает злоумышленнику больше информации для компрометации других систем — аналогично known_hosts .

Файл хранится в ~ / .ssh / config и может быть сопоставлен с вышеупомянутыми ключевыми словами.

Цепь эксплойтов RCE

Итак, как мы видели выше, открытие нескольких файлов из ~ / .ssh / может сделать вашу систему открытой для простых RCE-атак. Практически игра окончена, если ваши файлы закрытых ключей SSH доступны на сервере и не защищены паролем. Если вы оставите доступными еще несколько файлов, таких как known_hosts или authorized_keys , то вся ваша сеть может быть скомпрометирована.

Эта цепочка эксплойтов легко автоматизируется, поэтому следует ожидать, что злоумышленники уже (или будут в будущем) сканировать эти файлы и пытаться связать результаты.

Чтобы решить эту проблему, вам вообще не следует размещать эти файлы на веб-сервере!

Используйте пересылку агента или ProxyJump вместо ssh вперед с веб-сервера. (Спасибо @closeparen и @egwynn из HN)

Убедитесь, что этих файлов .ssh / нет в DocumentRoot .

Добавьте специальные правила в конфигурацию вашего веб-сервера, чтобы заблокировать доступ к /.ssh/ .

Следите за вашими журналами на предмет запросов GET на /.ssh/ .

— = —

Соответствующий тип ключа хоста не найден. Их предложение: ssh-rsa, ssh-dss [preauth]

Номер статьи: 249 | Рейтинг: Без рейтинга | Последнее обновление: среда, 16 октября 2019 г., 11:27

‘подходящий тип ключа хоста не найден.Их предложение: ssh-rsa, ssh-dss [preauth] ‘получили эту ошибку в / var / log / secure

Убедитесь, что ‘ ssh_host_rsa_key / ssh_host_dsa_key’ включен в вашем / etc / ssh / sshd_config

Если не включено, добавьте или раскомментируйте следующее в / etc / ssh / sshd_config

HostKey / и т.д. / ssh / ssh_host_rsa_key

HostKey / и т.д. / ssh / ssh_host_dsa_key

К этой статье нет приложений.

Просмотрен 867 раз, начиная с чт, 4 апр.2019 г.

Просмотрен 3272 раза с сб, 18 ноября 2017 г.

Просмотрен 5795 раз, начиная с чт, 15 июня 2017 г.

Просмотрен 3143 раза, начиная с понедельника, 27 апр.2020 г.

С среду, 14 июня 2017 г., просмотрели 3646 раз

Просмотрен 3512 раз, начиная с чт, 23 ноября 2017 г.

Просмотрен 718 раз, начиная с понедельника, 9 декабря 2019 г.

Просмотрен 2591 раз, начиная с чт, 15 июня 2017 г.