SSH -Требуется объяснение аутентификации с открытым ключом RSA
Для такой задачи брандмауэр не нужен. Обратите внимание, что я не говорю, что брандмауэры бесполезны, но вам просто нужно отключить прослушивание всех адресов(0.0.0.0). Наименьшая привилегия для адресов, по которым ваше программное обеспечение может ожидать подключения.
PostgreSQL и MySQL — это разные программы, поэтому они могут иметь разное поведение по умолчанию в отношении сети, доступа пользователей, пути установки, пути к файлам базы данных, поддерживаемых файловых систем и т. д. Вы не можете сопоставлять их только потому, что они являются базами данных. Другая вещь, которая может повлиять на конфигурацию по умолчанию, — это то, что ответственные за эти пакеты в вашем дистрибутиве решили, что программное обеспечение должно использовать по умолчанию.
По умолчанию MySQL прослушивает все сетевые адреса (0.0.0.0), если дистрибутив не настроен иначе, как описано выше.
Возвращаясь к вашему вопросу, чтобы MySQL отвечал только на локальный хост, откройте его файл конфигурации (в большинстве случаев по адресу /etc/my.cnfили/etc/mysql/my.cnf)и добавьте или отредактируйте следующую строку:
bind-address = 127.0.0.1
После этого перезапустите службу mysql (зависит от дистрибутива, обычно systemctl restart mysqlилиsystemctl restart mysqld)
Повторная проверка с помощью команды ss:
ss -lntu | grep mysql
Для фона...
На тему есть отличный ответ на Security Stack Exchange , который ссылается на заметки openssh об отказе от использования ssh -rsa .
Похоже, проблема в том, что исходный алгоритм ssh -rsa (, описанный в RFC 4253 ), опирался на SHA -1 , который в настоящее время в значительной степени не используется для криптографии:
Since 2005, SHA-1 has not been considered secure against well-funded opponents; as of 2010 many organizations have recommended its replacement. NIST formally deprecated use of SHA-1 in 2011 and disallowed its use for digital signatures in 2013. As of 2020, chosen-prefix attacks against SHA-1 are practical.
Но алгоритм подписи использовал SHA -1, а не сам ключ.
Имея это в виду...
If Cisco 4k allow higher PK than ssh-rsa, why it does not work with default ssh settings?
Что изменилось, так это то, что openssh no -больше не разрешает ssh -rsa по умолчанию. Сделанное вами изменение позволяет вашему клиенту принять ssh-rsa. Так что роутер все равно принимает его (, даже если он стонет ). Но в алгоритмах нет строгой иерархии, просто одни «лучше», чем другие. Поэтому разрешение «более высоких» алгоритмов не означает, что маршрутизатор и клиент используют одни и те же «высшие» алгоритмы.
Другая возможная причина заключается в том, что, хотя ваш клиент и маршрутизатор используют общие «лучшие» алгоритмы, они несовместимы с необработанным ключом RSA. Например :они разрешили ssh-сертификаты, но у вас есть ключ и нет сертификата. В этом случае вы можете использовать настройки по умолчанию, но не ваш существующий ключ с настройками по умолчанию.
Is there any connection between key type "ssh-rsa" and allowed PK algorithms
Судя по тому, что я могу найти по теме, да. Их алгоритмы могут быть ограничены одним шифром , но обычно не так сильно заботятся о длине ключа. Ключи — это просто [некоторые] очень большие числа. Неважно, насколько они велики, но алгоритм должен знать, что с ними делать.
Is there any way (I have tried ssh debug and sshd debug) to understand clearly what PK algorithms are supported on server and client like we do with ciphers?
Хотя это немного загадочно, это доступно с отладкой уровня 2 openssh(-vv). Вы увидите debug2: KEX algorithms:...и debug2: host key algorithms:.... Вы также должны увидеть, какой алгоритм был выбран. Существует также отладка третьего уровня (-vvv), если вы хотите копнуть глубже.
Это намного больше, чем кому-либо нужно, но, с другой стороны, это убережет вас от повторения этой проблемы.
Создать новые ключи:
ssh-keygen -t rsa -b 4096 -f "$HOME/.ssh/key_name" -C "purpose_of_key". Дважды нажмите[ENTER]и НЕ вводите кодовую фразу. Это выведет открытый и закрытый ключи.Отправьте новый открытый ключ на вашу удаленную систему (s ).
ssh-copy-id -i ~/.ssh/key_name.pub user@hostnameПосле того, как вы скопировали этот открытый ключ во все удаленные системы, сделайте резервную копию старого ключа (с ныне несуществующими алгоритмами )и перезапишите их.
mv ~/.ssh/key_name.pub ~/.ssh/id_rsa.pubиmv ~/.ssh/key_name ~/.ssh/id_rsa.Протестируйте, войдя в любую из ваших удаленных систем.
Вы только что поменяли свой ключ ssh; в любом случае это нужно делать на периодической основе.