Подтвердить что ты не робот

GitLab git пароль пользователя

Я только что установил GitLab.

Я создал проект под названием project-x.

Я создал несколько пользователей и назначил их проекту.

Теперь я попытался клонировать:

 git clone [email protected]:project-x.git

Он подсказал мне пароль.

Какой пароль использовать?

4b9b3361

Ответ 1

Он подсказал мне пароль.

Это не должно быть. Если у вас есть правильный общедоступный/закрытый ключ, представляющий пользователя, которому разрешен доступ к project-x, тогда gitlab ничего не потребует.

Но это предполагает, что ssh -vT [email protected] работает первым.

Ответ 2

Не строго связано с текущим сценарием. Иногда, когда вас просят ввести пароль, это происходит потому, что вы добавили неправильный * исходный формат (HTTPS вместо SSH)

Протокол HTTP (S) обычно используется для публичных репозиториев со строгим именем пользователя + pass
SSH аутентификация чаще встречается для внутренних проектов, где вы можете аутентифицироваться с помощью ssh-key-file и простой парольной фразы
Пользователи GitLab чаще используют протокол SSH protocol

Просматривайте удаленную информацию с помощью

git remote -v

Если вы видите адрес HTTP (S), это команда, чтобы изменить его на SSH:

git remote set-url origin [email protected]_domain.com/example-project.git

Ответ 3

Решение от https://github.com/gitlabhq/gitlab-shell/issues/46 работало для меня.

Установив разрешения:

chmod 700 /home/git/.ssh
chmod 600 /home/git/.ssh/authorized_keys

пароль исчезает.

Ответ 4

У меня была такая же проблема при использовании ключа из 4096 бит:

$ssh-keygen -t rsa -C "GitLab" -b 4096
$ ssh -vT git @gitlabhost
...
debug1: Предоставление открытого ключа:/home/user/.ssh/id_rsa
debug1: аутентификация, которая может продолжаться: публикация, пароль
debug1: использование секретного ключа:/home/user/.ssh/id_dsa
debug1: поиск секретного ключа:/home/user/.ssh/id_ecdsa
debug1: Следующий способ аутентификации: пароль
git @gitlabhost пароль:
Соединение закрыто хостом

Но с ключом 2048 бит (размер по умолчанию) ssh подключается к gitlab без запроса пароля (после добавления нового ключа pub к ключам пользователя gitlab ssh)

$ssh-keygen -t rsa -C "GitLab"
$ ssh -vT git @gitlabhost
Добро пожаловать в GitLab, Joe User!

Ответ 5

Это может произойти, если в имени хоста есть "-". (Даже если это является законным в соответствии с RFC 952.) (Протестировано с использованием Git Bash под Windows 10 с использованием git 2.13.2.)

ssh запрашивает у меня пароль для любого хоста, в имени которого есть "-". Казалось бы, это просто проблема с разбором файла конфигурации ssh, потому что добавление псевдонима в ~/.ssh/config (и использование этого псевдонима в моих удаленных URL-адресах git) решило проблему.

Другими словами, попробуйте добавить что-то вроде следующего в ваш C: /Users/{username}/. Ssh/config

Host {a}
    User git
    Hostname {a-b.domain}
    IdentityFile C:/Users/{username}/.ssh/id_rsa

и где у вас есть пульт в форме

origin  [email protected]:repo-name.git

измените URL, чтобы использовать следующую форму

git remote set-url origin [email protected]:repo-name.git

Ответ 6

Чтобы добавить еще одну причину в список... в моем случае я обнаружил, что эта проблема вызвана проблемой разрешений SELinux на сервере. Это стоит проверить, работает ли на вашем сервере Fedora/CentOS/Red Hat. Чтобы проверить этот сценарий, вы можете запустить:

Клиент: ssh -vT [email protected]<gitlab-server> - запрашивает пароль
Сервер: sudo setenforce 0
Клиент: ssh -vT [email protected]<gitlab-server> - успешно
Сервер: sudo setenforce 1

В моем случае файл authorized_keys пользователя gitlab/git имел неверный контекст файла SELinux, и службе ssh было отказано в разрешении на его чтение. Я исправил это на стороне сервера следующим образом:

sudo semanage fcontext -a -t ssh_home_t /gitlab/.ssh/
sudo semanage fcontext -a -t ssh_home_t /gitlab/.ssh/authorized_keys
sudo restorecon -F -Rv /gitlab/.ssh/

И тогда я смог сделать git clone на стороне клиента, как и ожидалось.

Ответ 7

У меня был правильный общедоступный/закрытый ключ, но, похоже, он все равно не работал (появились те же ошибки, что и запрос пароля git -user). После перезагрузки компьютера он работал, хотя!

Ответ 8

Это же решение для Windows-машины:

  • Сгенерировать ключ SSH и добавить ключ к серверу Git lab
  • Убедитесь, что 2 файла ключа SSH находятся в папке /.ssh(например, C:\Users\xxx.ssh)

Клон должен быть успешным без необходимости пароля.

Ответ 9

В моем случае я использовал пару ключей, у которых не было имен по умолчанию id_rsa и id_rsa.pub.

Создание ключей с этими именами решило проблему, и я действительно нашел ее, глядя на вывод ssh -vT my_gitlab_address. Странный факт: он работал на одном компьютере с Ubuntu, но не на других с разными дистрибутивами и более старыми версиями OpenSSH.

Ответ 10

Я использую mac.gitlab, установленный на сервере centos.

Я пробовал все вышеперечисленные методы и нашел для меня окончательный ответ:

не так:

ssh-keygen -t rsa

право:

 ssh-keygen -t rsa -C "[email protected]" -b 4096

Ответ 11

В Windows 10 с использованием терминала под VS Code я получил запрос "git @gitlab password:" при попытке:

git push -u origin --all

Я установил свои учетные данные ssh в windows и gitlab, но для этого использовал Windows 10 bash key-gen. Тогда решение состояло в том, чтобы вызвать bash в терминале кода VS и затем снова ввести команду.

bash
git push -u origin --all

Это удалось.

Чтобы избежать необходимости использовать bash/git вручную, я помещаю символическую ссылку между окнами .ssh/id_rsa и оболочкой bash.ssh/id_rsa:

C:\Users\bruce\.ssh>mklink id_rsa C:\Users\bruce\AppData\Local\lxss\home\bruce\.ssh\id_rsa

Действия с VS Code Git (push, pull и т.д.) Теперь работают с gitlab

Ответ 12

Моя проблема заключалась в том, что у меня была запись DNS для gitlab.example.com указывающая на мой балансировщик нагрузки. Поэтому, когда я пытался сделать ssh [email protected] я действительно пытался использовать не ту машину.

Я сделал запись в моем файле ~/.ssh/config:

Host gitlab.example.com
    Hostname 192.168.1.50

Это потратило много времени...

Ответ 13

У меня была та же проблема, Я потратил много времени на поиск!

У меня возникла идея использовать Eclipse для импорта проекта из GitLab.

Как только проект импортирован правильно, я сделал сравнение между конфигурацией:

  • проект Git ripository, который я импортировал в Eclispe ( "в Eclipse", Git Repository, в myprojectRepo/Working Directory/.git/config)
  • тот, который сделан в .git/config, там я хотел нажать мой проект с помощью git: Git push... и попросил у меня пароль.

Сюрприз: в обоих случаях пульт не имеет одинакового значения. Я передал то же самое, что и в затмении, и все работает.

Ответ 14

Имела ту же проблему в Windows 10 (не знаю, насколько это актуально). Если бы все было правильно настроено, команда ssh -vT [email protected] преуспела, но Gitlab все еще запрашивал мой пароль.

Удаление тогда повторного создания ключа в Gitlab стало для меня трюком.

Ответ 15

На моем компьютере с Windows 10 это произошло потому, что переменная среды SSH_GIT не была настроена на использование заливки, установленной мной на моей машине.

Ответ 16

Обычно, если у вас есть несколько ключей, установленных через ssh в вашей системе (на моем устройстве работает Windows 10), вы столкнулись с этой проблемой, исправление:

Предварительное условие: настройте свои SSH-ключи, как показано GitLab

  • открыть файл /c/Users//.ssh/config с помощью Notepad ++ или вашего любимого редактора
  • вставьте в него следующее. Хост  IdentityFile ~/.ssh/

Обратите внимание: перед второй строкой есть пробел, очень важно, чтобы это решение не работало.

Ответ 17

если вы уверены, что вы загрузили содержимое key.pub в GitLab, то: 1- Откройте Git Bash "Не CMD" 2- Перейдите в папку решений "Путь к CD" 3- Тип Git Init 4- Тип Git Add. 4- Тип Git Commit 6- Тип Git Push

и это будет работать.. еще один совет: убедитесь, что путь к файлу, в который вы скопировали ключ, является правильным и эквивалентным пути, указанному в CMD при создании ключей

Ответ 18

После добавления нового ключа SSH в GitLab проверьте, включена ли в SSHD группа "git" AllowGroups (для Debian /etc/ssh/sshd_config). Если нет, добавьте его и перезапустите sshd (systemctl restart ssh).

Проверьте это с ssh -vT [email protected], как предложено выше.