Недавно в своих ежедневных чтениях я наткнулся на явление, о котором думал уже много лет: феномен утечки информации людей, использующих SSH. Этот тип утечки информации не является новым явлением. Я давно предупреждал об этой опасности своих друзей, использующих SSH, но мой голос услышали лишь несколько человек. Поэтому я решил дать пояснения по этому поводу, потому что я считаю, что необходимо понимать этот риск в ИТ-сообществе, особенно в нынешней ситуации. Я буду исходить из предположения, что у вас, дорогой читатель, есть опыт работы с SSH.
Асимметричные ключи SSH
Протокол SSH использует асимметричную криптографию. Короче говоря, для шифрования связи и клиент и сервер каждый имеют открытый ключ и закрытый ключ, при установлении соединения они обмениваются друг с другом только открытым ключом, чтобы информация каждой стороны шифровалась с его помощью, а после обмена данные будут расшифрованы с помощью закрытого ключа. SSH использует тот же метод и для так называемой "авторизации по ключам". Существует распространенное мнение, что этот метод более безопасен, чем аутентификация по паролю, и это, безусловно, правда.
Чтобы подключиться, клиент должен сначала отправить открытый ключ на хост на другой стороне, которым обычно является SSH-сервер или Git.
Github, Gitlab и открытые ключи
В предыдущем абзаце я говорил о подключении к серверам Git через SSH. GitHub — один из нескольких известных сервисов Git, у которого много пользователей из нашей страны. GitHub позволяет пользователям работать с Git, используя публичные ключи SSH, но проблема в том, что такие сервера, как GitHub, публикуют ключи своих пользователей... в открытом виде. Вы можете увидеть один аспект этого увлекательного, но вредного действия GitHub, перейдя по ссылке ниже и подставив вместо "username" свое имя пользователя:
https://github.com/username.keysЗлоумышленники или работники силовых органов, имеющие какие-то намерения против своих граждан, могут просто просканировать эти SSH-ключи и создать базу данных аккаунтов и ключей, а дальше устанавливать совпадения с открытыми ключами, обнаруженными в других местах, и использовать их для идентификации граждан. Например, вы можете проверить наличие вашего ключа SSH на GitHub с помощью команды (ssh git@github.com ), и если такой ключ существует, вы увидите свое имя пользователя GitHub в ответе сервера.
Короче говоря, если у вас действительно есть SSH-ключ, зарегистрированный в GitHub, вам нужно принять за данность, что все ваши SSH-ключи GitHub вполне возможно уже просканированы и хранятся в какой-то базе данных.
Опасность сопоставления открытых ключей
Чтобы понять, как утечка открытого ключа пользователей SSH ставит под угрозу конфиденциальность, рассмотрим следующий эксперимент.
У меня есть два ключа SSH и сервер, который принимает от меня только один ключ. Теперь я пытаюсь подключиться к серверу с обоими ключами, а затем сравниваю логи клиента (с флагом verbose). Обратите внимание, что я удалил некоторые строки вывода из-за большого количества логов.
$ ssh -v -o "IdentitiesOnly=yes" -i ~/.ssh/id_ed25519 root@10.2.10.5
OpenSSH_9.1p1, OpenSSL 3.0.7 1 Nov 2022
debug1: Connecting to 10.2.10.5 [10.2.10.5] port 22.
debug1: Connection established.
debug1: Authenticating to 10.2.10.5:22 as 'root'
debug1: Host '10.2.10.5' is known and matches the ED25519 host key.
debug1: Will attempt key: /home/mark/.ssh/id_ed25519
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/mark/.ssh/id_ed25519
debug1: Server accepts key: /home/mark/.ssh/id_ed25519
Authenticated to 10.2.10.5 ([10.2.10.5]:22) using "publickey".$ ssh -v -o "IdentitiesOnly=yes" -i ~/.ssh/id_rsa root@10.2.10.5
OpenSSH_9.1p1, OpenSSL 3.0.7 1 Nov 2022
debug1: Connecting to 10.2.10.5 [10.2.10.5] port 22.
debug1: Connection established.
debug1: Authenticating to 10.2.10.5:22 as 'root'
debug1: Host '10.2.10.5' is known and matches the ED25519 host key.
debug1: Will attempt key: /home/mark/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/mark/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
(root@10.2.10.5) Password:Приведенный выше пример показывает, что в первом случае клиент предлагает серверу свой открытый ключ, сервер его принимает. Но во втором логе публичный ключ не принимается. Но вопрос в том, реально ли с помощью одного только публичного ключа, но не имея приватного, определить, разрешено пользователю, обладающим этим ключу подключение к серверу или нет? Обязательно ли для такой проверки иметь и приватный ключ? Кажется, что да, но давайте проверим доказательство этой гипотезы.
Для проверки я написал короткий код и попробовал использовать открытый ключ на целевом сервере, без использования приватного.
package main
import (
"fmt"
"io"
"golang.org/x/crypto/ssh"
)
const (
username = "root"
server = "10.2.10.5:22"
publicKey = "ssh-ed25519 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
)
func main() {
parsed, _, _, _, err := ssh.ParseAuthorizedKey([]byte(publicKey))
if err != nil {
panic(err)
}
signer := &DummySigner{PubKey: parsed}
authMethod := []ssh.AuthMethod{ssh.PublicKeysCallback(
func() ([]ssh.Signer, error) {
return []ssh.Signer{signer}, nil
},
)}
config := &ssh.ClientConfig{
User: username,
Auth: authMethod,
HostKeyCallback: ssh.InsecureIgnoreHostKey(),
}
_, _ = ssh.Dial("tcp", server, config)
if signer.Accepted {
fmt.Println("Public key was accepted by server")
return
}
fmt.Println("Public key was rejected by server")
}
type DummySigner struct {
PubKey ssh.PublicKey
Accepted bool
}
func (signer *DummySigner) PublicKey() ssh.PublicKey {
return signer.PubKey
}
func (signer *DummySigner) Sign(rand io.Reader, data []byte) (*ssh.Signature, error) {
signer.Accepted = true
return &ssh.Signature{Format: signer.PubKey.Type()}, nil
}Результат:
Public key was accepted by serverКак и ожидалось, все сработало.
Что в итоге?
Мы увидели, что с помощью нескольких строк кода можно протестировать, разрешен ли человеку с определенным публичным SSH-ключом (даже не имея его приватного ключа) доступ на сервер. Соответственно, тестирование того или иного ключа на большом количестве IP-адресов не должно стать проблемой. С помощью этого метода, используя данные из открытых источников, можно легко получить связки "юзернеймы - открытые ключи", а потом идентифицировать сервера, которые этим юзерам принадлежат.
Речь идет не о взломе сервера или учетной записи GitHub, а о сборе общедоступной информации о людях и организациях. Поэтому имейте в виду, что раз ваш публичный ключ светится в открытом доступе где-нибудь на Github, и вы установили этот же ключ для пользователя root или угадываемого имени пользователя для входа в систему на вашем сервере, то сопоставить эти два факта будет довольно легко. Я рекомендую использовать два разных публичных ключа для действий, связанных с Git, и для вашего сервера, и не публиковать нигде даже публичные ключи, используемые на сервере.
Использованная литература:
whoarethey: Determine Who Can Log In to an SSH Server
От переводчика: Это статья - очередное напоминание о том, что публичные ключи - именно публичные, и поэтому они могут использоваться для деанонимизации пользователя, если тот использует один и тот же ключ на разных серверах.
Например, зная юзернейм интересующего вас человека на Гитхабе и получив его публичный ключ оттуда, можно сканированием IP-адресов найти сервера в сети, которые он администрирует.
Либо другой случай, имея базу "юзернейм - публичный ключ", дампнутую с Гитхаба, теоретически можно найти аккаунт человека, который администрирует интересующий вас сервер - перебирать придется очень долго, но все-таки реально (особенно если отфильтровать набор юзеров для перебора по каким-то дополнительным критериям). А при возможности MitM-перехвата трафика (помните недавнюю историю с Hetzner и Jabber.ru?) где-то по пути до сервер, подслушав публичный ключ узнать аккаунт его администратора на Гитхабе можно вообще одной командой.
Совет все тот же: использовать разные публичные ключи для разных целей.
Комментарии (126)
Redduck119
03.11.2023 08:17+21Ну а то, что гитхаб легко и непринужденно отдает известные ему ключи просто по юзернейму, даже для меня было сюрпризом.А может публичный ключ он на то и публичный что может быть доступен по разным каналам.
Проблема только в том что один публичный ключ используется на разных сервисах и тогда можно определить что такой человек использует эти сервисы.
А может он (человек) и не скрывает этого, может это вовсе и не проблема.
iig
03.11.2023 08:17-3Не силен в go, ниасилил запустить этот код. Но сама концепция выглядит странно: няп, при соединении по SSH клиент просто пытается построить общий с сервером сеансовый ключ. Публичный ключ со стороны клиента здесь совершенно не нужен.
Может, в этой ssh библиотеке есть баг, и автор его обнаружил но не понял? Перевод, ага..
mayorovp
03.11.2023 08:17+4Сначала клиент посылает отпечатки своих публичных ключей, потом сервер выбирает среди них подходящий, и только после этого соответствующий приватный ключ используется для соединения.
Если не делать последний шаг - то и приватный ключ не требуется.
Antra
03.11.2023 08:17Сначала клиент посылает отпечатки своих публичных ключей
Можно чуть поподробнее?
Я клиент. У меня
~/.sshс десятком ключей. Но через-iя указываю только один конкретный приватный ключ.Что на самом деле клиент шлет на сервер? Он же не восстанавливает публичные ключи из всех этих приватных? Неужто
authorized_keys? Из чего сервер выбирает подходящий?Мне казалось, что наоборот, я как клиент могу получить публичные ключи сервера (
ssh-keyscan) и по поддерживаемым алгоритмам решить, какой из моих приватных ключей может подойти. А кучи публичных ключей на этой клиентской машине вообще может не быть (даже при наличии кучи приватных для доступа к разным ресурсам).iig
03.11.2023 08:17+1Но через -i я указываю только один конкретный приватный ключ.
Да, в openssh внутри приватного ключа лежит и публичный ;) У вас в ssh-agent может быть загружено 500 приватных ключей, и клиент их будет перебирать. НЯП, внутри реализации ssh сначала проверяется fingerprint публичного ключа (так быстрее), а при совпадении
строится соединение с использованием приватного. ssh клиент fingerprint отдельно не проверяет, но программу, которая так делает, написать можно.Antra
03.11.2023 08:17Да, в openssh внутри приватного ключа лежит и публичный ;)
Вау, не знал таких тонкостей.
VADemon
03.11.2023 08:17Вряд ли публичный хранится в приватном. Уверен, из приватного вырешивается публичный (stackoverflow говорит, openssh с запароленным приватным сначала поищет .pub ключ, чтобы не спрашивать лишний раз пароль)
mayorovp
03.11.2023 08:17+4Формат ключей 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)VADemon
03.11.2023 08:17Спасибо обоим, неправильно запомнил видимо. Наверное из-за описания команд: https://stackoverflow.com/questions/5244129/use-rsa-private-key-to-generate-public-key (комментарии + ответ golem)
iig
03.11.2023 08:17-1Вряд ли публичный хранится в приватном.
Так и есть. ssh-keygen -e
Уверен, из приватного вырешивается публичный
Это невозможно (за разумное время) by design асимметричной криптографии.
makkarpov
03.11.2023 08:17+3Это тривиально, и представляет проблему только для RSA и только если реализовывать его по википедии - с CRT ключами это тоже тривиально.
Невозможно вычислить приватный из публичного.
mayorovp
03.11.2023 08:17+6Если вы указали конкретный приватный ключ - то только его отпечаток клиент и пошлёт. Но в общем случае у вас может быть несколько ключей.
Он же не восстанавливает публичные ключи из всех этих приватных?
А что мешает это сделать?
Мне казалось, что наоборот, я как клиент могу получить публичные ключи сервера (
ssh-keyscan) и по поддерживаемым алгоритмам решить, какой из моих приватных ключей может подойти.Просто представьте сколько публичных ключей зарегистрировано у пользователя git на сервере github.com. Вы уверены что желаете каждый раз их все выкачивать? :-)
Antra
03.11.2023 08:17Просто представьте сколько публичных ключей зарегистрировано у пользователя git на сервере github.com. Вы уверены что желаете каждый раз их все выкачивать?
Не, я вообще по другому это себе представлял.
ssh-keyscan github.comвыдает лишь несколько своих ключей (ssh-rsa, ecdsa-sha2-nistp256, ssh-ed25519), а не миллионы загруженных в него пользовательских. А какой-то сервер более строго настроен, ssh-rsa не отдаст уже, и к нему с таким ломиться бесполезно, даже если пользователь такой прописал в свой authorized_keys.И думал, что гитхабу шлю key fingerprint, а не public key целиком Ибо для rsa это намного короче, а по идее должно быть достаточно, чтобы понять, что это именно я.
Но гитхаб знает отпечаток публичного ключа, т.е. его, видимо, надо сначала извлечь, чтобы посчитать fingerprint. С этим прояснилось.
А вот зачем гихаб возвращет публичный ключ по имени пользователя я так и не уловил. В какой момент это используется?
mayorovp
03.11.2023 08:17Ну так ssh-keyscan вообще-то ищет публичные ключи серверов, а не пользователей.
И думал, что гитхабу шлю key fingerprint, а не public key целиком
Вроде бы так и есть. Но разницы нет, что отпечаток, что публичный ключ одинаково хорошо позволяют идентифицировать пользователя.
А вот зачем гихаб возвращет публичный ключ по имени пользователя я так и не уловил. В какой момент это используется?
А фиг его знает, это часть Github API и к протоколу SSH отношения не имеет.
Там выше подсказывают, что в Ubuntu Server при установке можно выкачать публичные ssh-ключи с аккаунта на гитхабе.
ifap
03.11.2023 08:17+5Существует распространенное мнение, что этот метод более безопасен, чем аутентификация по паролю, и это, безусловно, правда.
Условно говоря, в ассиметричной криптографии "длина пароля" длинней, сильно длинней, очень-очень сильно длинней. И окрыленные этим обстоятельством пользователи часто забывают, что остальные болячки парольной защиты с увеличенной "длиной пароля" никуда не деваются, а некоторые даже обостяются. Скажем, логин vasya123 - совсем не уникальный, а вот 2048-битный открытый ключ пользователя vasya123 - очень даже.
13werwolf13
03.11.2023 08:17+1для кого-то стало открытием что для разных хостов и задач лучше юзать разные ssh ключи?
LeVoN_CCCP
03.11.2023 08:17Это я так понимаю новомолодёжная интерпретация старой притчи про использование одного и того же пароля на разных сайтах?
MiraclePtr Автор
03.11.2023 08:17-5Почти, только в данном случае Гитхаб по первому же запросу еще говорит "смотрите все, вот этот чувак использует вот этот пароль" ;)
iig
03.11.2023 08:17+7Для авторизации на других ресурсах это знание бесполезное, в отличие от пароля.
iig
03.11.2023 08:17+4Нет, это про деанонимизацию.
Если у вас есть учетная запись на github, с заполненным профилем
И ключ для авторизации на github вы используете еще зачем-то
То по вашему публичному ключу можно выйти на ваш профиль в github.
Не более.mayorovp
03.11.2023 08:17+2Причём выйти можно только перебором или сбором данных заранее, обратного сервиса (по ключу найти пользователя) github не предоставляет.
MiraclePtr Автор
03.11.2023 08:17обратного сервиса (по ключу найти пользователя) github не предоставляет.
Но при должном желании можно получить список всех юзеров гитхаба (у них даже API для такого есть), перебором по нему собрать базу пар "юзер - ключи" и уже искать по ней.
LeVoN_CCCP
03.11.2023 08:17+3Деанонимизация как побочный эффект. Если человек вдарился в анонимность, он не то что один и тот же ключ использовать не будет, но и ещё "логин" ("титл" или подобные поля) сделает отличающимся. Тем более если хочет анонимности то явно не будет вбивать свои данные на гитхабе или ещё как-то связывать. Доходя уже до того, чтоб с того же ИП не заходить в места которые не хочется чтоб были связаны.
А деанонимизировать человека с ником makeev_alexandr@github это странновато. Я не говорю про отдельные "хитрые" исключения.
iig
03.11.2023 08:17+1Это нужно очень хорошо и очень заранее планировать.
LeVoN_CCCP
03.11.2023 08:17+3Если собираешься для чего-либо анонимизироваться, то это кмк настолько очевидные вещи (в отличие, например, от атаки по времени или по стилю сообщений), что тут не просто очень заранее планировать, а банально здравый смысл, не?
Antra
03.11.2023 08:17+2Если собираешься анонимизироваться на 100%, то нужно не только совсем разные учетки с разными паролями и ключами, но и разные браузеры под каждый сайт и т.п., что для бытового использования нереально.
А вот если не шпион/хакер и т.п., а просто хотел иметь на разных сайтах несколько разных аккаунтов, достаточно и частичных мер. Всегда же баланс поставленных задач и усилий.
И одно дело, если какой-нибудь фейсбук палит и блокироует твой второй аккаунт - внутри одного сайта это не слишком сложно. И другое - если внезапно оказывается что тебя могут легко спалить по другому сайту, причем в рамках обычного нормального функционирования, безо всякх взломов.
Не смертельно, но неприятный сюрприз.
LeVoN_CCCP
03.11.2023 08:17Я чуть-чуть про другое. Для каждого сайта новая личность это перебор. А вот 1-2 личности (помимо тебя реального) вполне себе несложный вариант.
Меня на самом деле удивляет подобная позиция, нужно просто принять как данность - если ты (я не про вас, а "ты" это как к самому себе) залил что-то в интернет, то оно доступно для всех. Может не сразу, а через пол года и пусть оно будет под тремя сотнями замков. взломы/утечки/уязвимости - это просто банальный набор который даёт реальный шанс что всё что ты залил будет доступно где и кому угодно а ещё даже и будет украдено. И то что ты запилишь статью на хабр о том какая <s>digma</s> компания нехорошая, им от этого не будет ни жарко ни холодно.
А потому как вы верно сказали, зависит от баланса, что я ниже описал: хочешь некрасивое - забудь про себя; хочешь посмотреть порно - запусти приватный режим и логинься на порнхаб каждый раз.
А список логинов в открытом доступе? Ну блин, меня как-то опознал на хабре человек, который тут даже не зарегистрирован. По нику предположил, по комментарию обрёл уверенность.
iig
03.11.2023 08:17+1то это кмк настолько очевидные вещи
Но их учесть сложно. Вот недавно была заметка про хакера, который на форумах интересовался разными вещами по поводу telegram-ботоводства, и запилил таки этого своего бота, и запустил в prod.. И первое сообщение в него отправил со своей учетной записи ;) Упсь. Любая, самая неочевидная ошибка - и ты ошибся.
LeVoN_CCCP
03.11.2023 08:17Тут в комментарии выше как раз и говорилось про это. Хочешь делать что-то некрасивое - забудь про свои привычки - ты обычный и ты скрытый, это два человека и их нельзя связать через теорию 6-ти рукопожатий. Нельзя быть анонимным на пол-шишечки.
И тут если тебе нужно, чтоб тебя не опознали со стороны, то используешь исключительно всё новое (пусть и даже банально виртуалка заранее в ВПН-тор завёрнута), а если хочешь скрыть от жены, то можно и приватный режим браузера запустить.
iig
03.11.2023 08:17+2Нельзя быть анонимным на пол-шишечки.
Да и на 100% нельзя. Тебе кажется, что ты все предусмотрел, вырастил полноценную виртуальную личность.. А потом оказывается, что в анонимном зловреде обнаружили куски твоего кода.. Или сопоставили твою активность на форуме с обновлениями в ботнете.. И упсь.
LeVoN_CCCP
03.11.2023 08:17... а спалили потому что использовал тот же логин что и везде - makeev_alexandr :)
Antra
03.11.2023 08:17И наоборот. Зная имя на гитхаб можно получить публичный ключ. И по нему сопоставить вас с каким-то другим сервисом.
Какой-нибудь TeamCity/GtLab может посмотреть гихабовый аккаунт и понять, как этот же пользователь зарегистрирован у него.
В общем, меня напрягло, что это способ сопоставить мои разные ники и email на разных ресурсах, о котором я не подозревал.
saboteur_kiev
03.11.2023 08:17+1А гитхаб-авторизация, между прочим вполне себе широко используемая фича. Поэтому скрывать пользователей гитхаб и не должен.
Это задача самого пользователя решать использовать или не использовать тот же ключ/пароль на разных ресурсахAntra
03.11.2023 08:17+4"Авторизация через гихаб", мне кажется, из другой оперы.
Тем не менее, даже "выдать публичный ключ по имени пользователя" - тоже не какая-то уязвимость.
При этом использовать одинаковый ПУБЛИЧНЫЙ ключ и на гихабе и на гилабе я не считал опасным с точки зрения безопасности (хоть и не использовал по причине разный логин - разный ключ). А вот деанонимизация мне не нра.
Но пока это не "подсветили" в статье, я об этом не задумывался. Хотя и знал про возможность импортировать публичный ключ с гитхаба/ланчпада при установке убунты. Впредь буду еще внимательнее.
saboteur_kiev
03.11.2023 08:17+1Ну вот мне кажется, что если ты авторизируешься на каком-то другом ресурсе через гитхаб, то даже если на другом ресурсе не указывать свои ФИО, можно найти тебя через гитхаб и узнать о тебе все что есть на гитхабе
dartraiden
03.11.2023 08:17+3Скорее, логина.
Если вы используете необычный ник на всех ресурсах, то наблюдатель может предположить, что эти аккаунты принадлежат одному человеку,
Так же и с публичными ключами.
LeVoN_CCCP
03.11.2023 08:17Да, вы правы, больше о логине чем о пароле. Просто привык думать именно о "паре", что различить логин и пароль по отдельности практически бессмысленно (собственно как public и private ключи). Можно предположить, что шансы, что это один и тот же человек больше в случае ключей (чем в случае логинов), но опять же не стопроцентные, просто потому что не раз на гитхабе можно было найти пароли от различных "секретных" мест.
VADemon
03.11.2023 08:17Автор ушел от логичного вопроса как разграниченно использовать несколько ключей. Потому что по умолчанию OpenSSH (а за ним и git) будут перебирать все ключи в ~./ssh до победного. А вот это и еще удобно организовать - квест еще тот.
Подписывайтесь на мой каналв личку.iig
03.11.2023 08:17+4как разграниченно использовать несколько ключей
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.
Antra
03.11.2023 08:17+7Например, для разных аккаунтов гитхаба (корп, личный) я слегка модифицирую имя сервера и указываю в .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.comHost github-ssl.com
Hostname ssh.github.com
Port 443VADemon
03.11.2023 08:17Да это вариант, но слишком много телодвижений имхо. Я разграничил в .gitconfig на уровне файловых путей.
MiraclePtr Автор
03.11.2023 08:17Подписывайтесь на мой каналв личку.Не надо в личку, пожалуйста. У меня там еще больше десятка непрочитанных сообщений после предыдущих статей, на которые я физически не успею отвечать.
Brogahnl
03.11.2023 08:17+1Host github.com Hostname ssh.github.com Port 443 PreferredAuthentications publickey IdentityFile ~/.ssh/github.comА так перебрать тоже будет? Просто интересно.
Antra
03.11.2023 08:17Да, работает
[remote "origin"]
url = git@github.com:XXX/yyy.gitconfig:
Host github.com
Hostname ssh.github.com
Port 443
IdentityFile ~/.ssh/git-XXXРезультат:
Но обычно я во избежание накладок все-таки меняю на а-ля github-ssl.com (можно и просто github-ssl, лишь бы одинаково в конфигах гита и ssh)
VADemon
03.11.2023 08:17Если я правильно понимаю ман, то при работающем ssh-agent надо ещё IdentitiesOnly включить, чтобы наверняка. А так да, это твердая установка.
seepeeyou
03.11.2023 08:17Ну у меня по первой ссылке Not Found, хотя я использую ssh ключи для подписи и аутентификации. И чаво?
MiraclePtr Автор
03.11.2023 08:17+2Что-то делаете не так, значит. У меня все сработало.
seepeeyou
03.11.2023 08:17может я как раз всё так делаю, раз мои ключи не светятся?
MiraclePtr Автор
03.11.2023 08:17+2Как именно? Не добавляете свои ключи на гитхаб? Ну, такой себе метод. Всем хорош, кроме того, что коммитить на гитхаб не получится :-D
isden
03.11.2023 08:17Внезапно на гитхабе можно и https + gpg ключ.
MiraclePtr Автор
03.11.2023 08:17+1Комментатор выше сказал "я использую SSH-ключи для аутентификации", вот мне и интересно, как это он делает так, что они не светятся в наружу из API гитхаба, и при этом он может коммитить без проблем. Но ответа так и не последовало.
seepeeyou
03.11.2023 08:17я коммичу и подписываю свои коммиты без проблем. как с чтением?
mayorovp
03.11.2023 08:17+1Вы можете думать что используете свой ключ для авторизации, в то время как это может быть не так. Приведите ради интереса свой .git/config
seepeeyou
03.11.2023 08:17+1Нет, я именно по ssh авторизовался.
Но кстати ключ-то мой появился. Но не было еще вчера, ей богу. Хз как они считываются ("засвечиваются").
Так что мои извинения всем авторам за сомнения. Хорошая статья, напоминающая о давно известной притче "не используй один и тот же пароль на разных сайтах". Только тут не используй одну и ту же ключепару на разных сервисах.
MrKirushko
03.11.2023 08:17+4Проблема тут реально только одна и GitHub тут ни в чем не виноват. Истоки ее в том, что большинство ssh-клиентов (все что я видел) позволяют использовать для подключения конкретный закрытый ключ и никакой другой, но при этом можно ключ и не указывать, и тогда по умолчанию просто будут перепробованы все ключи что есть. В этом случае ключ как-бы считается не универсальным пропуском на сервер для всех у кого он есть, а средством аутентификации клиента для его доступа на все сервера которые готовы его принять. При этом что админы что программисты - существа крайне ленивые и вбивать лишние параметры в конфиг или командную строку, да еще и ключи каждый раз генерить - это лишняя работа, тем более что можно сделать это ровно один раз и все будет работать.
Собственно именно эта привычка использовать самые простые (первые заработавшие из загугленных) решения вместо осознанных - и есть единственный источник всех описанных в статье проблем. Избавьтесь от нее и будет вам счастье.
selivanov_pavel
03.11.2023 08:17Вопрос всем, кто пишет, что надо прописывать ключи в конфиге явно.
А что делать, если из-за требований безопасности ssh ключ в открытом виде нигде не присутствует, а живёт только в памяти ssh-agent? Или загружается из какого-нибудь YubiKey?
Опции ssh_config IdentitiesOnly и IdentityFile позволяют указать файл ключа, а вот конкретный id ключа из предоставляемых агентом выбрать не получится.
vassabi
03.11.2023 08:17вииртуалка\докер - и ходить оттуда только 1м ключем ?
selivanov_pavel
03.11.2023 08:17Если я пробрасываю в виртуалку или докер сокет ssh-агента - проблема остаётся. Если я копирую туда ключ - то получается то же самое, что и хранить ключ в открытом виде.
Можно, конечно, делать отдельную виртуалку с шифрованным диском для каждого ключа, и потом ещё на каждую виртуалку ставить весь рабочий софт, использующий ssh, но тут уже удобство работы начинает сильно страдать.
selivanov_pavel
03.11.2023 08:17Придумал решение: запускать несколько ssh-агентов c разными сокетами, и прописывать в IdentityAgent сокет до агента с нужным ключом.
Немного лучше, чем отдельные виртуалки, но всё равно дикие костыли.
Надо, чтобы ssh мог запрашивать у ssh-agent ключ только с заданным отпечатком, и его прописывать в конфиг.
vadimr
03.11.2023 08:17-2Весь смысл шифрования с открытым ключом заключается в том, что публичный ключ распространяется максимально широко, чтобы невозможно было его подменить. Совершенно очевидно, что это идейно несовместимо с анонимизацией. И не в гитхабе тут дело.
Совет использовать разные ключи - это фактически попытка из рабочей схемы с открытым ключом сделать кривое подобие схемы с секретным ключом. Учитывая, что доверенного канала связи, требуемого для передачи секретного ключа, в интернете нет, то автоматически при этом схема становится уязвимой к MITM.
Antra
03.11.2023 08:17+3Весь смысл шифрования с открытым ключом заключается в том, что публичный ключ распространяется максимально широко, чтобы невозможно было его подменить.
Это где-то написано? Или ваше предположение?
Я, к примеру, считал, что идея в том, что публичный ключ можно распространить без доверенного канала. Про то, что его нужно максимально шриоко распространять для каких-то дополнительных проверок я не слышал.
vadimr
03.11.2023 08:17+4Как вы его собираетесь распространять без доверенного канала? Вся идея в том, чтобы ваш получатель мог независимо от вас залезть, скажем, на гитхаб, и убедиться, что там содержится точно такой же ваш публичный ключ, и следовательно, на этот раз ему предлагаете ключ действительно вы, а не злоумышленник от вашего имени.
Прямо в Википедии в статье "Криптосистема с открытым ключом" в разделе "Общие принципы" можно причитать:
Владелец двух ключей никому не сообщает закрытый ключ, но передает открытый ключ контрагентам или делает его общеизвестным.
Поскольку прямая передача между контрагентами в интернете исключена, то остаётся второй способ.
Когда люди ещё пользовались в интернете криптографией осознанно, а не в силу моды, то многие даже в подпись всех своих сообщений вставляли pgp fingerprint, являющийся хешем публичного ключа.
netch80
03.11.2023 08:17Поскольку прямая передача между контрагентами в интернете исключена,
Она производится внесетевыми средствами, и на этом всё стоит. Ключи CA roots Мозиллы или корневые DNSSEC держатся на том, что люди, которые за них отвечают, регулярно встречаются вживую.
то остаётся второй способ.
Нет, не обязательно, и он точно не единственный, потому что сам вопрос доверия источнику публикации окончательно может быть решён только средствами вне Интернета.
то многие даже в подпись всех своих сообщений вставляли pgp fingerprint, являющийся хешем публичного ключа.
Которая давала только возможность сверить разные сетевые источники на то, что источник подписи один и тот же, но не давала возможность убедиться, например, что тот, кто подписывается Linus Torvalds, зовётся в реале так же, а не является, например, Аллой Пугачёвой, или тысячей индусов в одной локалке с шареным ключом.
vadimr
03.11.2023 08:17Она производится внесетевыми средствами, и на этом всё стоит. Ключи CA roots Мозиллы или корневые DNSSEC держатся на том, что люди, которые за них отвечают, регулярно встречаются вживую.
Для Мозиллы это верно, но анонимы же не заверяют свои ключи в центрах сертификации.
netch80
03.11.2023 08:17Как уже сказал, доверие к такому источнику, про который вы знаете только подпись одним и тем же ключом, остаётся на уровне "верю, что это один и тот же человек писал" (ну, если мы предполагаем, что не сидят несколько под одним акаунтом и что коты ещё не умеют писать в Интернет что-то длиннее "ЯКОТ"). Для любого более серьёзного доверия нужен внешний источник. Но если человек подписывается, условно, Вася Пупкин на хабре, на LOR и в email и пишет на одни и те же темы со схожим уровнем компетенции, я могу считать, что это он и что его так зовут.
Во времена ранних PGP в крупных городах производились "сессии взаимной подписи" - в определённом месте собирались люди, которые друг у друга верифицировали документы (паспорт, права - что там где применяется) и тогда принимали друг у друга ключи - и подписывали их на публичных PGP-серверах. Не знаю, насколько эта традиция сейчас жива, давно не слышал.
vadimr
03.11.2023 08:17Это всё, безусловно, верно.
Скажу больше – сама идея подтверждения личности субъекта, которого вы не знаете в реале (а тем более заведомого анонима) содержит логическое противоречие.
Antra
03.11.2023 08:17Как вы его собираетесь распространять без доверенного канала?
Смотря что вы понимаете под "Доверенным каналом". Возможно мы сейчас вообще про разное говорим.
Сервер Гихаба мне дал свой публичный ключ (SSL/TLS) просто по обычному незащищенному Интернету.
Я залил ему свой публичный SSH ключ внутри HTTPS.
Теперь я могу к нему подключаться по SSH
Я бы не назвал это все "доверенным каналом". Тем не менее, это решает мою задачу - безопасного подключения к серверу Гитхаба по SSH. И при этом я не поделился ничем "секретным". Если кто-то взломает гитхаб и украдет мой публичный ключ - ну и ладно, доступа к моим ресурсам на других серверах он не получит.
При этом я не вижу дополнительных преимуществ для безопасности в широком распространении моего публичного ключа в случае SSH (GPG для подписи - другая история).
vadimr
03.11.2023 08:17Публичный ключ невозможно "украсть", он на то и публичный. Вся схема безопасности построена на том, что он известен максимально широкому кругу лиц.
А вот ваш анонимный обмен с гитхабом небезопасен, так как гитхаб не имеет возможности сверить ваш публичный ключ с другими источниками и убедиться, что это именно вы, а не прокси между вами и гитхабом. Гитхаб, правда, в любом случае не стал бы этого делать, но это означает только то, что ваш обмен с гитхабом в любом случае небезопасен. У вас нет способа убедиться, что гитхаб отвечает вам на ваши запросы, а не злоумышенника посередине.
Antra
03.11.2023 08:17гитхаб не имеет возможности сверить ваш публичный ключ с другими источниками и убедиться, что это именно вы
Видимо я не понимаю саму концепцию. Что значит "именно я" для Гитхаба?
Ему же пофиг, как меня зовут и какой у меня номер паспорта. Вполне достаточно того, что некто, ранее подключавшийся к нему по имени и паролю, теперь может так же подключиться и по публичному ключу.
У вас нет способа убедиться, что гитхаб отвечает вам на ваши запросы, а не злоумышенника посередине.
У меня как раз есть. Достаточно проверить, что сертификат, удостоверяющий, что я подключен именно к github.com, выдан доверенным центром сертификации, а не каким-нибудь НУЦ.
А вот Гитхаб не может быть уверен в этом. Ну вдруг я проигнорировал предупреждение в браузере или вовсе добавил условный НУЦ в доверенные.
vadimr
03.11.2023 08:17У меня как раз есть. Достаточно проверить, что сертификат, удостоверяющий, что я подключен именно к github.com, выдан доверенным центром сертификации, а не каким-нибудь НУЦ.
У вас есть способ убедиться, что автор ответов - гитхаб. Но на чьи запросы он вам отвечает - вы не знаете.
Человек посередине может выкинуть ваш запрос к гитхабу и послать свой запрос "пришли мне троян из моего проекта", зашифрованный его открытым ключом и подписанный подписью гитхаба. После чего расшифровать этот ответ своим приватным ключом, зашифровать вашим открытым ключом и отправить вам. И вы получите настоящий подписанный гитхабом ответ, но на чужой запрос.
vadimr
03.11.2023 08:17Выше, конечно, имел в виду, что уже ответ гитхаба зашифрован открытым ключом злоумышленника и подписан гитхабом.
Antra
03.11.2023 08:17+1Можно вас пропросить чуть подробнее расписать цепочку?
Ведь я вижу в браузере сертификат гихаба, подписанный реальным УЦ, а не MITM. Далее шифрую сессию ключами, выработанными совместо с ним (он шифрует своим приватным ключом, я расшифровываю это его публичным ключом, подтвержденным доверенным УЦ).
В какой момент произойдет подмена? Как я расшифрую якобы ответ гитхаба, зашифрованный невесть кем, сессионным ключом, о котором договорился с гитхабом?
vadimr
03.11.2023 08:17Ведь я вижу в браузере сертификат гихаба, подписанный реальным УЦ, а не MITM.
Да, потому что сообщения гитхаба подписывает реальный гитхаб.
Далее шифрую сессию ключами, выработанными совместо с ним (он шифрует своим приватным ключом, я расшифровываю это его публичным ключом, подтвержденным доверенным УЦ).
Нет. В нормальной ситуации он шифрует вашим публичным ключом, а вы расшифровываете своим приватным ключом.
В хакнутой ситуации он шифрует публичным ключом митма, так как для него нет разницы между митмом и вами в силу вашей анонимности, затем митм расшифровывает своим приватным ключом, снова зашифровывает вашим публичным ключом и отдаёт вам.
В какой момент произойдет подмена? Как я расшифрую якобы ответ гитхаба, зашифрованный невесть кем, сессионным ключом, о котором договорился с гитхабом?
Сообщения в системах шифрования с открытым ключом, в том числе и в ssh, шифруются открытым ключом получателя. Вы будете расшифровывать сообщения реального гитхаба, зашифрованные вашим открытым ключом у митма.
А подмена будет происходить на пути от вас к гитхабу, так как гитхаб вас не знает и ему плевать, от кого получать запросы.
isden
03.11.2023 08:17+1Схема все еще не очень понятна. Если я в браузере вижу нормальный сертификат гитхаба - это значит я подключен к реальному гитхабу и все коммуникации в рамках этой сессии происходят с реальным гитхабом (т.е. я ему отправляю запросы и получаю от него ответы). Если там есть кто-то посередине - в браузере не будет нормального сертификата гитхаба (ситуацию с продажным УЦ не рассматриваем). Если в ответ гитхаба кто-то вдруг вклинится - браузер просто не примет такой ответ и ругнется в консоль.
Можете прямо по шагам расписать схему?
vadimr
03.11.2023 08:17-2По направлению от гитхаба к вам вы получаете данные с реального гитхаба. Только не те, которые вы просили, потому что вместо вас попросил митм, а направление от вас к гитхабу никто не контролирует, так как вашу подлинность никто не удостоверял и не проверял.
Коммуникация имеет два направления, и она, вообще говоря, анизотропна.
isden
03.11.2023 08:17+3Объясните как?
Вот я начинаю сессию со своей стороны. Делаю хендшейк, договариваемся о сессионных ключах. Этими ключами шифруются мои запросы и ответы гитхаба. В момент когда подключение установлено я вижу сертификат гитхаба.
На каком этапе криптография ломается?
vadimr
03.11.2023 08:17-4Я ж расписал выше.
Сообщения гитхаба настоящие, но направлены митму. Ваши сообщения выкидываются и заменяются сообщениями митма. Сессионный ключ сервера в сессии настоящий, ваш сессионный ключ – не настоящий (но об этом никому не известно, кроме митма, так как вы свой открытый ключ скрываете от широкой публики).
MiraclePtr Автор
03.11.2023 08:17+2Не сработает. Мой клиент просто не подключится к митму вместо гитхаба, потому что митм не сможет предоставить достоверный сертификат с нужным доменом.
vadimr
03.11.2023 08:17-4Митм просто пересылает вам реальные сообщения гитхаба, перешифровывая вашим ключом.
isden
03.11.2023 08:17+2Откуда он возьмет наши сессионные ключи? Ему тогда нужно вклиниваться до хендшейка, и предоставлять правильный сертификат гитхаба.
vadimr
03.11.2023 08:17-2Да, конечно, он вклинится до хендшейка. Сессионный ключ гитхаба ему пришлёт гитхаб, а ваш сессионный ключ он прочтёт в вашем первом сообщении гитхабу при хендшейке.
isden
03.11.2023 08:17+2Подождите, вы ниже пишете про ssh. А чуть выше обсуждали подключение в браузере. Как так?
По поводу хэндшейка - а где он возьмет валидный сертификат гитхаба, чтобы сделать хэндшейк безпалева?
vadimr
03.11.2023 08:17Браузер упоминался только в том контексте, что в нём можно посмотреть сертификат с открытым ключом гитхаба.
Ключ гитхаба для хендшейка пришлёт ему сам гитхаб.
Antra
03.11.2023 08:17+2Браузер упоминался как достаточно надежный способ залить публичный ключ в свой аккаунт на Гитхабе через недоверенный Интернет. И потом уже подключаться к своему же (тому же) аккаунту на Гитхабе уже через ssh.
Это было в рамках ответа на "Как вы его собираетесь распространять без доверенного канала?"
А ключевое мое непонимание вашей позиции заключалось в "При этом я не вижу дополнительных преимуществ для безопасности в широком распространении моего публичного ключа в случае SSH"
vadimr
03.11.2023 08:17-2Чей хост вы собрались там найти или не найти?
Для вас хост гитхаба будет known, потому что вы будете получать его настоящие сообщения, просто переупакованные. Для гитхаба ваш хост будет unknown, потому что вы аноним, а все дела гитхаб ведёт с mitm.
isden
03.11.2023 08:17+1Если там будет кто-то посередине, то хэш изменится и мой клиент ssh ругнется. Собственно, именно для такого этот механизм и был придуман.
vadimr
03.11.2023 08:17-2Хеш чего изменится? Вы получаете настоящие, подлинные сообщения гитхаба. Они не меняются по своему содержанию в расшифрованном виде.
mayorovp
03.11.2023 08:17+1Хеш публичного ключа. Вы не можете провести mitm-атаку не подменив этот ключ.
vadimr
03.11.2023 08:17-2Почитайте внимательно описание атаки выше. Я провожу mitm атаку только на направление от юзера к серверу, и подменяю, соответственно, только публичный ключ юзера, но не публичный ключ сервера. А юзер по условию анонимен, поэтому такая подмена никому не заметна.
mayorovp
03.11.2023 08:17+1Вы не можете этого сделать без подмены ключа сервера. Никак.
Чтобы узнать сессионный ключ - вам необходимо знать какие параметры послал клиент серверу, а они зашифрованы открытым ключом сервера и прочитать их может только сервер.
Вы можете сколько угодно притворяться перед сервером, но для MITM-атаки вам надо обмануть и сервер, и клиента.
vadimr
03.11.2023 08:17Да, наверное, вы правы. Возникнет проблема на этапе создания сессионного ключа для клиента.
MiraclePtr Автор
03.11.2023 08:17+3Это невозможно. Сама суть механизма TLS именно в том, чтобы подобное было невозможно.
При хендшейке сертификат, предоставленный сервером, содержит его открытый ключ, который нужно использовать для шифрования сообщений, отправляемых на сервер. После проверки действительности сертификата клиент генерирует pre-master secret, и потом используя открытый ключ сервера из сертификата, клиент шифрует это значение и отправляет его на сервер. Со своей стороны, сервер использует свой закрытый ключ для расшифровки pre-master secret. На этом этапе и клиент, и сервер имеют server random data, client random data и pre-master secret. На основе них они вычисляют общий сеансовый ключ. То есть если вы представились чужим сертификатом - вы не сможете расшифровать переданные вам данные и получить сессионные секреты, потому что у вас нету закрытого ключа. А если вы в mitm модифицируете сертификат, подсунув в него свой открытый ключ, то такой сертификат не пройдет проверку подлинности.
Серьезно, нет смысла объяснять очевидное, разберитесь в вопросе перед тем как делать такие утверждения. RFC протокола TLS есть в открытом доступе. А потом попробуйте реализовать такой MitM (и чтобы любой браузер принимал такие подключения как доверенные без дополнительных телодвижений на клиенте) на любом языке. Если получится - вам Гугл за такое по bug bounty выплатит миллионы.
MiraclePtr Автор
03.11.2023 08:17+2Ваш оппонент выше несколько комментариев подряд говорил про TLS (и про браузеры), а вы ему на это отвечали, вы уж определитесь.
Впрочем, в SSH примерно то же самое. При попытке MitM-подмены поменяется видимый вам публичный ключ (identity) сервера, а при его несовпадении с сохраненным ранее (можно даже заранее добавить вручную) приличные SSH-клиенты бьют тревогу и вообще не дают юзеру подключаться.
MiraclePtr Автор
03.11.2023 08:17+1Оно ему и не надо. Факт MitM будет выявлен со стороны вашего клиента, а не со стороны гитхаба.
vadimr
03.11.2023 08:17-2Каким образом? Ваш клиент будет получать подлинные сообщения гитхаба с его настоящим server identity.
MiraclePtr Автор
03.11.2023 08:17+1Не будет. Потому что если MitM представится identity (открытым ключом) гитхаба, то клиент будет использовать именно этот открытый ключ сервера при хэндшейке, и не обладая соответствующим ему закрытым ключом MitM не сможет получить сессионные ключи для расшифровки трафика. Возможно только одно из двух: либо MitM представляется identity гитхаба, но не может подслушивать/изменять передаваемый трафик, либо может, но тогда он засветит некорректный identity.
vadimr
03.11.2023 08:17-2Естественно, митм, не обладая закрытым ключом гитхаба, не может подслушать сообщения со стороны клиента после хендшейка, но у него и нет задачи это делать. Также у него нет задачи представляться гитхабом и подделывать его идентити. Вы спорите с утверждениями, которых я не делал.
Всё, что должен сделать Митм - это послать запрос серверу от своего собственного имени и передать ответ сервера клиенту, расшифровав своим ключом и зашифровав открытым ключом клиента.
MiraclePtr Автор
03.11.2023 08:17послать запрос серверу от своего собственного имени и передать ответ сервера клиенту
На каком этапе? На этапе хендшейка, или когда соединение между клиентом и настоящим сервером уже установлено?
sensem
03.11.2023 08:17А если 22-й (дефолтный) порт поменять на какой-то другой, то это сильно усложнит задачу.
MiraclePtr Автор
03.11.2023 08:17Не особо. При перевешивании SSH на другой порт поток долбящихся в sshd сканеров становится меньше, но не сильно - fail2ban все равно регулярно срабатывает. Да, перебирать приходится сильно больше, но тем не менее возможно.
isden
03.11.2023 08:17Раз в полгода (или как набигать начинают) инкрементируете номер порта и наслаждаетесь чистыми логами :)
F2b помогает далеко не всегда. У меня основные засиратели логов - это дятлы делающие по одному запросу с разных адресов. Хотя не очень понятен смысл, ибо там сразу отлуп с требованием ключа.
MonkAlex
Так, а что в термине "публичный ключ" неясно, что автор нас пугает?
И да, везде при работе с ключами явно пишут - используйте отдельный ключ на каждый сервер. Т.е. ключ для гитхаба должен быть только ключем для гитхаба.
MiraclePtr Автор
Автор (не я, я лишь сделал перевод) говорит базовые вещи, о которых все постоянно забывают, поэтому не лишним будет напомнить о них еще раз.
Ну а то, что гитхаб легко и непринужденно отдает известные ему ключи просто по юзернейму, даже для меня было сюрпризом.
uuger
а для вас не будет сюрпризом, что существуют целые каталоги открытых ключей типа https://keys.openpgp.org ?
MiraclePtr Автор
Это не сюрприз. Разница в том, что в эти реестры люди сами загружают свои ключи, специально для того чтобы пошарить их со всеми желающими (например, чтобы им могли слать зашифрованные емайлы).
uuger
Точно так же вы можете использовать публичный ssh ключ для доступа не на свой сервер, а к компьютеру учебного заведения / работодателя / итд, где тамошний админ может зайти в домашний каталог любого из пользователей. А в здешней дискуссии все почему-то сравнивают доступ к гитхабу с доступом к своим единолично администрируемым машинам
ExTalosDx
pgp ключи это немного другое и работает иначе. Кто с Arch Linux работал, тот представляет.
MonkAlex
Поэтому и явно написал что "автор", понимая, что это перевод =)
С одной стороны для меня это не сюрприз, что гитхаб отдает многое. С другой - да, это стрёмно, потому что на странице добавления ключей никакой информации об этом не вижу.
Fenex
Я даже встречал некоторый софт, который использует эту публичность у ключей юзеров. Самый известный, пожалуй, это установщик Ubuntu Server: во время установки ОС предлагается ввести имя пользователя на гитхабе и прописать все публичные ключи в `~/.ssh/authorized_keys`.
iig
Ошибся одним символом и случайно дал доступ какому-то анонимусу из github ;)
Antra
Ну так не получится залогиниться на сервер. Придется сразу же переустановить, коли от парольного доступа отказались.
VADemon
GitLab честно писал, что добавленные ключи всем доступны будут. Только не помню, чтобы описывали как.
vikarti
Для меня кстати сюрпризом это не было. Потому что инсталлеры Ubuntu с определенного момента умеют настраивать доступ к машине по...username с гитхаба. Вот именно через этот механизм.
grossws
Внизу, скорее всего, через
cloud-init, у него есть директиваssh_import_id. Оно сейчас широко используется для большинства cloud образов/сборок в совершенно разных местах, начиная от соотв. образов дистрибутивов у самих вендоров дистрибутивов до облачных провайдеров типа hetzner и систем типа lxd. Если рядом фигурируют слова типаcloud-configилиuser-data-- это оно)saboteur_kiev
Мне кажется, что автор намекает на уязвимость типа
"Извините, но этот пароль уже использует юзер Вася, введите другой пароль"