Для GitLab требуется git пароль @localhost для перехода к репо

Я пытаюсь запустить GitLab на моем сервере. Я выполнил инструкции по установке на странице gitlab github, и все прошло хорошо.

Проблема заключается в том, когда я создаю репо и пытаюсь

sudo git push -u origin master

Мне предлагается "git @localhost пароль:

Пользователь git не имеет пароля, поэтому это проблема.

Другие люди, столкнувшиеся с этой проблемой, предложили добавить git в AllowedUsers в моем sshd conf, но у меня нет поля AllowedUsers, поэтому это не проблема.

Я все еще довольно новичок в ssh-материале, поэтому считаю, что это какая-то проблема с ssh-ключами, хотя я попытался добавить все соответствующие ssh-ключи в /home/ git/.ssh/authorized_keys и проверить, что нет разрывы строк в файле.

Просто FYI, моя установка полностью проходит тест, указанный в вики файле gitlab:

sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production

Любые предложения, которые были высоко оценены!

ИЗМЕНИТЬ

Итак, я, наконец, обошел это, просто совершив репо с другой машины. Как бы то ни было, я был SSHed в той же машине, что и gitlab. Как только я попытался совершить передачу с машины, отличной от хоста, она отлично работала. Таким образом, это может быть решением для некоторых людей (это для нас, поскольку мы развиваемся на отдельных машинах, чем наши серверы).

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

Ответ 1

TL; DR

Ключи хранятся как на gitlab DB, так и на гитолит. Вы должны использовать папку factory build gitolite-admin.git, не используйте свою резервную копию! И перестройте ключи для гитолита позже командой обновления ключей. (обновите те ключи, которые уже сохранены внутри gitlab db до гитолита)

sudo -u gitlab -H bundle exec rake gitlab:gitolite:update_keys RAILS_ENV=production

Скорее всего, это потому, что есть что-то о том, что гитолит-ключи не сохраняются должным образом. Эти ключи (для входа) фактически сохраняются отдельно gitlab и gitolite. Для pull/push фактически используются ключи, сохраненные внутри гитолита. (git/repositories/gitolite-admin.git/index, git/. gitolite/keydir, git/. ssh/authorized_keys)

gitlab обычно должен помочь сохранить эти импортированные ключи в Интернете в файлы gitolite. Однако по некоторым причинам он потерпел неудачу. Поскольку ключи не сохраняются должным образом внутри gitolite, клиент/сервер не может использовать ключи и откатываться от пароля.

Вы должны проверить и исправить эти ключи, сохраненные внутри гитолита, чтобы исправить проблемы.

проверьте больше https://groups.google.com/forum/?fromgroups=#!topic/gitlabhq/X0z_9l7L7A8

Ответ 2

Если установка прошла успешно, это означает, что ваш gitlab может без проблем клонировать gitolite-admin repo.
Но вы говорите, что он проходит проверку статуса, что означает, что вы используете для ssh-подключения учетную запись с именем "gitlab".

Это также означает, что любой клиент будет иметь ssh с той же учетной записью "gitlab", а не "git".
Поэтому, если ваш ключ ssh был добавлен через интерфейс gitlab, вы можете git clone/git нажать на имя удаленного имени, которое будет иметь адрес '[email protected]'

Чтобы отладить еще немного, ознакомьтесь с некоторыми другими советами, упомянутыми в " "Настройка" git Удаленный SSH (git -upload-pack/ git -receive-pack)":

Если вы не можете нажать локально (на самом сервере, то есть на "localhost" ), попробуйте хотя бы a:

ssh -vvvT [email protected]

Он не должен содержать никаких паролей, поскольку существуют /home/gitlab/.ssh/id_rsa и /home/gitlab/.ssh/id_rsa.pub.

Ответ 3

Я получил ту же подсказку с паролем. Моя проблема заключалась в том, что я ограничил использование ssh только несколькими пользователями. Я добавил пользователя git в список AllowUsers sshd_config, и все отлично поработало.

Ответ 4

Убедитесь, что ваш профиль gitlab имеет общедоступный ключ ssh. Войдите в gitlab, перейдите в свой профиль и выберите кнопку "Добавить открытый ключ". Скопируйте и вставьте содержимое "keyfile".pub в поле "Ключ". Были некоторые версии gitlab, у которых была ошибка, что, когда вы добавили свой открытый ключ, он не обновил файл authorized_keys. Проверьте (но не добавляйте вручную), чтобы ваш открытый ключ находился в файле authorized_keys после добавления его в свой профиль. Если это не проблема, возможно, один из более ранних ответов поможет.

Ответ 5

на сервере git изменить /etc/ssh/sshd_config

раскомментируйте следующие строки в разделе аутентификации или добавьте их:

PubkeyAuthentication yes

AuthorizedKeysFile %h/.ssh/authorized_keys

дать вашему серверу цикл питания, а затем запустить gitlab

Ответ 6

У меня возникла проблема, которая проявляла подобные симптомы. Моя проблема заключалась в том, что у меня есть два компьютера за маршрутизатором. Маршрутизатор настроен на перенос SSH-трафика (порт 22) на компьютер 1. Gitlab установлен на компьютере 2. Я использую домен и открытый IP-адрес для подключения. Когда я нажимаю, SSH-трафик направляется на компьютер 1. На компьютере 1 пользователь git просто устанавливается git. Компьютер 1 запрашивает у меня пароль пользователя git.

Моя установка также прошла все готовые проверки.

Я не уверен, что у вас такая же проблема, но симптомы такие же, поэтому я решил, что это может помочь.

Ответ 7

Это начало происходить со мной довольно много в последнее время - для рабочих проектов git будет спрашивать меня мой адрес электронной почты и пароль. При вводе он продолжается нормально, но это раздражает.

Я могу исправить это для любого приложения, к которому у меня есть доступ, с помощью:

git config remote.origin.url [email protected]:user_org_or_co/repo_name_itself

например.

git config remote.origin.url [email protected]:smithw/bookmarkapp

Ответ 8

Ваши пользователи git и gitlab без пароля?

Как sshd_config?

проверьте, находится ли эта строка в файле: PermitEMptyPassword Yes

В любом случае, я предполагаю, что это небезопасно, в моей установке я положил это "Да", клонировал, а затем сохранил старую конфигурацию... Когда Cloning ssh_key сохраняется пользователем git, и он больше не будет запрашивать пароль.

Но теперь я сталкиваюсь с другой ошибкой, когда Im собирается нажать, для каждого нового Пользователя нам нужно переконфигурировать ssh для разрешения пустого нажатия, а затем сохранить конфигурацию.

(Я все еще не тестировал этот метод, потому что обнаружил, что моя gitlab не создает репозиции в git пользователе:/)

Ответ 9

Это может быть слишком просто, но у меня была та же проблема. Я предполагаю это, потому что он выбрал localhost как доменное имя.

Это сработало, когда я вошел с другого компьютера обратно на мою машину localhost, а затем попытался зафиксировать. Это довольно глупо, но стоит попробовать.

Ответ 10

Я перепутался с этим разом. Когда вы используете sudo git, это означает, что git запускается с правами root. Вопрос будет: вы создали SSH-ключ для root и поместили его в Gitlab?

Я предполагаю, что вы создали свой SSH-ключ без sudo (который для вашей обычной учетной записи), поместите SSH publickey в Gitlab, а затем запустите sudo git.

Вы можете попробовать запустить git без sudo. И если у вас есть проблемы с правами на доступ к папке, которые заставили вас использовать sudo в первую очередь, попробуйте предоставить вашей учетной записи пользователя доступ к этой папке. Или, возможно, попробуйте git обычно в папке с правами на запись.

Ответ 11

Здесь есть знак .

Чтобы определить причину проблемы, проверьте журналы на сервере через sudo grep sshd /var/log/auth.log.

До 13 декабря 2013 года фиксация b24d5d, проблема была вызвана машиной разработки Vagrant из-за превышения разрешений для .ssh/. Вы должны иметь:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

или ssh отказывается сделать соединение rsa и sudo grep sshd /var/log/auth.log говорит:

Authentication refused: bad ownership or modes for file /home/git/.ssh/authorized_keys

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

Ответ 12

Недавно я столкнулся с той же проблемой и обнаружил, что для меня проблема заключалась в том, что SELinux препятствовал доступу sshd к файлу authorized_keys в каталоге данных gitlab /var/opt/gitlab/.

Чтобы исправить это, отредактируйте /etc/selinux/targeted/contexts/files/file_contexts.homedirs и добавьте строку:

/var/opt/gitlab/\.ssh/.*    system_u:object_r:ssh_home_t:s0

Затем запустите:

$ restorecon -Rv /var/opt/gitlab

Источник: https://serverfault.com/questions/50573/selinux-preventing-passwordless-ssh-login

Ответ 13

Это означает, что gitlab ssh-сервер не настроен должным образом.

Измените /etc/ssh/sshd_config и убедитесь, что:

PasswordAuthentication no
ChallengeResponseAuthentication no

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

Не спрашивайте меня, закрываетесь ли вы снаружи, ясно, что SO - это не то место, где можно спросить, как настроить и использовать пару закрытого/открытого ключа.

Ответ 14

Для тех, у кого есть эта проблема с Bitnami или любой другой конфигурацией, которая хочет быстро ее решить, просто используйте полный путь.

git clone [email protected]_adress:/full/path/to/project.git

отредактирован: Я забыл упомянуть, очень важно проверить, добавили ли вы ключи SSH на git -lab через веб-страницу.