А как работает авторизация «git@github.com» под капотом?

Ну так этот сервер и есть. И не обязательно самописный. Просто там работают и другие сервисы, помимо sshd.

Ты же прекрасно можешь выполнить

ssh gitlab.com

— только shell-доступ тебе никто не даст.

Как хранятся 100500 публичных ключей всех пользователей ресурса и как пользователь git получает разные привилегии в зависимости от того, с каким ключом вошёл, — вопросы открытые.

man sshd_config
/AuthorizedKeysCommand

…
PRONTO!

Вот тебе пример из gitlab. В github вероятно аналогично

~git/.ssh/authorized_keys:

command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-18",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAA3... key-name

обрати внимание на key-18. В БД есть соответствие ключей и пользователей.

GitLab можно поднять на своём сервере и авторизация по SSH через единственного юзера git точно также будет работать. Можешь посмотреть как это устроено там. Используется обычный OpenSSH из системы. Инструкция по установке GitLab не требует модификации конфига OpenSSH. Так что смотри в ~/.ssh создаваемого при установке юзера git, а также в параметры самого юзера в системе. Больше ничего.

Читаем ман:

The program should produce on standard output zero or more lines of authorized_keys output

То есть, эта штука должна выплюнуть пачку публичных ключей, которые sshd попытается «приложить» к приватным ключам, пришедшим от клиента. Но на вопрос «как git@github.com превращается в конкретно взятого kawaii_neko» это не отвечает.

~git/.ssh/authorized_keys:

Спасибо, похоже оно. Никогда бы не подумал, что это через authroized_keys решается.

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

Но на вопрос «как git@github.com превращается в конкретно взятого kawaii_neko» это не отвечает.

кавай, фантазируй, ну!.. ;) скрипт->бд->профит ))

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

Для анализа времени надо читать исходники openssh-server. Если будет узким местом - можно и пропатчить. Это не сложно.

Можешь посмотреть как это устроено там. Используется обычный OpenSSH из системы.

Или в gitolite (SSH-based gatekeeper for git repositories). Очень легковесный: там просто perl и shell скрипты.

кавай, фантазируй, ну!.. ;) скрипт->бд->профит ))

Ну после command=... из authrozied_keys все стало на свои места, да.

только shell-доступ тебе никто не даст.

Сборище тупаков… )))

https://docs.gitlab.com/ee/ssh/README.html

Сборище тупаков… )))

https://docs.gitlab.com/ee/ssh/README.html

Умничка.

Ты можешь соединиться с github/gitlab/bitbucket по SSH и выполнить хотя бы одну команду – ну, скажем, uname?

Почитай про gitolite еще

про то, какие детали в использовании sshd для 100 миллионов ключей не подскажу, я писал такой код для эрланга:

https://github.com/flussonic/ssh-proxy/blob/master/ssh-proxy.erl#L167

sshd поставляемый в самом эрланге просто вызывает код с уже указанным username и публичным ключом. Надо пойти в базу и среди всех ключей Username найти тот, который равен публичному ключу.

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

Блин столько ответов и все втирают какую-то дичь, а всё очень просто :) Надо пойти в исходники гитлаба и посмотреть, как оно устроено под капотом. Есть проект:

https://gitlab.com/gitlab-org/gitlab-shell

GitLab Shell handles git SSH sessions for GitLab and modifies the list of authorized keys.

Пример как это работает:

git pull over SSH -> gitlab-shell -> API call to gitlab-rails (Authorization) -> accept or decline -> establish Gitaly session

Подробнее можно в коде посмотреть

спасибо, коммент по делу