Почему не работает авторизация в Gitlab по SSH?
spoilerДоброго времени суток. Пытаюсь настроить подключение к Gitlab по SSH. Сгенерировал пару ключей ED25519, добавил публичный ключ в Gtilab, пытаюсь подключиться - после ввода пасскея, ключ игнорится, и предлагает авторизоваться по паролю
debug1: Trying private key: C:\Users\alpha/.ssh/id_ed25519 Enter passphrase for key 'C:Usersalpha/.ssh/id_ed25519': debug3: sign_and_send_pubkey: ED25519 SHA256:O7D+2QkNdt667645DEkdByztn5ERyze4JS8888888 debug3: sign_and_send_pubkey: signing using ssh-ed25519 debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,password debug1: Trying private key: C:\Users\alpha/.ssh/id_xmss debug3: no such identity: C:\Users\alpha/.ssh/id_xmss: No such file or directory debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password alpha@gitlab.mydomain.ru's password: |
debug1: Trying private key: C:\Users\alpha/.ssh/id_ed25519 Enter passphrase for key 'C:Usersalpha/.ssh/id_ed25519': debug3: sign_and_send_pubkey: ED25519 SHA256:O7D+2QkNdt667645DEkdByztn5ERyze4JS8888888 debug3: sign_and_send_pubkey: signing using ssh-ed25519 debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,password debug1: Trying private key: C:\Users\alpha/.ssh/id_xmss debug3: no such identity: C:\Users\alpha/.ssh/id_xmss: No such file or directory debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password alpha@gitlab.mydomain.ru's password:
В чём может быть причина?
Подключается он точно к SSH Gitlab-а, потому что SSH самого сервера на другом порту
UPD:
Как я подозреваю, проблема в другом. Коннект видимо шёл на шлюз, на котором тоже есть свой SSH, на порту 22, и с включенной авторизацией по ключу.
Ок, я перевёл SSH шлюза на другой порт, сделал проброс порта 22 на нужную мне машину с гитлабом, теперь он просто выдаёт connection refused, и всё.
Как вообще работает SSH в Гитлабе? Использует свой сервер, или локальный? Если свой - где его конфиги, логи, и т.д.?
Если локальный - как разруливается доступ к самой машине и к гиту?
Дополнительно:
Ответы:
Больше догадка чем ответ, проверьте не включен ли fips?
cat /proc/sys/crypto/fips_enabled
Если не ноль, работать не будет.
- Нет такого каталога
- My_Second_Nickname, попробуйте rsa ключ сгенерировать все же.
- akelsey, тоже пробовал, не работает. Только пробовал через Xshell, ключ генерировал в нём же:
Connection established. To escape to local shell, press 'Ctrl+Alt+]'. [01:00:39] Version exchange initiated... [01:00:39] server: SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 [01:00:39] client: SSH-2.0-nsssh2_6.0.0032 NetSarang Computer, Inc. [01:00:39] SSH2 is selected. [01:00:39] Outgoing packet: 20 (0x14: SSH2_MSG_KEXINIT) [01:00:39] Incoming packet: 20 (0x14: SSH2_MSG_KEXINIT) [01:00:39] Algorithm negotiation initiated... (Dialog mode) [01:00:39] key exchange: curve25519-sha256@libssh.org [01:00:39] host key: ssh-rsa [01:00:39] outgoing encryption: chacha20-poly1305@openssh.com [01:00:39] incoming encryption: chacha20-poly1305@openssh.com [01:00:39] outgoing mac: hmac-sha2-256-etm@openssh.com [01:00:39] incoming mac: hmac-sha2-256-etm@openssh.com [01:00:39] outgoing compression: none [01:00:39] incoming compression: none [01:00:39] Outgoing packet: 30 (0x1e: SSH2_MSG_KEXDH_INIT) [01:00:39] Incoming packet: 31 (0x1f: SSH2_MSG_KEXDH_REPLY) [01:00:39] Host authentication initiated... [01:00:39] Hostkey fingerprint: [01:00:39] rsa 2048 33:fd:c6:7c:d1:453:a3:10:0a:68:6f:fd:d8:09:22:02 [01:00:39] Accepted. Verifying host key... [01:00:39] Verified. [01:00:39] Outgoing packet: 21 (0x15: SSH2_MSG_NEWKEYS) [01:00:39] Incoming packet: 21 (0x15: SSH2_MSG_NEWKEYS) [01:00:39] Outgoing packet: 5 (0x05: SSH2_MSG_SERVICE_REQUEST) [01:00:39] Incoming packet: 6 (0x06: SSH2_MSG_SERVICE_ACCEPT) [01:00:39] User authentication initiated... (Dialog mode) [01:00:43] Sent user name 'Sample'. [01:00:43] Outgoing packet: 50 (0x32: SSH2_MSG_USERAUTH_REQUEST) [01:00:43] Incoming packet: 51 (0x33: SSH2_MSG_USERAUTH_FAILURE) [01:00:51] Outgoing packet: 50 (0x32: SSH2_MSG_USERAUTH_REQUEST) [01:00:51] Sent public key blob, type:ssh-rsa. [01:00:51] Incoming packet: 51 (0x33: SSH2_MSG_USERAUTH_FAILURE) [01:00:51] Server rejected the public blob. [01:00:52] Canceled. [01:00:52] Outgoing packet: 1 (0x01: SSH2_MSG_DISCONNECT)
Connection established. To escape to local shell, press 'Ctrl+Alt+]'. [01:00:39] Version exchange initiated... [01:00:39] server: SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 [01:00:39] client: SSH-2.0-nsssh2_6.0.0032 NetSarang Computer, Inc. [01:00:39] SSH2 is selected. [01:00:39] Outgoing packet: 20 (0x14: SSH2_MSG_KEXINIT) [01:00:39] Incoming packet: 20 (0x14: SSH2_MSG_KEXINIT) [01:00:39] Algorithm negotiation initiated... (Dialog mode) [01:00:39] key exchange: curve25519-sha256@libssh.org [01:00:39] host key: ssh-rsa [01:00:39] outgoing encryption: chacha20-poly1305@openssh.com [01:00:39] incoming encryption: chacha20-poly1305@openssh.com [01:00:39] outgoing mac: hmac-sha2-256-etm@openssh.com [01:00:39] incoming mac: hmac-sha2-256-etm@openssh.com [01:00:39] outgoing compression: none [01:00:39] incoming compression: none [01:00:39] Outgoing packet: 30 (0x1e: SSH2_MSG_KEXDH_INIT) [01:00:39] Incoming packet: 31 (0x1f: SSH2_MSG_KEXDH_REPLY) [01:00:39] Host authentication initiated... [01:00:39] Hostkey fingerprint: [01:00:39] rsa 2048 33:fd:c6:7c:d1:453:a3:10:0a:68:6f:fd:d8:09:22:02 [01:00:39] Accepted. Verifying host key... [01:00:39] Verified. [01:00:39] Outgoing packet: 21 (0x15: SSH2_MSG_NEWKEYS) [01:00:39] Incoming packet: 21 (0x15: SSH2_MSG_NEWKEYS) [01:00:39] Outgoing packet: 5 (0x05: SSH2_MSG_SERVICE_REQUEST) [01:00:39] Incoming packet: 6 (0x06: SSH2_MSG_SERVICE_ACCEPT) [01:00:39] User authentication initiated... (Dialog mode) [01:00:43] Sent user name 'Sample'. [01:00:43] Outgoing packet: 50 (0x32: SSH2_MSG_USERAUTH_REQUEST) [01:00:43] Incoming packet: 51 (0x33: SSH2_MSG_USERAUTH_FAILURE) [01:00:51] Outgoing packet: 50 (0x32: SSH2_MSG_USERAUTH_REQUEST) [01:00:51] Sent public key blob, type:ssh-rsa. [01:00:51] Incoming packet: 51 (0x33: SSH2_MSG_USERAUTH_FAILURE) [01:00:51] Server rejected the public blob. [01:00:52] Canceled. [01:00:52] Outgoing packet: 1 (0x01: SSH2_MSG_DISCONNECT)
debug1: Trying private key: C:\Users\alpha/.ssh/id_xmss
debug3: no such identity: C:\Users\alpha/.ssh/id_xmss: No such file or directory
Английским по черному написано - нет ключа, который запрашивается. Либо Вы не так назвали файл ключа, либо не туда положили.
- В самом начале же он нашёл ключ, принял его, запросил passphrase, получил его, и перепрыгнул дальше.
Проблема не в этом. Тут оказалось всё вообще в другом, делаю UPD поста
Какая ОС? В убунте мой коллега так и не смог настроить работу SSH - я отдельно поставил в чистом дебиане гитлаб и там все заработало сразу из коробки. В гитлабе есть два механизма доступа по SSH: стандартный SSH сервер - для этого при установке гитлаб настраивает пользователя git и далее через него идет все взаимодействие; и второй вариант - это отдельный SHH демон gitlab-sshd, который используется только гитлабом и запускается на отдельном порту. Тут пару месяцев назад уже был аналогичный вопрос: Как настроить работу с репозиторием GitLab через SSH?
- Debian
Гитлаб на нём поднимали задолго до меня. Как выяснить в каком варианте оно работает?
В базовом SSH не было пользователя Git, так что либо не настроено, либо второй, но хотелось бы как-то точнее узнать. Ну и вопрос так же остался, где вообще этот gitlab-sshd настраивать и логи его смотреть?В том аналогичном вопросе решением в итоге что стало? Поднятие нового сервера? Как бы совсем не хочется переустанавливать сервак. У меня собственно так же - нет такой строки в конфиге /etc/gitlab/gitlab.rb нет пункта gitlab_sshd['enable']
-
Debian
А какая версия? В чистом 12 все работает из коробки - я проверял.
Гитлаб на нём поднимали задолго до меня.
Тогда скорее всего там какие-то дополнительные настройки местные или еще что-то.
В базовом SSH не было пользователя Git, так что либо не настроено, либо второй, но хотелось бы как-то точнее узнать.
Проверить настройки гитлаба.
Ну и вопрос так же остался, где вообще этот gitlab-sshd настраивать и логи его смотреть?
В настройках гитлаба и включается и настраивается - ссылка чуть выше есть. Логи - стандартно в журнале должны быть и смотрите ман гитлаба.
Вообще, я бы рекомендовал поднять отдельно новый инстанс с дебианом под гитлаб и чтобы он там жил и ничего ему не мешало.
- VoidVolker, дополнил ответ. Нет такой строки, дебиан 9, сервер давно поднят, и работает нормально, но вот понадобилось получить доступ к Гиту по SSH
Переустанавливать полностью сервак с гитом вообще не вариант. Он и так на Дебиане, звучит как "при ошибках переустанови систему"
- А, так может тогда и версия гитлаба у вас старая? Текущая версия - v16.10.1.
Как бы совсем не хочется переустанавливать сервак.
Так а зачем его переустанавливать? Просто на отдельном сервере запустите и настройте как надо. Все равно он десяток гигов памяти и ядер жрет для адекватной работы. А старый сервер пусть и дальше крутит то, что он там крутит.
В том аналогичном вопросе решением в итоге что стало?
Не знаю, как автор решил свою проблему - он не отписался в итоге, но мой ответ отметил - вероятно тоже отдельно на новом сервере запустил.
- VoidVolker, какой смысл? Что значит "отдельный сервер"? Он и так крутится на своей виртуалке.
- VoidVolker Ясно, мне вариант с переносом не подходит. Спасибо за помощь.
- Смысл в том, чтобы не тратить кучу времени и пытаться ремонтировать то, что уже сломано, устарело и вообще непонятно что. Дебиан, конечно, легко переварит обновление до 12 версии, но все настройки и мусор останутся, а как переживает это все существующий софт - неизвестно. Поэтому, проще всего запустить новую чистую машину со свежей ОС, поставить туда гитлаб, настроить его работу и мигрировать все проекты со старого.
- My_Second_Nickname дык версия-то какая гитлаба? Может его обновить надо? И тогда можно будет использовать отдельный ссх демон его.
- VoidVolker, Ок, я вас услышал. Но придётся пытаться ремонтировать.
- My_Second_Nickname, О, прям одновременно отвечаем, чат какой-то получается. См выше - проверяйте версию гитлаба.
- VoidVolker, GitLab12.8.1 (d18b43a5f5a)
- My_Second_Nickname, проверил у себя конфиг - у меня есть конфиг встроенного sshd:
spoiler
################################################################################
## gitlab-sshd
################################################################################# gitlab_sshd['enable'] = false
# gitlab_sshd['generate_host_keys'] = true
# gitlab_sshd['dir'] = "/var/opt/gitlab/gitlab-sshd"# gitlab-sshd outputs most logs to /var/log/gitlab/gitlab-shell/gitlab-shell.log.
# This directory only stores stdout/stderr output from the daemon.
# gitlab_sshd['log_directory'] = "/var/log/gitlab/gitlab-sshd/"# gitlab_sshd['env_directory'] = '/opt/gitlab/etc/gitlab-sshd/env'
# gitlab_sshd['listen_address'] = 'localhost:2222'
# gitlab_sshd['metrics_address'] = 'localhost:9122'
# gitlab_sshd['concurrent_sessions_limit'] = 100
# gitlab_sshd['proxy_protocol'] = false
# gitlab_sshd['proxy_policy'] = 'use'
# gitlab_sshd['proxy_header_timeout'] = '500ms'
# gitlab_sshd['grace_period'] = 55
# gitlab_sshd['client_alive_interval'] = nil
# gitlab_sshd['ciphers'] = nil
# gitlab_sshd['kex_algorithms'] = nil
# gitlab_sshd['macs'] = nil
# gitlab_sshd['login_grace_time'] = 60
# gitlab_sshd['host_keys_dir'] = '/var/opt/gitlab/gitlab-sshd'
# gitlab_sshd['host_keys_glob'] = 'ssh_host_*_key'
# gitlab_sshd['host_certs_dir'] = '/var/opt/gitlab/gitlab-sshd'
# gitlab_sshd['host_certs_glob'] = 'ssh_host_*-cert.pub'Так что скорее всего версия у вас старая.
- VoidVolker, угу, а добавили его в версии 14.5
Ладно, буду или гит обновлять, или прикручивать через локальный sshd -
GitLab12.8.1 (d18b43a5f5a)
О, ну, как я и предполагал. Делайте снепшот машины, бэкапы и прочее и пробуйте обновить гитлаб. Он сейчас пакетом из репозитория ставится - смотрите как у вас установлен, возможно придется удалить существующий и добавить репозиторий и поставить из пакетов. Но, есть риск что-то сломать при миграции - я все же рекомендую на чистом инстансе попробовать сделать миграцию со старого на новый и только потом уже пытаться обновить гитлаб на самом сервере. Ну или если есть возможность клонировать вируталку полностью - то на копии экспериментировать.
- VoidVolker, переносить всех юзеров/настройки/обработчики будет не менее геморройно, чем обновлять, я думаю. Тут ещё юзеры капризные, чуть что изменилось/стало не так как привыкли - поднимается вой и жалобы директору.
Склонировать машину можно легко, я и рассматривал этот вариант, чтобы они пока на своём работали, пусть и без ssh.
Вообще не люблю обновлять на линуксах что либо, обязательно что-то ломается. и ищи потом, где они в конфигах что поменяли... -
переносить всех юзеров/настройки/обработчики будет не менее геморройно, чем обновлять, я думаю. Тут ещё юзеры капризные, чуть что изменилось/стало не так как привыкли - поднимается вой и жалобы директору.
Ну тут бы я на это не надеялся, чем ремонтировать такого монстра - лучше перенесите всё на актуальный дебиан и актуальный гитлаб, как рекомендовал VoidVolker . Потому что "попытка ремонта" в данном случае равноценна заметанию проблемы под ковёр - случится какая-нибудь авария - всё, вы без ssh не реанимируете, и шансы на реанимацию уменьшаются по мере устаревания.
Поэтому присоединяюсь к рекомендации VoidVolker - ставите рядом новый гитлаб на актуальном дебиане, полный импорт всего (желательно в выходные, чтобы разработчики помогли с тестом, как оно всё работает, чтобы условно в понедельник все вышли без проблем на новый гитлаб), и потом просто обновляете в последующем дебиан и гитлаб штатно, 16.10->16.11->17.0->итд.
Либо как крайний случай - клон виртуалки с последующим обновлением сначала дебиана, затем гитлаба 12.8.1->(все промежуточные версии)->16.10. Экспириенса поднимите на этом занятии пропорционально новым седым волосам)))
-
всё, вы без ssh не реанимируете
Почему? На самой машине есть ssh, и работает нормально. Не работает ssh именно гита.
Поэтому присоединяюсь к рекомендации VoidVolker - ставите рядом новый гитлаб на актуальном дебиане, полный импорт всего (желательно в выходные, чтобы разработчики помогли с тестом
Если бы я в своё время поднимал этот гитлаб, то может быть и было бы легко и просто взять и перенести. А тут обработчиков накручено, всё настроено лет много назад, тот кто делал, уже давно не на связи. Разрабы помогать не будут - выше объяснял почему. Тем более в выходной. Так что вариантов нет, буду клонировать, и обновлять.
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Пока нет других ответов. Будьте первым, кто поможет автору.
Ответить на вопрос
Возможно, причина проблемы с авторизацией в Gitlab по SSH заключается в неправильной настройке ключей SSH на вашем компьютере или в самом Gitlab.
Вот несколько шагов, которые вы можете предпринять, чтобы решить эту проблему:
1. Убедитесь, что у вас есть SSH-ключи на вашем компьютере. Вы можете проверить их наличие, запустив команду `ls -al ~/.ssh` в терминале. Если ключи отсутствуют, вам необходимо их сгенерировать с помощью команды `ssh-keygen`.
2. Проверьте, что публичный ключ (обычно файл с расширением `.pub`) добавлен в ваш аккаунт Gitlab. Это можно сделать, скопировав содержимое вашего публичного ключа и вставив его в раздел "SSH Keys" в настройках вашего профиля на Gitlab.
3. Убедитесь, что правильно настроен файл конфигурации SSH (`~/.ssh/config`). В этом файле должны быть указаны параметры для подключения к Gitlab по SSH.
4. Проверьте, что у вас правильно настроен удаленный репозиторий Gitlab в вашем локальном репозитории. Убедитесь, что удаленный адрес репозитория указан с использованием SSH (например, `git@yourgitlab.com:yourusername/yourrepository.git`).
Если после выполнения этих шагов проблема с авторизацией по SSH в Gitlab все еще не решена, возможно, проблема кроется в настройках самого Gitlab. В этом случае, вам следует обратиться к администратору Gitlab или в техническую поддержку для дальнейшей помощи.
Надеюсь, эти шаги помогут вам решить проблему с авторизацией в Gitlab по SSH. Если у вас остались вопросы или возникли сложности, не стесняйтесь обращаться за помощью!