LINUX.ORG.RU

SSH Keys и bitbucket.org

 , ,


0

1

Недавно возникла проблема аутентификации Git на Bitbucket

$ git pull
Password for 'https://******@bitbucket.org': 
remote: Because you enabled two-step verification for your Atlassian account, you'll need to authenticate with an app password. Create an app password at https://bitbucket.org/account/admin/app-passwords
fatal: unable to access 'https://bitbucket.org/******/******.git/': The requested URL returned error: 403

При этом two-step verification моего Atlassian аккаунта был включен гораздо раньше, но до сих пор команды вроде git pull продолжали работать по-прежнему, с простым запросом пароля. Предлагаемый выше app password работает, но пользоваться им совершенно неудобно, непрактично и, на мой взгляд, несекьюрно. Это просто ещё один пароль, сгенерированный самим bitbucket-ом. Очень длинный и сложный пароль, который я никогда не запомню и буду вынужден хранить в каком нибудь текстовом файле для постоянного copy/paste от туда.

Я решил попробовать использовать SSH Keys вместо app password. При помощи ssh-keygen сгенерировал пару RSA ключей, публичный ключ скопировал в https://bitbucket.org/account/settings/ssh-keys/ командой ssh-add -l проверил, что ssh-agent видит новые ключи и попробовал протестировать подключение, но оно не работает

$ ssh -T git@bitbucket.org
git@bitbucket.org: Permission denied (publickey).

Наш айтишник говорит, что открыл по этому поводу тикет и в Bitbucket сейчас разбираются. У нас эта проблема появилась лишь у части сотрудников и неодновременно. У остальных доступ по ssh пока продолжает работать.

Кто-то ещё с этим сталкивался?


Оказалось, что RSA более не считается достаточно защищённым и ключи должны генерироваться алгоритмом ED25519, командой ssh-keygen -t ed25519

Нашёл это так:

$ ssh -vT git@bitbucket.org
...
...
debug1: Next authentication method: publickey
debug1: Offering public key: /home/******/.ssh/id_rsa RSA SHA256:******************************************* agent
debug1: send_pubkey_test: no mutual signature algorithm
...
...

Про «no mutual signature algorithm» загуглил эту полезную статью и там прочитал про ED25519:

https://confluence.atlassian.com/bitbucketserverkb/ssh-rsa-key-rejected-with-message-no-mutual-signature-algorithm-1026057701.html

hummer
() автор топика
Ответ на: комментарий от Oleg_Iu

RSA хотят депрекейтнуть в ближайшем будущем, но пока что он используется по-умолчанию утилитой ssh-keygen.

hummer
() автор топика
Ответ на: комментарий от EXL

Как то доверия ED25519 нету.

это еще почему?

Lrrr ★★★★★
()
https://******@bitbucket.org
https://bitbucket.org/******/******.git/
The requested URL returned error: 403

Какое отношение к вопросу имеют SSH-ключи, если ты лезешь на BitBucket по HTTPS?

Bass ★★★★★
()
Ответ на: комментарий от Bass

Вначале лез по HTTPS, затем, из-за two-step verification и неудобности app password, начал лезть по SSH. Перечитай.

hummer
() автор топика
Ответ на: комментарий от hummer

А, ясно.

Тогда я бы попробовал ssh -vvv, чтобы убедиться, что твой клиент посылает правильный ключ.

А ещё использовал бы https://github.com/arthepsy/ssh-audit, чтобы выяснить, какие на той стороне требования а) к ключу и б) к SSH-клиенту.

Bass ★★★★★
()
Последнее исправление: Bass (всего исправлений: 1)
Ответ на: комментарий от Bass

Тогда я бы попробовал ssh -vvv, чтобы убедиться, что твой клиент посылает правильный ключ.

-Tv, с которым я пробовал проверить SSH подключение, показывал из каких файлов он посылает ключи.

А ещё использовал бы https://github.com/arthepsy/ssh-audit, чтобы выяснить, какие на той стороне требования а) к ключу и б) к SSH-клиенту.

Спасибо, но тогда, наверное, лучше его более активно развиваемый форк:

https://github.com/jtesta/ssh-audit/

hummer
() автор топика
Ответ на: комментарий от hummer

Спасибо за ссылку.

Я правильно понимаю, что на bitbucket.org стоит древний сервер, который не умеет rsa-sha2-512 или rsa-sha2-256, если эти алгоритмы предлагает современный клиент?

И ещё – я правильно понимаю, что ни на клиентской, ни на серверной стороне нельзя включить принудительное использование rsa-sha2-512/256, и в результате приходится отключать ssh-rsa целиком?

Bass ★★★★★
()
Ответ на: комментарий от Bass

Не знаю, видимо да. Вот о версии их sshd, из выхлопа ssh-audit:

(gen) banner: SSH-2.0-conker_fd15f4a5a7-dirty conker-3003
(gen) compatibility: OpenSSH 6.5-6.6, Dropbear SSH 2013.62+
hummer
() автор топика
Ответ на: комментарий от hummer

Update: по поводу второго вопроса в моём сообщении:

я правильно понимаю, что … на серверной стороне нельзя включить принудительное использование rsa-sha2-512/256, и в результате приходится отключать ssh-rsa целиком?

– я таки разобрался. На своём сервере всё можно:

HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256,rsa-sha2-256-cert-v01@openssh.com

В результате ssh-audit будет выдавать нечто подобное:

# host-key algorithms
(key) ssh-ed25519                           -- [info] available since OpenSSH 6.5
(key) rsa-sha2-512 (2048-bit)               -- [info] available since OpenSSH 7.2
(key) rsa-sha2-256 (2048-bit)               -- [info] available since OpenSSH 7.2

Другое дело, что ButBucket умеет только

# host-key algorithms
(key) ssh-dss                        -- [fail] using small 1024-bit modulus
                                     `- [fail] removed (in server) and disabled (in client) since OpenSSH 7.0, weak algorithm
                                     `- [warn] using weak random number generator could reveal the key
                                     `- [info] available since OpenSSH 2.1.0, Dropbear SSH 0.28
(key) ssh-rsa (2048-bit)             -- [fail] using weak hashing algorithm
                                     `- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.28
                                     `- [info] a future deprecation notice has been issued in OpenSSH 8.2: https://www.openssh.com/txt/release-8.2

В этом смысле, GitHub и GitLab предпочтительнее, а упомянутая статья позорит собственный же сервис ButBucket, принадлежащий тому же Atlassian.

И да, дело не в формате ключа. RSA-ключами можно пользоваться и впредь, и совсем не обязательно мигрировать на Ed25519.

Достаточно лишь на собственных SSH-серверах, если их версия ниже, чем 8.2, убрать ssh-rsa из списка HostKeyAlgorithms.

Bass ★★★★★
()
Последнее исправление: Bass (всего исправлений: 1)
Ответ на: комментарий от Bass

Достаточно лишь на собственных SSH-серверах, если их версия ниже, чем 8.2, убрать ssh-rsa из списка HostKeyAlgorithms.

А причём тут собственный SSH сервер? Проблема в том сервере, который на стороне bitbucket.org

hummer
() автор топика
Ответ на: комментарий от hummer

В контексте заданного тобой вопроса – ни при чём.

Но изменения в OpenSSH касаются ведь не только сервиса BitBucket.

Bass ★★★★★
()
Ответ на: комментарий от Bass

То есть ты предлагаешь изменить то, как HostKeyAlgorithms настроен по умолчанию, на что-то менее безопасное. В статье, которую ты нашёл вслед за мной, как раз и говорится, что RSA теперь считается менее безопасным и надёжнее использовать ED25519.

hummer
() автор топика
Ответ на: комментарий от hummer

Нет.

Я предлагаю настроить этот параметр безопасно в серверах, версия которых ниже, чем 8.2. То, как оно было настроено по умолчанию месяцы или годы назад, более не считается безопасным.

Статья касается исключительно настройки нового (8.2+) клиента для совместимости со старым сервером. То, что рекомендуется в ней, является ухудшением безопасности в жертву совместимости (со старым сервером, напр., bitbucket.org).

Bass ★★★★★
()
4 ноября 2021 г.

Решение?

Добрый день, столкнулись с точно такой же проблемой в продакшене. Подскажите, как решили, если решилиб пожалуйста. Саппорт тикет помог?

Спасибо!

anonymous
()
Ответ на: Решение? от anonymous

Добрый день, столкнулись с точно такой же проблемой в продакшене. Подскажите, как решили, если решилиб пожалуйста.

Решил переходом на новые ключи, сгенерированные по схеме ed25519 вместо rsa sha256.

SSH Keys и bitbucket.org (комментарий)

Саппорт тикет помог?

Нет, решил проблему самостоятельно, не дожидаясь тикета. Тикет и не помог бы, ибо

https://confluence.atlassian.com/bitbucketserverkb/ssh-rsa-key-rejected-with-message-no-mutual-signature-algorithm-1026057701.html

hummer
() автор топика
Ответ на: комментарий от hummer

Целую статью прочитал, а вместо SHA-1 небезопасным теперь считаешь RSA? Старый добрый анон.

EDIT: ещё и не анон

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от Legioner

ssh-keygen поддерживает следующие алгоритмы ключей, через параметр -t

[-t dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa]

В каком месте здесь можно указать тип SHA? Везде, где обсуждают данную проблему пишуть, что -t rsa (используемый по-умолчанию) генерирует теперь невалидные ключи и что правильным решением является использование ключей, сгенерированный с указанием -t ed25519 или -t ecdsa.

hummer
() автор топика
Ответ на: комментарий от hummer

В ключе нет хеша, если ты не используешь CA (ты его не используешь с вероятностью 99%). Ключ это просто ключ. Хеш используется в самом протоколе, когда идёт обмен ключами и тд. Если одна из сторон использует очень старую версию ssh, то эта старая версия ssh будет пытаться использовать sha1 в протоколе при обмене ключами, а новая откажется работать с этим алгоритмом хеширования. Если обе стороны используют более-менее новые клиенты, то проблем не будет.

А в атлассиане сидят идиоты. Впрочем не опасные, ничего плохого в ed25519 нет. Но отключать rsa мотивируя это тем, что sha1 плохой, это признак того, что на этот тикет отвечал человек, у которого нет никакого представления о криптографии в общем и об ssh в частности.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от hummer

правильным решением является использование ключей, сгенерированный с указанием -t ed25519 или -t ecdsa.

На GitHub об этом «слегка» по другому говорится (https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account):

RSA keys (ssh-rsa) with a valid_after before November 2, 2021 may continue to use any signature algorithm. RSA keys generated after that date must use a SHA-2 signature algorithm. Some older clients may need to be upgraded in order to use SHA-2 signatures.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.