SSH Отпечаток SHA256

что это может быть?

Мамкеры взломали

ip сервера менялся ??

Нет

В known_hosts теперь 2 хеша, один старый, а другой текущий

Учитывая что сервер на ssh ключе наврядли

ну удали их и подключись заново, делов то

так а почему key fingerprint вдруг сменился ни с того ни с сего?

This key is not known by any other names.

У вас хоть старый-то был? А то сейчас окажется, что вы никогда с этой машинки не заходили, вы чего-то обновили и т.д. и т.п.

а почему бы и нет

а где можно историю этих отпечатков посмотреть?

в know_hosts на локальном компе первая запись ecdsa-sha2-nistp256 а вторая уже ssh-ed25519

а если ip моего локального компа сменился то это может этого из-за этого?

Ну вот, уже разницу видите.

Если «локальный комп» это клиент, то нет.

Так мне то что делать? Сервер был скомпрометирован или что? Что значит «разницу видите». Почему отпечаток хоста сменился?

Почему отпечаток хоста сменился?

а ключ сменился?

для начала проверить время изменения /etc/ssh/ssh_host_* на сервере.
Потом проверить когда изменялись конфиги и/или обновлялось ssh на сервере и клиенте.
Выглядит как смена конфигурации по умолчанию

1. все ssh_host файлы в директории /etc/ssh/ от 10 числа и не изменялись
2. /etc/ssh/ssh_config также не изменялся, дата изменений 9.10.2024, как на клиенте посмотреть я не знаю
3. что за смена конфигурации по умолчанию? Как ещё можно проверить сервер? У меня на руках открытый и закрытый ключ, что можно проверить на одинаковость на сервере и у меня на локальной машине? Чтобы убедится что всё одинаково, что у меня на локальной машине, что на сервере

Прикол в том что я много раз заходил по SSH с ключом, но почему то в этот раз он запросил

А заходите от того же пользователя?

что за смена конфигурации по умолчанию?

Обновились.

Да

Типа сам SSH обновился?

Кстати, тогда что означает WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY И ниже пишет It is also possible that a host key has just been changed.

Из за чего это сообщение впринципе появляется?

У меня было просто The authenticity of host can’t be established. Key fingerprint is SHA 256:…….. This key is not known by any other names. Are you sure you want to continue connecting?

В чём разница?

Один из вариантов. Дефолты могли измениться. Но читать «что и когда» надо в changelog-ах.

все ssh_host файлы в директории /etc/ssh/ от 10 числа и не изменялись

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

что за смена конфигурации по умолчанию?

клиент и сервер договариваются какие настройки они будут использовать при установке соединения. Кроме всего прочего там есть список алгоритмов, который будет использоваться при проверке отпечатков. Эти списки задаются как через конфиги, так и прописаны в ssh севрер/клиент (настройки по умолчанию). Если сервер и/или клиент обновлялись, то они могли договориться использовать новый алгоритм, т.к. в новой версии он считается лучшим, например.

У меня на руках открытый и закрытый ключ

у вас на руках отпечаток ключа сервера, вам надо сгенерировать новый руками и сравнить. На вскидку я помню только ssh-keyscan.
Еще можно подключаться к серверу с опцией -vvv и посмотреть, что предлагает клиент и что сервер или попробовать явно указать клиенту HostKeyAlgorithms

Из за чего это сообщение впринципе появляется?

из-за того, что у сервера сменился отпечаток ключа (из тех, что в /etc/ssh)

В чём разница?

в том, что в первом случае хост известный (отпечаток был сохранен), но в данный момент отпечаток отличается от сохраненного, а во втором — это просто неизвестный хост

Это vps на хостинге, дата установки и генерации ключей на локальной машине 10.10.2024, странно что ssh_config от 9 числа. Но в любом случае это же не факт компрометации сервера, это просто что-то обновилось?

что это может быть?

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

в какой файл для логов смотреть?

в какой файл для логов смотреть?

# journalctl

Ну там в это время генерились ключи и больше ничего

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

Ну там в это время генерились ключи и больше ничего

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

Сделал поиск по словам «Accepted publickey for» и что от 10 числа, что от сегодняшнего 14 числа - rsa sha256 одинаковый, о чём это может говорить?

sshd Accepted publickey for «user» from «myip» port …. ssh2: RSA SHA256:xxxxxx и они все одинаковые, от 10.10.2024 до сегодняшнего 14.10.2024 после того как я нажал yes для генерации нового «This key is not known by any other names. Are you sure you want to continue connecting?»

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

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

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

Тоесть сервер в порядке, просто почему то мой комп забыл этот сервак? Сервер оставить в покое, можно выдохнуть?

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

Да. Если бы что-то не то на сервере было, у тебя бы была та другая угрожающая надпись. Но прицины забывания сервера клиентом просто так оставлять по-моему тоже нельзя.

Может быть ты раньше запускал ssh по ip-адресу сервера а теперь по доменному имени? Или у сервера два разных доменных имени есть и ты сейчас с другим чем раньше запустил? Или ты заходишь по ip-адресу и он сменился? Посмотри в логе bash_history на клиенте как ssh команды выглядели раньше и сейчас.

Генерация была на моей локальной машине, потом перенесена на сервер, так что самая это первая генерация в журнале, кстати этот ключ и key-host автоматически генерируется при первом запуске сервера что-ли?

понятно, ну понаблюдаю тогда, может ssh-клиент на локальной машине шалит просто

не, я ВСЕГДА заходил на сервер по SSH по IP.

Просто так «шалить» там нечему.

Ты проверил в bash_history что команды выглядят точно одинаково? Может ip сервера поменялся?

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

дата установки и генерации ключей на локальной машине 10.10.2024

я запутался

все ssh_host файлы в директории /etc/ssh/ от 10 числа и не изменялись

вот это было про сервер или про «локальную машину», если про локальную, то все-таки интересно, что на сервере

Если тот же хост вдруг сменит алгоритм ключа - должна быть та же надпись про «кажется вас хотят взломать». Хотя я не проверял, но было бы очень странно и дыряво если была бы не она. Та надпись что у автора может быть только в одном случае: в known_hosts нужного хоста вообще нет ни в каком виде.

префикс ssh_host_ говорит что это ключи используемых sshd сервером на «хосте» для начальной организации шифроканала.
их пачка генерится при первой установке, глянул в пакет
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key

при этом ключ авторизации пользователя лежит в /home/$USER/.ssh/id_%тип шифра% и может совсем другой системы…

меня чего-то переклинило на REMOTE HOST IDENTIFICATION HAS CHANGED
а тут походу что-то странное с known_hosts

Сделал поиск по словам «Accepted publickey for» и что от 10 числа, что от сегодняшнего 14 числа - rsa sha256 одинаковый, о чём это может говорить?

sshd Accepted publickey for «user» from «myip» port …. ssh2: RSA SHA256:xxxxxx и они все одинаковые, от 10.10.2024 до сегодняшнего 14.10.2024

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

Генерация была на моей локальной машине, потом перенесена на сервер, так что самая это первая генерация в журнале, кстати этот ключ и key-host автоматически генерируется при первом запуске сервера что-ли?

Не совсем. Генерация ключей производится сервисом sshdgenkeys.service при отсутствии любого из следующих файлов:

/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key.pub

При этом существующие файлы приватных ключей не заменяются, а новые публичные создаются только вместе с приватными (.pub-файлы вообще не используются приложениями из openssh, а создаются только ради удобства пользователя). Так как при первом запуске сервера эти файлы отсутствуют, то автоматически производится их генерация.

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

Рискну предположить, что Вы добавляли ключ сервера созданный на Вашей машине, уже после того, как первый раз зашли на сервер по ssh. Вероятно, Вы использовали scp, либо rsync, для переноса созданного ключа с локальной машины на сервер, и после этого новых ssh-подключений до 14 числа не производили. Поэтому, вероятно, когда Вы первый раз зашли на сервер, Вы приняли отпечаток ключа изначально созданного сервером, а уже затем этот ключ был заменён Вами на другой.

Если после этого Вы вручную внесли в known_hosts отпечаток нового ключа, но не перезапускали sshd, и не заставляли его перечитать конфигурацию, то sshd до сих пор использует изначально созданный ключ, так как загружает ключи во время запуска, и предложил Вам при подключении 14 числа отпечаток именно изначального ключа.

Если же, наоборот, Вы заменили ключ на сервере, перезапустили sshd, но не внесли отпечаток нового ключа в known_hosts, то при подключении 14 числа sshd предложил Вам отпечаток нового ключа, в то время как на локальной машине, подключение было ассоциировано со старым ключом.