Git Remote : 오류 : 치명적 : 프로토콜 오류 : 잘못된 줄 길이 문자 : Unab

git 서버를 설정하고 이제 클라이언트에서 처음에 내 저장소를 푸시하고 싶습니다. git push origin master이 오류 메시지를 사용 하고 나타납니다.

fatal: protocol error: bad line length character: Unab

나는 무엇이 잘못되었는지 모른다. "Unab"이 무엇인지 모르겠습니다. 셸 크기를 조정하려고했지만 여전히 "Unab"입니다. 이 오류 메시지에 대한 해결책을 찾을 수 없습니다.

"authorized_keys"와 SSH로 서버를 설정했습니다. (SSH를 사용하여 연결할 수 있습니다.)

자식 문제인 것 같습니까?

BTW : 서버가 Windows 7 VM에 설정되어 있습니다.

이 오류 메시지는 약간 둔감하지만 실제로 원격 서버가 적절한 git 응답으로 응답하지 않았다는 것을 알려줍니다. 궁극적으로 git-receive-pack프로세스를 실행하는 서버에 문제가있었습니다 .

Git 프로토콜에서 처음 4 바이트는 줄 길이 여야합니다. 대신, 그들은 문자였습니다 Unab... 아마도 일종의 오류 메시지의 시작일 것입니다. (즉, " Unable to..."일 가능성이 있습니다.)

달리면 어떻게 ssh <host> git-receive-pack <path-to-git-repository>되나요? git 클라이언트가 실행 중이라는 오류 메시지가 나타나고이를 수정할 수 있습니다.

비슷한 문제가 있었지만 정확한 오류 메시지는 다음과 같습니다.

치명적 : 프로토콜 오류 : 잘못된 줄 길이 문자 : Usin

이것은 Windows에 있으며 PuTTY GIT_SSH의 경로 로 설정됩니다 plink.exe.

가능한 문제 및 해결책 :

• 경로 plink.exe가 올바른지 확인하십시오 . 예를 들어 유닉스 스타일 경로도 잘 작동합니다./c/work/tools/PuTTY/plink.exe
• PuTTY ( pageant.exe) 의 키 에이전트 가 실행 중인지 확인
• 키 에이전트에 서버에 액세스하기위한 유효한 키가 포함되어 있는지 확인하십시오.

GitExtension 사용자의 경우 :

git을 2.19.0으로 업그레이드 한 후에도 동일한 문제가 발생했습니다.

해결책:

도구> 설정> Git 확장> SSH

[ PuTTY ] 대신 [ OpenSSH ]를 선택하십시오 .

Windows에 GIT를 설치 한 후에도 같은 종류의 문제가 발생했습니다. 처음에는 효과가있었습니다. 그런 다음 하루 후 (PC 재부팅 후) 더 이상 작동하지 않았고 다음과 같은 결과를 얻었습니다.

$ git pull
fatal: protocol error: bad line length character: git@

문제는 재부팅 후 자동으로 시작된 Putty "pageant.exe"가 더 이상 개인 키를 활성화하지 않았다는 것입니다. Pageant에 키를 추가하면 기본적으로 영구 설정이 아닙니다. 키를 다시 추가해야했는데 제대로 작동했습니다. 따라서이 경우 여기에 설명 된대로 pagenant가 키를 자동으로로드하도록해야합니다.

https://www.digitalocean.com/community/tutorials/how-to-use-pageant-to-streamline-ssh-key-authentication-with-putty

출력을 생성하는 서버의 .bashrc에 명령문이있을 수 있습니다. 예를 들어 다음과 같습니다.

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"
rvm use ruby-1.9.3-p194@rails32

이 경우 rvm 사용의 출력은 git에서 오는 것으로 (잘못) 해석됩니다. 따라서 다음으로 교체하십시오.

rvm use ruby-1.9.3-p194@rails32 > /dev/null

Git Extensions에서 SSH 개인 키를로드하면이 문제가 해결됩니다.

모든 출력을 .bashrc에서 stderr다음으로 리디렉션 할 수 있습니다 .

# inside .bashrc
echo 'some error/warning/remind message' 1>&2

자식은이 기호를 무시합니다

Git Bash를 사용하여 Windows에서 비슷한 문제가 발생했습니다. git 복제를 시도 할 때이 오류가 계속 발생했습니다. 저장소는 GitLab이 설치된 Linux 상자에있었습니다.

git clone git@servername:path/to/repo
fatal: protocol error: bad line length character: git@

ssh 키가 생성되었는지 확인했습니다. 공개 키가 GitLab에 추가되었습니다. ssh-agent가 실행 중이고 생성 된 키가 추가되었습니다 ( github link ).

옵션이 부족한 다음 마침내 Git Bash를 닫고 '관리자 권한으로 실행'을 마우스 오른쪽 버튼으로 클릭하여 다시 열었습니다. 그 후에 일했습니다.

이것은 누군가를 도울 수 있습니다. EC2 인스턴스에서 프로젝트를 복제하려고 할 때 아래 오류가 발생했습니다.

Cloning into 'repo1'...
fatal: protocol error: bad line length character: logi

나를위한 해결 방법에는 다음 단계가 포함됩니다.

1. EC2 인스턴스에서 SSH 키 (공개)가 추가 / 업데이트되었는지 확인합니다.
2. 인증 에이전트 (내 경우에는 Pageant = Putty 인증 에이전트)가 실행되고 있고 해당 개인 키가로드되었는지 확인합니다.

3. git clone의 퍼블릭 키에 EC2 SSH 키 ID를 사용하십시오. 예:

   git clone ssh : // {SSH 키 ID}@someaccount.amazonaws.com/v1/repos/repo1

나를 위해 최근에 추가했기 때문에

RequestTTY force

.ssh / config로

이것을 주석 처리하면 작동하도록 허용되었습니다.

원격 시스템에 연결하는 데 사용 된 계정의 시작 파일에서 "echo"문을 확인하십시오. Bash 셸의 경우 .bashrc 및 .bash_profile 등이 될 것입니다. Edward Thomson은 그의 대답이 정확하지만 ssh를 통해 서버에 로그인 할 때 상용구가 출력되는 특정 문제를 경험했습니다. Git은 해당 상용구의 처음 4 바이트를 가져와이 오류를 발생시킵니다. 이제이 특정 경우에 "Unab"는 실제로 Git 호스트에 다른 문제가 있음을 나타내는 "Unable ..."작업이라고 추측 할 것입니다.

제 경우에는 가져 오기 후 다음과 같이 작성 fatal: protocol error: bad line length character: Pass되었습니다.. 또한 푸시 후 : fatal: protocol error: bad line length character: git@ Done.

Windows를 재부팅 한 후 "PuTTY 에이전트"(pageant.exe)를 다시 시작하고 키 목록에서 사라진 개인 키를 추가해야했습니다.

참고로 CentOS6 컨테이너를 CentOS7로 업그레이드 한 후에도 이와 동일한 오류 메시지가 나타납니다. 컨테이너를 빌드 할 때 일부 자식 작업이 실패하기 시작했습니다.

# git remote show origin
fatal: protocol error: bad line length character: Inva

ssh를 실행하면 검색 할 수있는 오류가 발생했습니다.

# ssh git@bitbucket.org
Invalid clock_id for clock_gettime: 7

그로 인해 https://github.com/wolfcw/libfaketime/issues/63으로 이동 LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1하여 부모 Dockerfile에 있음을 잊었습니다. 주석 처리하면 오류가 수정되었습니다.

제 경우 문제는 32 비트 Putty 및 pageant.exe였습니다. 64 비트 TortoisePlink.exe와 통신 할 수 없습니다. 32 비트 Putty를 64 비트 버전으로 교체하면 문제가 해결되었습니다.

내 경우에는 사용자 이름이 "fatal: protocol error: bad line length character: shmi" 어디에 있는지 같은 오류가 발생했습니다 shmi. .NET에서 SSH를 PuTTY에서 OpenSSH로 전환했습니다 "Git Extensions->Settings->SSH". 도움이되었습니다.

나는 Christer Fernstrom과 같은 문제가있었습니다. 제 경우에는 며칠 동안 백업을 수행하지 않았을 때 백업을 수행하도록 상기시키는 .bashrc에 넣은 메시지였습니다.

다음은 누군가에게 도움이 될 수 있습니다. AWS EC2 인스턴스에있는 프로젝트를 복제하려고 할 때 다음 오류가 발생했습니다.

Cloning into 'AWSbareRepo'...
fatal: protocol error: bad line length character: Plea

이는 EC2-USER 대신 루트로 ssh를 시도했기 때문입니다. git clone을하지 않고 실제로 ssh를한다면 ... "Please login with ec2-user"라는 줄에 오류 메시지가 나타날 것입니다. 일단 ec2-user로 git clone을 수행하면 좋았습니다.

나는 또한 때때로 그 오류가 발생하지만 발생하면 내 지점이 최신 상태가 아니므로해야합니다. git pull origin <current_branch>

Git은 암호 를 요구하지 않고 개인 키 인증 설정 도 없는 경우 유사한 비밀 메시지 "치명적 : 프로토콜 오류 : 잘못된 줄 길이 문자 : 사용자"와 함께 실패 합니다.

https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server 는 서버에서 공개 키를 지정하는 방법을 알려줍니다. 기본적으로 ~ / .ssh / authorized_keys 또는 ~ / .ssh / authorized_keys2에 공개 키를 추가합니다.

Windows 컴퓨터의 Git Bash에 개인 키를 제공하는 방법에 대해 약간 고심해야했습니다. /server/194567/how-do-i-tell-git-for-windows-where-to-find-my-private-rsa-key/382801#382801 에서 Dan McClain의 답변에 대해 설명합니다. 그의 대답에 대한 추가 사항 중 하나는 내 경우 개인 키 파일의 이름이 id_rsa.pub로 예상되었습니다.

나를 위해 개인 키 (puttygen으로 변환)를 사용하여 동일한 호스트 세부 정보를 Putty에 추가했습니다. 그 이후의 모든 git bash 명령에는 문제가 없었습니다.

Putty를 사용하는 경우. 그런 다음 Pageant를 실행하고 개인 키가 Pageant에로드되었는지 확인합니다 (작업 표시 줄에서 Pageant 아이콘을 마우스 오른쪽 버튼으로 클릭하고 팝업 메뉴에서 "키보기"를 클릭).

그렇지 않으면 cmd.exe에서 할 때 :

git clone ssh://name@host:/path/to/git/repo.git

"심각한 : 프로토콜 오류 : 잘못된 줄 길이 문자 :"라는 메시지가 표시됩니다.

TL; DR은 : 할 일이 없습니다 생략 할 username@경우 Windows에서 원격의 URL에서.

기본 ssh를 사용하는 Linux 및 Windows에서는 다음과 같이 원격 URL에서 사용자 이름을 생략 할 수 있습니다.

git clone server-name:/srv/git/repo-name

ssh의 기본 동작은 현재 로그인 한 사용자 이름을 사용하는 것입니다. Windows를 사용 중이고에서 plink.exe로드 된 키 를 사용할 수 있도록 git을 사용 하도록 설정 한 경우 동일한 자동 사용자 이름 동작이 pageant없기 때문에 plink작동하지 않아 오류 메시지가 표시됩니다. 사용자 이름에 대한 프롬프트 :

$ plink server-name
login as: _

대:

$ plink username@server-name
...logs you in...

이미 저장소를 복제 한 경우 원격 URL 에을 .git/config추가하여 원격을 수정할 수 있습니다 username@.

서버에서 셸 액세스가 허용되는지 확인합니다.

변형 된 오류 : 치명적 : 프로토콜 오류 : 잘못된 줄 길이 문자 : fata

git-upload-pack의 위치를 ​​시스템 경로에 추가 한 후.

문제는 저장소 이름 주위에 아포스트로피가 추가 된 것 같습니다. git 클라이언트에 의해 추가 된 Process Monitor (sys 내부에서 제공)와 같은 도구를 사용하는 것 같습니다. 자식 특정 창 문제인 것 같습니다.

서버 프롬프트에서 동일한 명령 줄을 시도했습니다. 전체 오류는 "치명적 : 지정된 저장소 (또는 상위 디렉토리)가 아님 : .git"였습니다.

결론적으로, 그것은 소프트웨어 버그처럼 보입니다. 내가 git 전문가가 아니라는 점을 알려드립니다. git을 처음 사용하고 subversion 및 perforce에서 왔습니다.

우리는 이것도 만났습니다.

Counting objects: 85, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (38/38), done.
Writing objects: 100% (38/38), 3.38 KiB | 0 bytes/s, done.
Total 38 (delta 33), reused 0 (delta 0)
Auto packing the repository for optimum performance.
fatal: protocol error: bad line length character: Remo
error: error in sideband demultiplexer

무엇이 잘못되었는지에 대한 자세한 내용은 모르지만, 우리의 경우에는 서버의 디스크가 꽉 찼다는 것이 원인이었습니다.

컴퓨터의 보안 액세스 일 수 있습니다. Pageant (퍼티 에이전트)를 실행하고 있습니까?

언제든지 git 프로젝트에 대한 http 링크를 가질 수 있습니다. ssh 링크 대신 사용할 수 있습니다. 이것은 당신이 가진 옵션입니다

글쎄, 나는 이와 같은 문제가 있었다 (Windows 7). 암호로 repo를 얻으십시오. 나는 Git Bash + Plink (환경 변수 GIT_SSH) + Pageant를 사용합니다. GIT_SSH (임시)를 삭제하면 도움이됩니다. 패스로 로그인과 RSA로 로그인을 동시에 사용할 수없는 이유를 모르겠습니다.

여기에 늦은 답변이 있지만 누군가에게 도움이되기를 바랍니다. 프로토콜 오류 인 경우 원격 git과 통신 할 수없는 로컬 git과 무언가를해야합니다. 이는 ssh를 통해 리포지토리를 복제하고 나중에 리포지토리의 키를 잃어 버리거나 ssh 에이전트가 더 이상 해당 키를 찾을 수없는 경우에 발생할 수 있습니다.

해결책

1. 새 키를 생성하고 git repo에 추가하거나 다른 사람이 아닌 다른 사람과 함께 키를 가지고있는 경우 키를로드하도록 ssh 에이전트를 구성하십시오.)

2. 또 다른 빠른 수정은 .git디렉토리 로 이동 하여 config파일의 [remote "origin"] urlfrom gitto를 편집하여 http푸시하는 데 ssh 키가 필요하지 않고 사용자 이름과 암호를 묻는 것으로 되돌아가는 것입니다.

   [remote "origin"]
   url = git@gitlab.*****.com:****/****.git
   fetch = +refs/heads/*:refs/remotes/origin/*
   

로 변경

    [remote "origin"]
    url = http://gitlab.*****.com/****/****.git
    fetch = +refs/heads/*:refs/remotes/origin/*

설정 / 버전 제어 / git에서 ssh exectuable을 내장에서 nativ로 변경하면 트릭이 생겼습니다.