Comments 43
Не очень понятно как можно закоммитить ключ в репозиторий.
Однако, возможно, на всякий случай, стоит еще раз повторить простой совет: никогда не храните конфиги, пароли, ключи и прочие секретные параметры в одном каталоге с кодом.
Даже если вы думаете что они перечислены в исключениях в .gitignore, .htaccess и прочих местах. Но всегда есть вероятность что что-то случится. Например в .gitignore прописан файл "id_rsa*", но вы переименовали его в "old_id_rsa" на время, а потом забыли. Или файлик ".env" с переменными окружения или паролями - сколько раз я уже находил такое в репозиториях клиентов...
У меня все конфиги по дефолту лежат отдельно в "/usr/local/etc/" и все приложения умеют оттуда читать. Ни git, ни nginx не смогут туда добраться. Трояны смогут, да, но это уже отдельный случай.
По-хорошему трояны не должны мочь попасть на ту машину, где хранятся ключи. Доступ к ней должен быть ограничен запросами на использование ключей: сформировать подпись, проверить подпись и т.п.
И без прямого доступа к ключам, перехватив управление, можно получить доступ к секретным ресурсам. Самый простой пример - троян в PyPI репозитории (или просто поддельный пакет), который при запуске может пропатчить, скажем, библиотеку boto3 и получить доступ к AWS во время выполнения легитимной операции.
Это уже отдельная тема и защита от этого - всеж сложнее чем не закоммитить продакшен-ключ в репозиторий компанией, которая занимается этими репозиториями.
Что за процессы там у них происходят что на одной машине встретились продакшен-ключ и разрешение на запись в публичный репозиторий?
Ещё хорошей практикой будет использовать хуки проверяющие на наличие секретов в коммите
Подчеркну, что это касается тех, кто использует ключи RSA. Если вы используете EcDSA, то для вас всё продолжает работать, как и работало.
У меня почему-то был только RSA ключ. После удаления старого прилетели аж три новых.
Нет, вы сами должны отправить публичный ключ с ECDSA.
Вы путаете. При первом подключении происходит получение ключей от сервера. Если вас устраивает ключ от сервера, то вы его сохраняете и используете при следующих подключениях для проверки подлинности сервера. После проверки вы пользуетесь своим закрытым ключом, чтобы туда подключиться. Естественно предварительно нужно загрузить на сервер свой открытый ключ, только тогда сервер может подтвердить вашу подлинность. Т.е. сервер имеет свою пару ключей и клиент свою пару. И вот для github.com у меня в ~.ssh/known_hosts был ключ только RSA. И у gillab с bitbuсket также. Gitlab, кстати, тоже выдал три ключа сегодня. В bitbucket так и выдаёт один RSA.
Нет, в любом случае. Проверьте ssh github.com
В том-то и дело, что я написал это после того, как проверил. У меня ничего не ломалось.
ssh github.com в любом случае проверяет RSA ключ сервера, даже если он и не используется.
Даже в статье написано, что пользователей ключей ECDSA это не затрагивает. Врут, наверное.
Там 3 ключа и 3 строчки в known_hosts. Смотрите сами: ssh-keygen -H -F github.com
ssh-ed25519
ssh-rsa
ecdsa-sha2-nistp256
(Ssh_rsa это именно ключ, а не алгоритм.)
Разумеется. Но у меня только ключ ecdsa, и у меня всё как работало, так и работает, и в посте github тоже написано, что пользователи ecdsa ничего не заметят.
Не надо мне доказывать, что у крота нет глаз, потому что он живёт под землёй в темноте.
RSA ключ всегда проверяется. Подождите, а что дает у вас ssh-keygen -H -F github.com
Три ключа?? Или меньше? Тогда странно.
Три ключа, из них два rsa, новый и старый. Но в случае использования ключа ECDSA ключ RSA не проверяется ни у меня, ни у разработчиков github.
На машине, где был только rsa-ключ, выводится лишь один. У вас, видимо, все три.
"Один нет" это какой? RSA? У меня 3 открытых ключа github.com сервера именно в know_hosts, а 4 мой, у меня закрытый ключ, у Github открытый. У меня самого ecdsa-sha2-nistp256, он отличается от ecdsa-sha2-nistp256 github-a.
Но в случае использования ключа ECDSA ключ RSA не проверяется ни у меня, ни у разработчиков github
Я не спорю.
RSA ключ всегда проверяется
Я не спорю.
Таки спорите.
Он не используется при шифровании, perfect forward secrecy. Но он проверяется при простом ssh github.com. У меня так.
Может у вас настройка, что весь RSA запрещен? Там столько настроек... Это ужас.
интересно почему гитхаб не использует SSHFP DNS запись..
Спасибо, успокоили.
Проблем решается также ручным удалением файла known_hosts из папки /home/юзернэйм/.ssh/
После этого git pull попросит заново подтвердить fingerprint
список правильных фингерпринтов: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints
Проблем решается также ручным удалением файла known_hosts из папки /home/юзернэйм/.ssh/
Это уже какой-то антисовет. У меня там 1029 строки, например. Это не какой-то ненужный файл, он, все-таки, используется ssh.
Да вы там похоже помойку развели, давно пора было почистить
Как его почистить? Там доменные имена и ip захешированы. https://unix.stackexchange.com/questions/31549/is-it-possible-to-find-out-the-hosts-in-the-known-hosts-file
Способ описан выше - удаление.
Все нужные хосты добавятся при первой необходимости.
Еще раз вам уже прямо говорю - вы не понимаете назначения этого файла и советуете вредные вещи. Не делайте так.
В этом случае при "первой необходимости" каждый хост заново задаст вопрос про доверие, что, например, прервёт выполнение давно настроенных скриптов, не предусматривающих человеческого участия.
Сложно представить сервер, который работает с 1000 хостов и не имеет механизма добавления/обновления фингерпринтов. Вечное хранение хлама на серверах это тормоза и печаль
Мне легко представить. Ещё раз, там нет имен серверов в clear text, так что почистить можно только удалив файл.
Ну или подбирать хеши.
Отнюдь. Используя ssh-keygen можно все что угодно делать.
└> ssh-keygen -F github.com
# Host github.com found: line 60
|1|lU0Q4ff21TEigpxXW0pHZyJC ...Кстати, ниже спрашивают про revocation list - это тоже там есть, судя по всему, однако, я сам не пользовался:
ssh-keygen is able to manage OpenSSH format Key Revocation Lists (KRLs).
Он как раз хеширует github.com и ищет уже захешированную строку. Не зная всех серверов наизусть будет сложно почистить файл.
Интересно, здесь есть KRL?
А, в этом смысле да, вывести список не получится. Однако,, судя по всему, хэши там - это одна из форм записи.
Hostnames is a comma-separated list of patterns (
*and?act as wildcards). Each pattern is matched against the canonical host name when authenticating a client or against the user-supplied name when authenticating a server. A pattern can also be preceded by!to indicate negation. If the host name matches a negated pattern, it is not accepted by that line even if it matched another pattern on the line. A hostname or address can optionally be enclosed within '[' and ']' brackets, then followed by ':' and a nonstandard port number.Alternatively, hostnames can be stored in a hashed form which hides host names and addresses if the file's contents are disclosed. Hashed hostnames start with a '|' character. Only one hashed hostname can appear on a single line and none of the above negation or wildcard operators can be applied.
Про revocation
For RSA, DSA, ECDSA, or Ed25519 from the id_rsa.pub, id_dsa.pub, id_ecdsa.pub, or
id_ed25519.pub files:marker (optional), hostnames, key-type, public-key, comment
The marker is optional, but if it is present then it must be one of @cert-authority, to
indicate that the line contains a certification authority (CA) key, or @revoked, to indicate that
the key contained on the line is revoked and must not ever be accepted. Only one marker should be
used on a key line.
Нашел тут
А что если кому-то нужно работать более чем с одним хостом, может с сотнями хостов или даже с тысячами? Да не, бред какой-то, кому может быть нужно что-то кроме GitHub. Точно помойка.
Я нигде не видел, но старый ключ же должны были занести в какой-то revocation list?
GitHub сообщил об изменении RSA SSH ключей github.com после утечки приватного ключа в открытый доступ