Блог

Главная - Вопросы по программированию - GIT: фатальная: ошибка протокола: неверная длина строки символ: Это

GIT: фатальная: ошибка протокола: неверная длина строки символ: Это

#git #ssh #gitlab

# #git #ssh #gitlab

Вопрос:

При попытке клонирования с использованием SSH URL мы получаем следующую ошибку:

 $ git clone git@host:repository.git
Cloning into 'test'...
fatal: protocol error: bad line length character: This

Мы используем GitLab локально и используем SSH URL для клонирования репозиториев. Вчера все пользователи и Дженкинс сообщили о проблемах с клонированием, извлечением и отправкой кода в репозитории. Вскоре мы выяснили, что протокол HTTPS работает должным образом, и эта проблема была ограничена для всех, использующих SSH URL.

Вот некоторые вещи, которые мы пытались получить более подробно, но безрезультатно, за исключением того, что мы видим, что после авторизации происходит сбой со статусом выхода 254 или 1 случайным образом:

 GIT_SSH_COMMAND='ssh -v' git clone git@host:repository.git

GIT_SSH_COMMAND='ssh -v' git clone git@host:repository.git

Фрагмент вывода из приведенных выше команд

 debug1: Authentication succeeded (publickey).
Authenticated to host ([a.y.x.b]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: PTY allocation disabled.
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: PTY allocation disabled.
debug1: Sending environment.
debug1: Sending env GIT_PROTOCOL = version=2
debug1: Sending command: git-upload-pack 'repository.git'
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
fatal: protocol error: bad line length character: This
Transferred: sent 2352, received 2984 bytes, in 0.1 seconds
Bytes per second: sent 22560.7, received 28622.9
debug1: Exit status 1

Комментарии:

1. Попробуйте запустить ssh git@host 'echo hello' и посмотреть, печатает ли он что-нибудь, кроме «привет».

2. В качестве шага отладки: запуск простого ssh git@host файла также может помочь выявить некоторые проблемы.

Ответ №1:

Проверьте, какие поддерживаемые оболочки

 cat /etc/shells

В нашем случае у пользователя git была отключена оболочка, и на изображении ниже отображался /sbin/ nologin

остановлен экземпляр gitlab

 gitlab-ctl stop

Обновить оболочку для пользователя git (вы можете использовать любую из приведенных ниже команд)

 usermod -s which git-shell git
usermod -s /bin/sh git

Перенастроить GitLab

 gitlab-ctl reconfigured

Перезапустите службу GitLab

 gitlab-ctl restart

Наконец, проверьте, что /sbin/ nologin изменился на /bin/sh для пользователя git, как показано на рисунке ниже

 vi /etc/passwd | grep git

введите описание изображения здесь

Комментарии:

1. /bin/sh возможно, это не та оболочка, которую вы хотели бы использовать здесь. Смотрите git-scm.com/docs/git-shell

2. Мы выполнили следующую команду, и мне сказали, «какой git-shell» сопоставляется с /bin/sh: usermod -s, который git-shell git

3. С вашей настройкой любой, у кого есть git@host доступ, теперь может запускать любую команду от имени пользователя git . Например, ssh git@host echo test будет печатать test . Это может быть нормально, в зависимости от того, насколько вы доверяете своим пользователям. Вот почему я сказал, что этого не может быть . Это просто примечание.

Метки: