Правильный способ использования github, gitlab и тд — проверить fingerprint ssh хоста через их https страницы. То бишь пользователь должен заниматься работой машины. Почему так странно? Там же примерно та же криптография, что и в https.
Если ключ скомпрометируется, это вообще кошмар будет для гитхаба. Ротации ключей в ssh не предусмотрено, клиент тупо будет давать отлуп. Миллионам юзеров придётся ручками удалять строчки из ~/.ssh/known_hosts.
Здравствуйте, vsb, Вы писали:
vsb>Правильный способ использования github, gitlab и тд — проверить fingerprint ssh хоста через их https страницы. То бишь пользователь должен заниматься работой машины. Почему так странно? Там же примерно та же криптография, что и в https. vsb>Если ключ скомпрометируется, это вообще кошмар будет для гитхаба. Ротации ключей в ssh не предусмотрено, клиент тупо будет давать отлуп. Миллионам юзеров придётся ручками удалять строчки из ~/.ssh/known_hosts. vsb>Очень странно такое видеть в 2021 году.
Здравствуйте, kov_serg, Вы писали:
_>А в чем собственно проблема?
Проблем, собственно, две. Первая это предотвращение MITM. Для этого нужно быть уверенным в том, что на том конце действительно сервер, а не злоумышленник. В HTTPS это решается с помощью УЦ. В SSH метод решения перекладывается на пользователя. Который в лучшем случае сверит отпечаток ключа с эталонным, полученным через тот же HTTPS, в худшем случае (думаю, это 90% программистов) вообще ни с чем сверять не будет. Вторая проблема это смена ключа при его компрометации, про это я написал в первом сообщении.
Здравствуйте, vsb, Вы писали:
vsb>Правильный способ использования github, gitlab и тд — проверить fingerprint ssh хоста через их https страницы. То бишь пользователь должен заниматься работой машины. Почему так странно? Там же примерно та же криптография, что и в https.
SSH создавался независимо от иерархической инфраструктуры X.509 (которая вообще-то необязательна для https) и у него p2p структура доверия ключей по умолчанию.
Но есть, как минимум, SSHFP записи в DNS.
vsb>Если ключ скомпрометируется, это вообще кошмар будет для гитхаба. Ротации ключей в ssh не предусмотрено, клиент тупо будет давать отлуп. Миллионам юзеров придётся ручками удалять строчки из ~/.ssh/known_hosts.
Да, это слегка проблема. Вообще openssh очень странная штука. Например, зачем требовать держать known_hosts и authorized_keys одним файлом?
SSH2 от ssh.fi вместо этого имеет каталоги с файлами.
vsb>Очень странно такое видеть в 2021 году.
Увы.
Но это проблемы конкретного клиента, который можно и нужно исправлять.
Здравствуйте, vsb, Вы писали:
vsb>Проблем, собственно, две. Первая это предотвращение MITM. Для этого нужно быть уверенным в том, что на том конце действительно сервер, а не злоумышленник. В HTTPS это решается с помощью УЦ. В SSH метод решения перекладывается на пользователя. Который в лучшем случае сверит отпечаток ключа с эталонным, полученным через тот же HTTPS, в худшем случае (думаю, это 90% программистов) вообще ни с чем сверять не будет. Вторая проблема это смена ключа при его компрометации, про это я написал в первом сообщении.
Повторюсь — SSHFP записи в DNS. Вместе с DNSSEC это даёт такую же надёжную иерархию, как и с X.509, но в роли УЦ выступает вся DNS система.
Стандартный openssh клиент умеет SSHFP по умолчанию.
Здравствуйте, netch80, Вы писали:
vsb>>Проблем, собственно, две. Первая это предотвращение MITM. Для этого нужно быть уверенным в том, что на том конце действительно сервер, а не злоумышленник. В HTTPS это решается с помощью УЦ. В SSH метод решения перекладывается на пользователя. Который в лучшем случае сверит отпечаток ключа с эталонным, полученным через тот же HTTPS, в худшем случае (думаю, это 90% программистов) вообще ни с чем сверять не будет. Вторая проблема это смена ключа при его компрометации, про это я написал в первом сообщении.
N>Повторюсь — SSHFP записи в DNS. Вместе с DNSSEC это даёт такую же надёжную иерархию, как и с X.509, но в роли УЦ выступает вся DNS система. N>Стандартный openssh клиент умеет SSHFP по умолчанию.
DNSSec требует клиентской конфигурации? Если нет, то не понятно, почему ни у github ни у gitlab этого нет.
А вообще с DNSSec в теории и УЦ не нужны. Но на практике браузеры не поддерживают, видимо есть до сих пор не решённые проблемы с этим.
Здравствуйте, vsb, Вы писали:
vsb>DNSSec требует клиентской конфигурации?
На финальном клиенте — нет, такие обычно ходят к рекурсивному резолверу серверной фермы или провайдера.
Тому тоже усилий минимум — разве что включить обязательность проверки по DNSSEC, где есть соответствующие записи.
vsb> Если нет, то не понятно, почему ни у github ни у gitlab этого нет.
Возможно, никто не просил...
vsb>А вообще с DNSSec в теории и УЦ не нужны. Но на практике браузеры не поддерживают, видимо есть до сих пор не решённые проблемы с этим.
Здравствуйте, netch80, Вы писали:
vsb>>DNSSec требует клиентской конфигурации?
N>На финальном клиенте — нет, такие обычно ходят к рекурсивному резолверу серверной фермы или провайдера. N>Тому тоже усилий минимум — разве что включить обязательность проверки по DNSSEC, где есть соответствующие записи.
Такой вариант мало полезен. Резолвер там может что угодно возвращать, ему веры нет. Проверять всю криптографию должна конечная программа и никак иначе. Хотя, полагаю, достаточно просто пользоваться https://1.1.1.1/ прямо внутри бинарника того же ssh для разрешения имён. Но это тоже сделать надо.
vsb>>А вообще с DNSSec в теории и УЦ не нужны. Но на практике браузеры не поддерживают, видимо есть до сих пор не решённые проблемы с этим.
N>Просто X.509 появилась существенно раньше.
Тем не менее до появления letsencrypt был некий локальный кризис HTTPS, когда бесплатные провайдеры были очень сомнительного качества, а платные хотели денег. С letsencrypt, конечно, всё стало проще, но всё же часть людей предпочли бы не зависеть от этого сервиса. Так что определённый спрос на такой функционал точно есть. За себя могу сказать, что я бы точно предпочёл этот вариант.
HTTPS нужен, для клиентов, которые общаются с разными неожиданным и незнакомыми хостами (со многими однократно). Тут нужна третья доверенная сторона, которая подпишет сертификат сервера, для удовлетворения клиента.
SSH нужен, когда ты ходишь на известные хосты и тут третья сторона, которая может не ответить, когда я со своего ноутбука захожу по офисной сети на сервер, вообще не приемлема, поэтому тут есть только две стороны: сервер и клиент, и они должны суметь друг дружку авторизовать. При заходе на незнакомый хост, ты можешь посмотреть отпечаток его ключа при подключении и сравнить с тем, что лежит на сервере, на который ты зашел. Необходимость сравнивать отпечатки (при избытке паранойи, потому что в реальности это не нужно) возникает из того, что в SSH только две стороны и третьей (доверенной) быть не может.
А, ну, да, ответ на вопрос: в SSH не может быть доверенной стороны (с ней тупо может не быть связи, сеть изолированная или, например, в офисе отпал интернет — ты не можешь зайти на сервак/роутер и посмотреть настройки, найти причину, исправить маршрутизацию).
P.S. DNSSEC не получил нужной популярности и умер (сложности в настройке и в разы увеличенное время ответа DNS неприемлемо ни для пользователей, ни для админов).
Здравствуйте, Reset, Вы писали:
R>Вообще не понимаю сути вопроса.
R>HTTPS нужен, для клиентов, которые общаются с разными неожиданным и незнакомыми хостами (со многими однократно). Тут нужна третья доверенная сторона, которая подпишет сертификат сервера, для удовлетворения клиента.
R>SSH нужен, когда ты ходишь на известные хосты и тут третья сторона, которая может не ответить, когда я со своего ноутбука захожу по офисной сети на сервер, вообще не приемлема, поэтому тут есть только две стороны: сервер и клиент, и они должны суметь друг дружку авторизовать.
А есть вариант, например, когда у тебя 100500 узлов на Амазоне, и надо иметь возможность на любой зайти по ssh, а завтра он исчезнет и появится другой узел.
Предлагаете задавать им всем идентичный ключ хоста?
R> При заходе на незнакомый хост, ты можешь посмотреть отпечаток его ключа при подключении и сравнить с тем, что лежит на сервере, на который ты зашел. Необходимость сравнивать отпечатки (при избытке паранойи, потому что в реальности это не нужно) возникает из того, что в SSH только две стороны и третьей (доверенной) быть не может.
R>А, ну, да, ответ на вопрос: в SSH не может быть доверенной стороны (с ней тупо может не быть связи, сеть изолированная или, например, в офисе отпал интернет — ты не можешь зайти на сервак/роутер и посмотреть настройки, найти причину, исправить маршрутизацию).
И никакой _принципиальной_ разницы с HTTPS нет. В HTTPS точно так же может быть (самоподписанный) сертификат локального значения.
Разница в _типовой_ практике, а не в принципах работы с ними. Да, обычно по HTTPS ходят по всему миру, а по SSH к десятку знакомых, но это _обычно_.
И вот это
R> при избытке паранойи, потому что в реальности это не нужно
неверно, потому что случаи подделки потока с подменой хостового ключа и перехватом всего трафика — таки известны.
R>P.S. DNSSEC не получил нужной популярности и умер (сложности в настройке и в разы увеличенное время ответа DNS неприемлемо ни для пользователей, ни для админов).
С чего это вывод, что DNSSEC умер? Он спокойно себе развивается. Мгоновенного чуда не получилось, конечно, но идёт медленное планомерное внедрение.
Здравствуйте, vsb, Вы писали:
vsb>>>DNSSec требует клиентской конфигурации? N>>На финальном клиенте — нет, такие обычно ходят к рекурсивному резолверу серверной фермы или провайдера. N>>Тому тоже усилий минимум — разве что включить обязательность проверки по DNSSEC, где есть соответствующие записи.
vsb>Такой вариант мало полезен. Резолвер там может что угодно возвращать, ему веры нет.
Почему это "резолвер может что угодно возвращать"? Где вы видели такие проблемные резолверы?
vsb> Проверять всю криптографию должна конечная программа и никак иначе.
Можно установить и удостоверенную связь с резолвером. А что значит "всю" криптографию? Корректность данных файловой системы из пакета ca-certificates она тоже будет проверять на каждом запуске? И на основании чего собственно?
vsb> Хотя, полагаю, достаточно просто пользоваться https://1.1.1.1/ прямо внутри бинарника того же ssh для разрешения имён. Но это тоже сделать надо.
Полагаться на публичный резолвер плохо:
1) Может просто выйти из строя или быть выключен, гарантии работы нет.
2) Иногда перегружен.
3) Ничего не знает про имена локальных сетей.
4) В случае проблем настройки DNS не позволяет ставить даже временные обходы этих проблем (типа форвард-зон с конкретным ремотным ответственным).
vsb>>>А вообще с DNSSec в теории и УЦ не нужны. Но на практике браузеры не поддерживают, видимо есть до сих пор не решённые проблемы с этим.
N>>Просто X.509 появилась существенно раньше.
vsb>Тем не менее до появления letsencrypt был некий локальный кризис HTTPS, когда бесплатные провайдеры были очень сомнительного качества, а платные хотели денег. С letsencrypt, конечно, всё стало проще, но всё же часть людей предпочли бы не зависеть от этого сервиса. Так что определённый спрос на такой функционал точно есть. За себя могу сказать, что я бы точно предпочёл этот вариант.
Я тоже. Но меня одного точно не хватит на исправление.
С DNSSEC проблема в сложности конструкции и как следствие — слишком медленном развитии.
Ожидаю, что кто-то сделает софт для облегчения управления, но пока не видел.
Здравствуйте, vsb, Вы писали:
vsb>Правильный способ использования github, gitlab и тд — проверить fingerprint ssh хоста через их https страницы. То бишь пользователь должен заниматься работой машины. Почему так странно? Там же примерно та же криптография, что и в https.
На самом деле, можно. В SSH есть инфраструктура CA, просто о ней мало кто знает.
Мы её используем для того, чтобы управлять доступом к машинам на EC2. На узлы вместо обычного публичного ключа устанавливается корневой сертификат нашей CA. А разработчики вместо приватного ключа получают подписанный временный (валидность в 2 часа) сертификат, с помощью специальной утиллитки, которая привязана к Single Sign-On.
Так что нет проблем с тем, что ключ может утечь или остаться у пользователя после его ухода из компании.
Здравствуйте, vsb, Вы писали:
vsb>Правильный способ использования github, gitlab и тд — проверить fingerprint ssh хоста через их https страницы. То бишь пользователь должен заниматься работой машины. Почему так странно? Там же примерно та же криптография, что и в https.
непонял. в ssh нет authority, а в https — их целые иерархии.
vsb>Если ключ скомпрометируется, это вообще кошмар будет для гитхаба. Ротации ключей в ssh не предусмотрено, клиент тупо будет давать отлуп. Миллионам юзеров придётся ручками удалять строчки из ~/.ssh/known_hosts.
опять не понял. на каждый ПК — отдельный ключ на гитхабе. у меня по крайней мере. я думал все так делают.
vsb>Очень странно такое видеть в 2021 году.
гитхаб вечен по сравнению с конкретным ~/.ssh/ в 2021м году. что не так то? 🙃
Здравствуйте, VladCore, Вы писали:
vsb>>Правильный способ использования github, gitlab и тд — проверить fingerprint ssh хоста через их https страницы. То бишь пользователь должен заниматься работой машины. Почему так странно? Там же примерно та же криптография, что и в https.
VC>непонял. в ssh нет authority, а в https — их целые иерархии.
Что именно не понял?
vsb>>Если ключ скомпрометируется, это вообще кошмар будет для гитхаба. Ротации ключей в ssh не предусмотрено, клиент тупо будет давать отлуп. Миллионам юзеров придётся ручками удалять строчки из ~/.ssh/known_hosts.
VC>опять не понял. на каждый ПК — отдельный ключ на гитхабе. у меня по крайней мере. я думал все так делают.
Речь о серверном ключе, а не о твоём клиентском. Твой клиентский-то как раз валидируется как положено — ты загружаешь его на github через https-соединение, т.е. github уверен в том, что его не подменят.
Здравствуйте, vsb, Вы писали:
vsb>Правильный способ использования github, gitlab и тд — проверить fingerprint ssh хоста через их https страницы. То бишь пользователь должен заниматься работой машины. Почему так странно? Там же примерно та же криптография, что и в https.
Математика там примерно та же, а вот процедура key exchange — совершенно другая.
SSL — это корпоративного капитала, а SSH — это мир одноранговой анархии.
Сейчас границы между мирами постепенно стираются. Но исходно это две в каком-то смысле противоположных идеологии: X.509 специально спроектирован так, чтобы доверие распространялось от центра вниз.
Это делает систему несимметричной — грубо говоря, ты должен идти на поклон к authority, которая тебе может выдать сертификат, а может и не выдать. Или произвольно отозвать у тебя сертификат на основе только ей ведомых процессов и причин.
ssh подразумевает, что все равноправны, и решение о том, кому доверять, а кому нет, принимает конечный пользователь. С одной стороны, он не может полагаться на то, что кто-то в иерархии уже взял на себя ответственность; с другой стороны — нет возможности централизованно "задавить" какой-то сервер.
В X.509 источником власти является "божественная сущность", которая помазывает на царство "императоров" (Root CA), а те уже наделяют властью своих подчинённых.
В SSH источником власти является народ.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
