Комментарии 153
Так, а что в термине "публичный ключ" неясно, что автор нас пугает?
И да, везде при работе с ключами явно пишут - используйте отдельный ключ на каждый сервер. Т.е. ключ для гитхаба должен быть только ключем для гитхаба.
гитхаб легко и непринужденно отдает известные ему ключи просто по юзернейму, даже для меня было сюрпризом
а для вас не будет сюрпризом, что существуют целые каталоги открытых ключей типа https://keys.openpgp.org ?
Точно так же вы можете использовать публичный ssh ключ для доступа не на свой сервер, а к компьютеру учебного заведения / работодателя / итд, где тамошний админ может зайти в домашний каталог любого из пользователей. А в здешней дискуссии все почему-то сравнивают доступ к гитхабу с доступом к своим единолично администрируемым машинам
pgp ключи это немного другое и работает иначе. Кто с Arch Linux работал, тот представляет.
Поэтому и явно написал что "автор", понимая, что это перевод =)
С одной стороны для меня это не сюрприз, что гитхаб отдает многое. С другой - да, это стрёмно, потому что на странице добавления ключей никакой информации об этом не вижу.
Я даже встречал некоторый софт, который использует эту публичность у ключей юзеров. Самый известный, пожалуй, это установщик Ubuntu Server: во время установки ОС предлагается ввести имя пользователя на гитхабе и прописать все публичные ключи в `~/.ssh/authorized_keys`.
GitLab честно писал, что добавленные ключи всем доступны будут. Только не помню, чтобы описывали как.
Для меня кстати сюрпризом это не было. Потому что инсталлеры Ubuntu с определенного момента умеют настраивать доступ к машине по...username с гитхаба. Вот именно через этот механизм.
Внизу, скорее всего, через cloud-init, у него есть директива ssh_import_id. Оно сейчас широко используется для большинства cloud образов/сборок в совершенно разных местах, начиная от соотв. образов дистрибутивов у самих вендоров дистрибутивов до облачных провайдеров типа hetzner и систем типа lxd. Если рядом фигурируют слова типа cloud-config или user-data -- это оно)
Мне кажется, что автор намекает на уязвимость типа
"Извините, но этот пароль уже использует юзер Вася, введите другой пароль"
Ну а то, что гитхаб легко и непринужденно отдает известные ему ключи просто по юзернейму, даже для меня было сюрпризом.
А может публичный ключ он на то и публичный что может быть доступен по разным каналам.
Проблема только в том что один публичный ключ используется на разных сервисах и тогда можно определить что такой человек использует эти сервисы.
А может он (человек) и не скрывает этого, может это вовсе и не проблема.
Это проблема неосведомлённого юзера, а не гитхаба. По хорошему никто не использует один ключ для разных сервисов, для каждого генерируется свой ключ!
По-хорошему только параноики так делают, все остальные не парятся, что кто-то узнает, что они на еще какой-то дугой сервер с этим ключом заходят. Вы еще логин предложите для каждого сервера уникальный генерировать.
Так тут вся статья только для параноиков и нужна, остальные не парятся, что кто-то узнает их логин на гитхабе :)
Вы еще логин предложите для каждого сервера уникальный генерировать.
А разве генерирование пользователя с именем, состоящим из случайной цифробуквенной комбинации длительностью 8 символов или более вроде ai18djh1 не является стандартной практикой? Оно же один раз в жизни вбивается в конфигурацию SSH и с тех пор больше нигде никогда не потребуется.
Не силен в go, ниасилил запустить этот код. Но сама концепция выглядит странно: няп, при соединении по SSH клиент просто пытается построить общий с сервером сеансовый ключ. Публичный ключ со стороны клиента здесь совершенно не нужен.
Может, в этой ssh библиотеке есть баг, и автор его обнаружил но не понял? Перевод, ага..
Кажестя, автор и правда попутал. По ключу -i команде ssh передается identity, т.е. приватный ключ.
Сначала клиент посылает отпечатки своих публичных ключей, потом сервер выбирает среди них подходящий, и только после этого соответствующий приватный ключ используется для соединения.
Если не делать последний шаг - то и приватный ключ не требуется.
Сначала клиент посылает отпечатки своих публичных ключей
Можно чуть поподробнее?
Я клиент. У меня ~/.ssh с десятком ключей. Но через -i я указываю только один конкретный приватный ключ.
Что на самом деле клиент шлет на сервер? Он же не восстанавливает публичные ключи из всех этих приватных? Неужто authorized_keys? Из чего сервер выбирает подходящий?
Мне казалось, что наоборот, я как клиент могу получить публичные ключи сервера (ssh-keyscan) и по поддерживаемым алгоритмам решить, какой из моих приватных ключей может подойти. А кучи публичных ключей на этой клиентской машине вообще может не быть (даже при наличии кучи приватных для доступа к разным ресурсам).
Но через -i я указываю только один конкретный приватный ключ.
Да, в openssh внутри приватного ключа лежит и публичный ;) У вас в ssh-agent может быть загружено 500 приватных ключей, и клиент их будет перебирать. НЯП, внутри реализации ssh сначала проверяется fingerprint публичного ключа (так быстрее), а при совпадении
строится соединение с использованием приватного. ssh клиент fingerprint отдельно не проверяет, но программу, которая так делает, написать можно.
Да, в openssh внутри приватного ключа лежит и публичный ;)
Вау, не знал таких тонкостей.
Вряд ли публичный хранится в приватном. Уверен, из приватного вырешивается публичный (stackoverflow говорит, openssh с запароленным приватным сначала поищет .pub ключ, чтобы не спрашивать лишний раз пароль)
Формат ключей OpenSSH:
"openssh-key-v1"0x00 # NULL-terminated "Auth Magic" string
32-bit length, "none" # ciphername length and string
32-bit length, "none" # kdfname length and string
32-bit length, nil # kdf (0 length, no kdf)
32-bit 0x01 # number of keys, hard-coded to 1 (no length)
32-bit length, sshpub # public key in ssh format
32-bit length, keytype
32-bit length, pub0
32-bit length, pub1
32-bit length for rnd+prv+comment+pad
64-bit dummy checksum? # a random 32-bit int, repeated
32-bit length, keytype # the private key (including public)
32-bit length, pub0 # Public Key parts
32-bit length, pub1
32-bit length, prv0 # Private Key parts
... # (number varies by type)
32-bit length, comment # comment string
padding bytes 0x010203 # pad to blocksize (see notes below)Спасибо обоим, неправильно запомнил видимо. Наверное из-за описания команд: https://stackoverflow.com/questions/5244129/use-rsa-private-key-to-generate-public-key (комментарии + ответ golem)
Вряд ли публичный хранится в приватном.
Так и есть. ssh-keygen -e
Уверен, из приватного вырешивается публичный
Это невозможно (за разумное время) by design асимметричной криптографии.
Это тривиально, и представляет проблему только для RSA и только если реализовывать его по википедии - с CRT ключами это тоже тривиально.
Невозможно вычислить приватный из публичного.
Вы с @VADemon про разные операции говорите:
публичный ключ из приватного (Публичный ключ именно так и делается)
приватный ключ из публичного (Это невозможно (за разумное время) by design асимметричной криптографии.)
Если вы указали конкретный приватный ключ - то только его отпечаток клиент и пошлёт. Но в общем случае у вас может быть несколько ключей.
Он же не восстанавливает публичные ключи из всех этих приватных?
А что мешает это сделать?
Мне казалось, что наоборот, я как клиент могу получить публичные ключи сервера (
ssh-keyscan) и по поддерживаемым алгоритмам решить, какой из моих приватных ключей может подойти.
Просто представьте сколько публичных ключей зарегистрировано у пользователя git на сервере github.com. Вы уверены что желаете каждый раз их все выкачивать? :-)
Просто представьте сколько публичных ключей зарегистрировано у пользователя git на сервере github.com. Вы уверены что желаете каждый раз их все выкачивать?
Не, я вообще по другому это себе представлял. ssh-keyscan github.com выдает лишь несколько своих ключей (ssh-rsa, ecdsa-sha2-nistp256, ssh-ed25519), а не миллионы загруженных в него пользовательских. А какой-то сервер более строго настроен, ssh-rsa не отдаст уже, и к нему с таким ломиться бесполезно, даже если пользователь такой прописал в свой authorized_keys.
И думал, что гитхабу шлю key fingerprint, а не public key целиком Ибо для rsa это намного короче, а по идее должно быть достаточно, чтобы понять, что это именно я.
Но гитхаб знает отпечаток публичного ключа, т.е. его, видимо, надо сначала извлечь, чтобы посчитать fingerprint. С этим прояснилось.
А вот зачем гихаб возвращет публичный ключ по имени пользователя я так и не уловил. В какой момент это используется?
Ну так ssh-keyscan вообще-то ищет публичные ключи серверов, а не пользователей.
И думал, что гитхабу шлю key fingerprint, а не public key целиком
Вроде бы так и есть. Но разницы нет, что отпечаток, что публичный ключ одинаково хорошо позволяют идентифицировать пользователя.
А вот зачем гихаб возвращет публичный ключ по имени пользователя я так и не уловил. В какой момент это используется?
А фиг его знает, это часть Github API и к протоколу SSH отношения не имеет.
Там выше подсказывают, что в Ubuntu Server при установке можно выкачать публичные ssh-ключи с аккаунта на гитхабе.
Существует распространенное мнение, что этот метод более безопасен, чем аутентификация по паролю, и это, безусловно, правда.
Условно говоря, в ассиметричной криптографии "длина пароля" длинней, сильно длинней, очень-очень сильно длинней. И окрыленные этим обстоятельством пользователи часто забывают, что остальные болячки парольной защиты с увеличенной "длиной пароля" никуда не деваются, а некоторые даже обостяются. Скажем, логин vasya123 - совсем не уникальный, а вот 2048-битный открытый ключ пользователя vasya123 - очень даже.
для кого-то стало открытием что для разных хостов и задач лучше юзать разные ssh ключи?
Это я так понимаю новомолодёжная интерпретация старой притчи про использование одного и того же пароля на разных сайтах?
Нет, это про деанонимизацию.
Если у вас есть учетная запись на github, с заполненным профилем
И ключ для авторизации на github вы используете еще зачем-то
То по вашему публичному ключу можно выйти на ваш профиль в github.
Не более.
Причём выйти можно только перебором или сбором данных заранее, обратного сервиса (по ключу найти пользователя) github не предоставляет.
И по ней искать что? Вы подставляете ник юзера для генерации ссылки для получения ключа, потом по этому ключу получаете тот же ник? И называете это деанонимизацией?
Я читаю то внимательно, вы снова повторяете то же самое. Вы получаете список юзеров с помощью API, подставляете каждого юзера для генерации ссылки для получения ключа, потом по этому ключу получаете тот же ник?
Деанонимизация как побочный эффект. Если человек вдарился в анонимность, он не то что один и тот же ключ использовать не будет, но и ещё "логин" ("титл" или подобные поля) сделает отличающимся. Тем более если хочет анонимности то явно не будет вбивать свои данные на гитхабе или ещё как-то связывать. Доходя уже до того, чтоб с того же ИП не заходить в места которые не хочется чтоб были связаны.
А деанонимизировать человека с ником makeev_alexandr@github это странновато. Я не говорю про отдельные "хитрые" исключения.
Это нужно очень хорошо и очень заранее планировать.
Если собираешься для чего-либо анонимизироваться, то это кмк настолько очевидные вещи (в отличие, например, от атаки по времени или по стилю сообщений), что тут не просто очень заранее планировать, а банально здравый смысл, не?
Если собираешься анонимизироваться на 100%, то нужно не только совсем разные учетки с разными паролями и ключами, но и разные браузеры под каждый сайт и т.п., что для бытового использования нереально.
А вот если не шпион/хакер и т.п., а просто хотел иметь на разных сайтах несколько разных аккаунтов, достаточно и частичных мер. Всегда же баланс поставленных задач и усилий.
И одно дело, если какой-нибудь фейсбук палит и блокироует твой второй аккаунт - внутри одного сайта это не слишком сложно. И другое - если внезапно оказывается что тебя могут легко спалить по другому сайту, причем в рамках обычного нормального функционирования, безо всякх взломов.
Не смертельно, но неприятный сюрприз.
Я чуть-чуть про другое. Для каждого сайта новая личность это перебор. А вот 1-2 личности (помимо тебя реального) вполне себе несложный вариант.
Меня на самом деле удивляет подобная позиция, нужно просто принять как данность - если ты (я не про вас, а "ты" это как к самому себе) залил что-то в интернет, то оно доступно для всех. Может не сразу, а через пол года и пусть оно будет под тремя сотнями замков. взломы/утечки/уязвимости - это просто банальный набор который даёт реальный шанс что всё что ты залил будет доступно где и кому угодно а ещё даже и будет украдено. И то что ты запилишь статью на хабр о том какая <s>digma</s> компания нехорошая, им от этого не будет ни жарко ни холодно.
А потому как вы верно сказали, зависит от баланса, что я ниже описал: хочешь некрасивое - забудь про себя; хочешь посмотреть порно - запусти приватный режим и логинься на порнхаб каждый раз.
А список логинов в открытом доступе? Ну блин, меня как-то опознал на хабре человек, который тут даже не зарегистрирован. По нику предположил, по комментарию обрёл уверенность.
то это кмк настолько очевидные вещи
Но их учесть сложно. Вот недавно была заметка про хакера, который на форумах интересовался разными вещами по поводу telegram-ботоводства, и запилил таки этого своего бота, и запустил в prod.. И первое сообщение в него отправил со своей учетной записи ;) Упсь. Любая, самая неочевидная ошибка - и ты ошибся.
Тут в комментарии выше как раз и говорилось про это. Хочешь делать что-то некрасивое - забудь про свои привычки - ты обычный и ты скрытый, это два человека и их нельзя связать через теорию 6-ти рукопожатий. Нельзя быть анонимным на пол-шишечки.
И тут если тебе нужно, чтоб тебя не опознали со стороны, то используешь исключительно всё новое (пусть и даже банально виртуалка заранее в ВПН-тор завёрнута), а если хочешь скрыть от жены, то можно и приватный режим браузера запустить.
И наоборот. Зная имя на гитхаб можно получить публичный ключ. И по нему сопоставить вас с каким-то другим сервисом.
Какой-нибудь TeamCity/GtLab может посмотреть гихабовый аккаунт и понять, как этот же пользователь зарегистрирован у него.
В общем, меня напрягло, что это способ сопоставить мои разные ники и email на разных ресурсах, о котором я не подозревал.
А гитхаб-авторизация, между прочим вполне себе широко используемая фича. Поэтому скрывать пользователей гитхаб и не должен.
Это задача самого пользователя решать использовать или не использовать тот же ключ/пароль на разных ресурсах
"Авторизация через гихаб", мне кажется, из другой оперы.
Тем не менее, даже "выдать публичный ключ по имени пользователя" - тоже не какая-то уязвимость.
При этом использовать одинаковый ПУБЛИЧНЫЙ ключ и на гихабе и на гилабе я не считал опасным с точки зрения безопасности (хоть и не использовал по причине разный логин - разный ключ). А вот деанонимизация мне не нра.
Но пока это не "подсветили" в статье, я об этом не задумывался. Хотя и знал про возможность импортировать публичный ключ с гитхаба/ланчпада при установке убунты. Впредь буду еще внимательнее.
Скорее, логина.
Если вы используете необычный ник на всех ресурсах, то наблюдатель может предположить, что эти аккаунты принадлежат одному человеку,
Так же и с публичными ключами.
Да, вы правы, больше о логине чем о пароле. Просто привык думать именно о "паре", что различить логин и пароль по отдельности практически бессмысленно (собственно как public и private ключи). Можно предположить, что шансы, что это один и тот же человек больше в случае ключей (чем в случае логинов), но опять же не стопроцентные, просто потому что не раз на гитхабе можно было найти пароли от различных "секретных" мест.
Автор ушел от логичного вопроса как разграниченно использовать несколько ключей. Потому что по умолчанию OpenSSH (а за ним и git) будут перебирать все ключи в ~./ssh до победного. А вот это и еще удобно организовать - квест еще тот. Подписывайтесь на мой канал в личку.
как разграниченно использовать несколько ключей
man ssh_config например
Потому что по умолчанию OpenSSH (а за ним и git) будут перебирать все ключи в ~./ssh
The default is ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519,
~/.ssh/id_ed25519_sk and ~/.ssh/id_rsa.
Например, для разных аккаунтов гитхаба (корп, личный) я слегка модифицирую имя сервера и указываю в .ssh/config, какой именно в данном случае приватный ключ использовать.
Примерно так:
[remote "origin"]
url = git@github-antra:USER/yyy.git
Кусочек config:
Host github-antra
HostName github.com
User git
IdentityFile ~/.ssh/git-antra
# ssh over https to bypass firewalls blocking ssh
# ssh -T -p 443 git@ssh.github.com
Host github-ssl.com
Hostname ssh.github.com
Port 443
как разграниченно использовать несколько ключей
.ssh/config
Host github.com
Hostname ssh.github.com
Port 443
PreferredAuthentications publickey
IdentityFile ~/.ssh/github.comА так перебрать тоже будет? Просто интересно.
Да, работает
[remote "origin"]
url = git@github.com:XXX/yyy.git
config:
Host github.com
Hostname ssh.github.com
Port 443
IdentityFile ~/.ssh/git-XXX
Результат:
Но обычно я во избежание накладок все-таки меняю на а-ля github-ssl.com (можно и просто github-ssl, лишь бы одинаково в конфигах гита и ssh)
Если я правильно понимаю ман, то при работающем ssh-agent надо ещё IdentitiesOnly включить, чтобы наверняка. А так да, это твердая установка.
Ну у меня по первой ссылке Not Found, хотя я использую ssh ключи для подписи и аутентификации. И чаво?
может я как раз всё так делаю, раз мои ключи не светятся?
Можно через access token же?
Внезапно на гитхабе можно и https + gpg ключ.
я коммичу и подписываю свои коммиты без проблем. как с чтением?
Вы можете думать что используете свой ключ для авторизации, в то время как это может быть не так. Приведите ради интереса свой .git/config
Нет, я именно по ssh авторизовался.
Но кстати ключ-то мой появился. Но не было еще вчера, ей богу. Хз как они считываются ("засвечиваются").
Так что мои извинения всем авторам за сомнения. Хорошая статья, напоминающая о давно известной притче "не используй один и тот же пароль на разных сайтах". Только тут не используй одну и ту же ключепару на разных сервисах.
Проблема тут реально только одна и GitHub тут ни в чем не виноват. Истоки ее в том, что большинство ssh-клиентов (все что я видел) позволяют использовать для подключения конкретный закрытый ключ и никакой другой, но при этом можно ключ и не указывать, и тогда по умолчанию просто будут перепробованы все ключи что есть. В этом случае ключ как-бы считается не универсальным пропуском на сервер для всех у кого он есть, а средством аутентификации клиента для его доступа на все сервера которые готовы его принять. При этом что админы что программисты - существа крайне ленивые и вбивать лишние параметры в конфиг или командную строку, да еще и ключи каждый раз генерить - это лишняя работа, тем более что можно сделать это ровно один раз и все будет работать.
Собственно именно эта привычка использовать самые простые (первые заработавшие из загугленных) решения вместо осознанных - и есть единственный источник всех описанных в статье проблем. Избавьтесь от нее и будет вам счастье.
Вопрос всем, кто пишет, что надо прописывать ключи в конфиге явно.
А что делать, если из-за требований безопасности ssh ключ в открытом виде нигде не присутствует, а живёт только в памяти ssh-agent? Или загружается из какого-нибудь YubiKey?
Опции ssh_config IdentitiesOnly и IdentityFile позволяют указать файл ключа, а вот конкретный id ключа из предоставляемых агентом выбрать не получится.
вииртуалка\докер - и ходить оттуда только 1м ключем ?
Если я пробрасываю в виртуалку или докер сокет ssh-агента - проблема остаётся. Если я копирую туда ключ - то получается то же самое, что и хранить ключ в открытом виде.
Можно, конечно, делать отдельную виртуалку с шифрованным диском для каждого ключа, и потом ещё на каждую виртуалку ставить весь рабочий софт, использующий ssh, но тут уже удобство работы начинает сильно страдать.
Придумал решение: запускать несколько ssh-агентов c разными сокетами, и прописывать в IdentityAgent сокет до агента с нужным ключом.
Немного лучше, чем отдельные виртуалки, но всё равно дикие костыли.
Надо, чтобы ssh мог запрашивать у ssh-agent ключ только с заданным отпечатком, и его прописывать в конфиг.
Весь смысл шифрования с открытым ключом заключается в том, что публичный ключ распространяется максимально широко, чтобы невозможно было его подменить. Совершенно очевидно, что это идейно несовместимо с анонимизацией. И не в гитхабе тут дело.
Совет использовать разные ключи - это фактически попытка из рабочей схемы с открытым ключом сделать кривое подобие схемы с секретным ключом. Учитывая, что доверенного канала связи, требуемого для передачи секретного ключа, в интернете нет, то автоматически при этом схема становится уязвимой к MITM.
Весь смысл шифрования с открытым ключом заключается в том, что публичный ключ распространяется максимально широко, чтобы невозможно было его подменить.
Это где-то написано? Или ваше предположение?
Я, к примеру, считал, что идея в том, что публичный ключ можно распространить без доверенного канала. Про то, что его нужно максимально шриоко распространять для каких-то дополнительных проверок я не слышал.
Как вы его собираетесь распространять без доверенного канала? Вся идея в том, чтобы ваш получатель мог независимо от вас залезть, скажем, на гитхаб, и убедиться, что там содержится точно такой же ваш публичный ключ, и следовательно, на этот раз ему предлагаете ключ действительно вы, а не злоумышленник от вашего имени.
Прямо в Википедии в статье "Криптосистема с открытым ключом" в разделе "Общие принципы" можно причитать:
Владелец двух ключей никому не сообщает закрытый ключ, но передает открытый ключ контрагентам или делает его общеизвестным.
Поскольку прямая передача между контрагентами в интернете исключена, то остаётся второй способ.
Когда люди ещё пользовались в интернете криптографией осознанно, а не в силу моды, то многие даже в подпись всех своих сообщений вставляли pgp fingerprint, являющийся хешем публичного ключа.
Поскольку прямая передача между контрагентами в интернете исключена,
Она производится внесетевыми средствами, и на этом всё стоит. Ключи CA roots Мозиллы или корневые DNSSEC держатся на том, что люди, которые за них отвечают, регулярно встречаются вживую.
то остаётся второй способ.
Нет, не обязательно, и он точно не единственный, потому что сам вопрос доверия источнику публикации окончательно может быть решён только средствами вне Интернета.
то многие даже в подпись всех своих сообщений вставляли pgp fingerprint, являющийся хешем публичного ключа.
Которая давала только возможность сверить разные сетевые источники на то, что источник подписи один и тот же, но не давала возможность убедиться, например, что тот, кто подписывается Linus Torvalds, зовётся в реале так же, а не является, например, Аллой Пугачёвой, или тысячей индусов в одной локалке с шареным ключом.
Она производится внесетевыми средствами, и на этом всё стоит. Ключи CA roots Мозиллы или корневые DNSSEC держатся на том, что люди, которые за них отвечают, регулярно встречаются вживую.
Для Мозиллы это верно, но анонимы же не заверяют свои ключи в центрах сертификации.
Как уже сказал, доверие к такому источнику, про который вы знаете только подпись одним и тем же ключом, остаётся на уровне "верю, что это один и тот же человек писал" (ну, если мы предполагаем, что не сидят несколько под одним акаунтом и что коты ещё не умеют писать в Интернет что-то длиннее "ЯКОТ"). Для любого более серьёзного доверия нужен внешний источник. Но если человек подписывается, условно, Вася Пупкин на хабре, на LOR и в email и пишет на одни и те же темы со схожим уровнем компетенции, я могу считать, что это он и что его так зовут.
Во времена ранних PGP в крупных городах производились "сессии взаимной подписи" - в определённом месте собирались люди, которые друг у друга верифицировали документы (паспорт, права - что там где применяется) и тогда принимали друг у друга ключи - и подписывали их на публичных PGP-серверах. Не знаю, насколько эта традиция сейчас жива, давно не слышал.
Как вы его собираетесь распространять без доверенного канала?
Смотря что вы понимаете под "Доверенным каналом". Возможно мы сейчас вообще про разное говорим.
Сервер Гихаба мне дал свой публичный ключ (SSL/TLS) просто по обычному незащищенному Интернету.
Я залил ему свой публичный SSH ключ внутри HTTPS.
Теперь я могу к нему подключаться по SSH
Я бы не назвал это все "доверенным каналом". Тем не менее, это решает мою задачу - безопасного подключения к серверу Гитхаба по SSH. И при этом я не поделился ничем "секретным". Если кто-то взломает гитхаб и украдет мой публичный ключ - ну и ладно, доступа к моим ресурсам на других серверах он не получит.
При этом я не вижу дополнительных преимуществ для безопасности в широком распространении моего публичного ключа в случае SSH (GPG для подписи - другая история).
Публичный ключ невозможно "украсть", он на то и публичный. Вся схема безопасности построена на том, что он известен максимально широкому кругу лиц.
А вот ваш анонимный обмен с гитхабом небезопасен, так как гитхаб не имеет возможности сверить ваш публичный ключ с другими источниками и убедиться, что это именно вы, а не прокси между вами и гитхабом. Гитхаб, правда, в любом случае не стал бы этого делать, но это означает только то, что ваш обмен с гитхабом в любом случае небезопасен. У вас нет способа убедиться, что гитхаб отвечает вам на ваши запросы, а не злоумышенника посередине.
гитхаб не имеет возможности сверить ваш публичный ключ с другими источниками и убедиться, что это именно вы
Видимо я не понимаю саму концепцию. Что значит "именно я" для Гитхаба?
Ему же пофиг, как меня зовут и какой у меня номер паспорта. Вполне достаточно того, что некто, ранее подключавшийся к нему по имени и паролю, теперь может так же подключиться и по публичному ключу.
У вас нет способа убедиться, что гитхаб отвечает вам на ваши запросы, а не злоумышенника посередине.
У меня как раз есть. Достаточно проверить, что сертификат, удостоверяющий, что я подключен именно к github.com, выдан доверенным центром сертификации, а не каким-нибудь НУЦ.
А вот Гитхаб не может быть уверен в этом. Ну вдруг я проигнорировал предупреждение в браузере или вовсе добавил условный НУЦ в доверенные.
У меня как раз есть. Достаточно проверить, что сертификат, удостоверяющий, что я подключен именно к github.com, выдан доверенным центром сертификации, а не каким-нибудь НУЦ.
У вас есть способ убедиться, что автор ответов - гитхаб. Но на чьи запросы он вам отвечает - вы не знаете.
Человек посередине может выкинуть ваш запрос к гитхабу и послать свой запрос "пришли мне троян из моего проекта", зашифрованный его открытым ключом и подписанный подписью гитхаба. После чего расшифровать этот ответ своим приватным ключом, зашифровать вашим открытым ключом и отправить вам. И вы получите настоящий подписанный гитхабом ответ, но на чужой запрос.
Выше, конечно, имел в виду, что уже ответ гитхаба зашифрован открытым ключом злоумышленника и подписан гитхабом.
Можно вас пропросить чуть подробнее расписать цепочку?
Ведь я вижу в браузере сертификат гихаба, подписанный реальным УЦ, а не MITM. Далее шифрую сессию ключами, выработанными совместо с ним (он шифрует своим приватным ключом, я расшифровываю это его публичным ключом, подтвержденным доверенным УЦ).
В какой момент произойдет подмена? Как я расшифрую якобы ответ гитхаба, зашифрованный невесть кем, сессионным ключом, о котором договорился с гитхабом?
Ведь я вижу в браузере сертификат гихаба, подписанный реальным УЦ, а не MITM.
Да, потому что сообщения гитхаба подписывает реальный гитхаб.
Далее шифрую сессию ключами, выработанными совместо с ним (он шифрует своим приватным ключом, я расшифровываю это его публичным ключом, подтвержденным доверенным УЦ).
Нет. В нормальной ситуации он шифрует вашим публичным ключом, а вы расшифровываете своим приватным ключом.
В хакнутой ситуации он шифрует публичным ключом митма, так как для него нет разницы между митмом и вами в силу вашей анонимности, затем митм расшифровывает своим приватным ключом, снова зашифровывает вашим публичным ключом и отдаёт вам.
В какой момент произойдет подмена? Как я расшифрую якобы ответ гитхаба, зашифрованный невесть кем, сессионным ключом, о котором договорился с гитхабом?
Сообщения в системах шифрования с открытым ключом, в том числе и в ssh, шифруются открытым ключом получателя. Вы будете расшифровывать сообщения реального гитхаба, зашифрованные вашим открытым ключом у митма.
А подмена будет происходить на пути от вас к гитхабу, так как гитхаб вас не знает и ему плевать, от кого получать запросы.
Схема все еще не очень понятна. Если я в браузере вижу нормальный сертификат гитхаба - это значит я подключен к реальному гитхабу и все коммуникации в рамках этой сессии происходят с реальным гитхабом (т.е. я ему отправляю запросы и получаю от него ответы). Если там есть кто-то посередине - в браузере не будет нормального сертификата гитхаба (ситуацию с продажным УЦ не рассматриваем). Если в ответ гитхаба кто-то вдруг вклинится - браузер просто не примет такой ответ и ругнется в консоль.
Можете прямо по шагам расписать схему?
По направлению от гитхаба к вам вы получаете данные с реального гитхаба. Только не те, которые вы просили, потому что вместо вас попросил митм, а направление от вас к гитхабу никто не контролирует, так как вашу подлинность никто не удостоверял и не проверял.
Коммуникация имеет два направления, и она, вообще говоря, анизотропна.
Объясните как?
Вот я начинаю сессию со своей стороны. Делаю хендшейк, договариваемся о сессионных ключах. Этими ключами шифруются мои запросы и ответы гитхаба. В момент когда подключение установлено я вижу сертификат гитхаба.
На каком этапе криптография ломается?
Я ж расписал выше.
Сообщения гитхаба настоящие, но направлены митму. Ваши сообщения выкидываются и заменяются сообщениями митма. Сессионный ключ сервера в сессии настоящий, ваш сессионный ключ – не настоящий (но об этом никому не известно, кроме митма, так как вы свой открытый ключ скрываете от широкой публики).
Митм просто пересылает вам реальные сообщения гитхаба, перешифровывая вашим ключом.
Откуда он возьмет наши сессионные ключи? Ему тогда нужно вклиниваться до хендшейка, и предоставлять правильный сертификат гитхаба.
Да, конечно, он вклинится до хендшейка. Сессионный ключ гитхаба ему пришлёт гитхаб, а ваш сессионный ключ он прочтёт в вашем первом сообщении гитхабу при хендшейке.
Подождите, вы ниже пишете про ssh. А чуть выше обсуждали подключение в браузере. Как так?
По поводу хэндшейка - а где он возьмет валидный сертификат гитхаба, чтобы сделать хэндшейк безпалева?
Браузер упоминался только в том контексте, что в нём можно посмотреть сертификат с открытым ключом гитхаба.
Ключ гитхаба для хендшейка пришлёт ему сам гитхаб.
Браузер упоминался как достаточно надежный способ залить публичный ключ в свой аккаунт на Гитхабе через недоверенный Интернет. И потом уже подключаться к своему же (тому же) аккаунту на Гитхабе уже через ssh.
Это было в рамках ответа на "Как вы его собираетесь распространять без доверенного канала?"
А ключевое мое непонимание вашей позиции заключалось в "При этом я не вижу дополнительных преимуществ для безопасности в широком распространении моего публичного ключа в случае SSH"
google "ssh known_hosts".
Чей хост вы собрались там найти или не найти?
Для вас хост гитхаба будет known, потому что вы будете получать его настоящие сообщения, просто переупакованные. Для гитхаба ваш хост будет unknown, потому что вы аноним, а все дела гитхаб ведёт с mitm.
Если там будет кто-то посередине, то хэш изменится и мой клиент ssh ругнется. Собственно, именно для такого этот механизм и был придуман.
Хеш чего изменится? Вы получаете настоящие, подлинные сообщения гитхаба. Они не меняются по своему содержанию в расшифрованном виде.
Хеш публичного ключа. Вы не можете провести mitm-атаку не подменив этот ключ.
Почитайте внимательно описание атаки выше. Я провожу mitm атаку только на направление от юзера к серверу, и подменяю, соответственно, только публичный ключ юзера, но не публичный ключ сервера. А юзер по условию анонимен, поэтому такая подмена никому не заметна.
Вы не можете этого сделать без подмены ключа сервера. Никак.
Чтобы узнать сессионный ключ - вам необходимо знать какие параметры послал клиент серверу, а они зашифрованы открытым ключом сервера и прочитать их может только сервер.
Вы можете сколько угодно притворяться перед сервером, но для MITM-атаки вам надо обмануть и сервер, и клиента.
Причём здесь TLS? Мы обсуждаем ssh.
Это верное замечание, но гитхаб не знает server identity анонима.
Каким образом? Ваш клиент будет получать подлинные сообщения гитхаба с его настоящим server identity.
Естественно, митм, не обладая закрытым ключом гитхаба, не может подслушать сообщения со стороны клиента после хендшейка, но у него и нет задачи это делать. Также у него нет задачи представляться гитхабом и подделывать его идентити. Вы спорите с утверждениями, которых я не делал.
Всё, что должен сделать Митм - это послать запрос серверу от своего собственного имени и передать ответ сервера клиенту, расшифровав своим ключом и зашифровав открытым ключом клиента.
А если 22-й (дефолтный) порт поменять на какой-то другой, то это сильно усложнит задачу.
Шум и гам...
Оставлю это здесь https://trufflesecurity.com/blog/driftwood-know-if-private-keys-are-sensitive/
Это к чему?
То, что на гитхаб (и не только) не стоит аплоадить приватные ключи присутствующим здесь и так понятно. Такое делается скорее по ошибке, а не по необходимости.
В статье же речь о потенциальной опасности дележки с гитхабом публичным ключом для вполне себе благой цели.
@Antra (и не только)
# Github
https://github.com/<username>.keys
# Gitlab
https://gitlab.com/<username>.keys
# Bitbucket
https://bitbucket.org/api/1.0/users/<accountname>/ssh-keys
# Inside a GCP CloudShell using: curl -H "Metadata-Flavor: Google" <url>
http://metadata.google.internal/computeMetadata/v1/project/attributes/ssh-keys
Еще и gpg
In addition these also provide a way to retrieve a user's PGP keys:
GitHub:
https://github.com/USER.keys
https://gitlab.com/USER.gpg
GitLab:
https://gitlab.com/USER.keys
https://gitlab.com/USER.gpg
Да я вижу вектор мыслей автора, собрать все pub-key ssh не великая проблема. (Конечно же gh-archive/gh-torrent не включает подобные данные).
Вроде не раз уже собиралось подобное по порту 22.
Но в контексте безопасности, безусловно есть "рычаги" влияния. Но в контексте концепции криптографии - приватный ключ должен быть в безопасности. Да великая проблема в том что мы не можем отслеживать попытки применения приват ключа. Но best practice гласит: используйте уникальную пару на сервис (ровно как и пароль), заменяйте регулярно пару (как гласит практика плановой смены "паролей", но в данном контексте ключ).
Есть ли смысл выставлять на всеобщее обозрение кейсы имеющие влияние на OA комьюнити? Сомневаюсь...
Уже начиная с того, что по адресу https://github.com/username.keysмы можем увидеть только свои собственные ключи, но никак не чужие, всё, что идёт далее не имеет никакого практического значения, со своими можете играться сколько хочется и естественно получать ответы от сервера
Кто знает каким хостингом пользуется автор?
(аккаунт новый и не могу написать под прошлыми постами коммент)
Я ооооочень извиняюсь что пишу коммент по теме другого поста, но под старыми постами комменты оставлять не могу(
Автор, спасибо за Ваш труд и помощь в комментариях.
Посмотрите пожалуйста, возможно подскажите решение.
Я развернул Xray через скрпт Marzban на VPS, на клиенте подключался через Nekoray с ядром sing-box. Сейчас хочется подключаться через командную строку. Я экспортировал клиентский конфиг из Nekoray и пытаюсь заставить это работать командойsing-box run -c /usr/local/etc/sing-box/config.json
Конфиг запускается, но есть ошибки.
И интернета нет.
Мой клиентский конфиг: https://pastebin.com/GeZW00ej
Лог: https://pastebin.com/eBvEtzDv
Что я упускаю?
Это вывод route в случае использования nekoray.
Destination Gateway Genmask Flags Metric Ref Use Iface
default _gateway 0.0.0.0 UG 600 0 0 wlan0
172.19.0.0 0.0.0.0 255.255.255.240 U 0 0 0 nekoray-tun
192.168.0.0 0.0.0.0 255.255.255.0 U 600 0 0 wlan0
_gateway 0.0.0.0 255.255.255.255 UH 600 0 0 wlan0А это в случае прямого запуска из командной строки
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.0.1 0.0.0.0 UG 600 0 0 wlan0
172.19.0.0 0.0.0.0 255.255.255.240 U 0 0 0 tun0
192.168.0.0 0.0.0.0 255.255.255.0 U 600 0 0 wlan0
192.168.0.1 0.0.0.0 255.255.255.255 UH 600 0 0 wlan0Судя по отличиям, проблема в маршрутах?
Да я вот тоже пытаюсь разобраться, что это за _gateway, файл hosts пуст)
Кстати, через curl все работает, убрал из конфига tun, сделал:
curl -x "http://127.0.0.1:2080" "http://httpbin.org/ip"
Вернулся айпишник VPS.
Вообщем что то странное.
Я в конфиге удалил вот эту часть:
{
"network": "udp",
"outbound": "block",
"port": [
135,
137,
138,
139,
5353
]
},
{
"ip_cidr": [
"224.0.0.0/3",
"ff00::/8"
],
"outbound": "block"
},
{
"outbound": "block",
"source_ip_cidr": [
"224.0.0.0/3",
"ff00::/8"
]
}Потом запустил, все заработало.
Потом остановил, вернул обратно.
Запустил, и работает.
Вас сдаст Гитхаб: деанонимизация пользователей SSH-серверов