Git 원격:오류: 치명적: 프로토콜 오류: 잘못된 줄 길이 문자: Unab
Git 서버를 설정하고 처음에 클라이언트에서 내 repo를 푸시하려고 합니다.저는 용한사를 요.git push origin master다음 오류 메시지가 표시됩니다.
fatal: protocol error: bad line length character: Unab
난 뭐가 문제인지 모른다."UNAB"가 뭔지 모르겠어요셸의 크기를 조정하려고 했지만 여전히 "Unab" 상태입니다.이 오류 메시지에 대한 해결 방법을 찾을 수 없습니다.
"authorized_keys"와 SSH로 서버를 설정했습니다. (SSH를 사용하여 연결할 수 있습니다.)
기트 문제인 것 같아요?
BTW: 서버가 윈도우즈 7 VM에 설정되어 있습니다.
이 오류 메시지는 다소 둔탁하지만 실제로 원격 서버가 적절한 Git 응답으로 응답하지 않았다는 것을 알려주려고 합니다.에서 궁으로, 적문있니다었습제가서에극버를 실행하는 데 문제가 .git-receive-pack과정.
Git 프로토콜에서 처음 4바이트는 줄 길이여야 합니다.대신, 그들은 등장인물들이었습니다.Unab아마도 어떤 종류의 오류 메시지의 시작일 것입니다.(즉, "일 것입니다.Unable to...을 합니다).
을 실행할 때 ssh <host> git-receive-pack <path-to-git-repository>Git 클라이언트가 오류 메시지를 표시해야 하며 이를 수정할 수도 있습니다.
비슷한 문제가 있었지만 정확한 오류 메시지는 다음과 같습니다.
치명적: 프로토콜 오류: 잘못된 줄 길이 문자: Usin
은 Windows에 버전입니다.GIT_SSH…의 plink.exeTTY 의.
발생 가능한 문제 및 해결 방법:
- 경로를 확인하십시오.
plink.exe예를 들어, 스타일 경로도잘 합니다./c/work/tools/PuTTY/plink.exe - PuTTY)의 키 합니다.
pageant.exe) 실행중 - 키 에이전트에 서버에 액세스할 수 있는 유효한 키가 포함되어 있는지 확인합니다.
GitExtension 사용자의 경우:
git를 2.19.0으로 업그레이드한 후에도 동일한 문제에 직면했습니다.
솔루션:
도구 > 설정 > Git Extensions > SSH
[열기] 선택[PuTTY] 대신 SSH]
윈도우에 GIT를 설치한 후에도 같은 종류의 문제가 있었습니다.처음에는 작동했지만, 하루 후(PC 재부팅 후) 더 이상 작동하지 않았고, 저는 다음과 같은 결과를 얻었습니다.
$ git pull
fatal: protocol error: bad line length character: git@
문제는 재부팅 후 자동으로 시작된 Putty "pageant.exe"가 더 이상 개인 키를 활성화하지 않는다는 것입니다.미인대회에서 키를 추가하면 기본적으로 키가 영구 설정이 아닙니다.그냥 키를 다시 추가해야 했고, 잘 작동했습니다.따라서 이 경우에는 다음과 같이 페이지 에이전트가 키를 자동으로 로드하도록 해야 합니다.
서버의 .bashrc에 출력을 생성하는 문이 있을 수 있습니다.예를 들어, 나는 다음과 같이 했습니다.
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"
rvm use ruby-1.9.3-p194@rails32
이 경우 rvm use의 출력은 git에서 나온 것으로 (잘못된) 해석됩니다.따라서 다음으로 대체:
rvm use ruby-1.9.3-p194@rails32 > /dev/null
GitExtensions에서 SSH 개인 키를 로드한 후 이 문제가 해결됩니다.
에서 수 ..bashrcstderr:
# inside .bashrc
echo 'some error/warning/remind message' 1>&2
git는 이 기호를 무시할 것입니다.
Windows에서 Git Bash를 사용할 때도 비슷한 문제가 있었습니다.git clone을 하려고 할 때 계속 이 오류가 발생했습니다.저장소가 GitLab이 설치된 Linux 상자에 있었습니다.
git clone git@servername:path/to/repo
fatal: protocol error: bad line length character: git@
ssh 키가 생성되었는지 확인했습니다.GitLab에 공개 키가 추가되었습니다.ssh-agent가 실행 중이고 생성된 키가 추가되었습니다(github 링크).
옵션이 부족하여 Git Bash를 닫고 '관리자 권한으로 실행'을 마우스 오른쪽 버튼으로 클릭하여 다시 엽니다.그 후에 일했습니다.
저에게 있어서는 최근에 추가했기 때문입니다.
RequestTTY force
.vmx/config로
이것을 논평하는 것은 그것이 작동할 수 있게 했습니다.
누군가에게 도움이 될 수도 있습니다.EC2 인스턴스에서 프로젝트를 복제하려고 할 때 다음 오류가 발생했습니다.
Cloning into 'repo1'...
fatal: protocol error: bad line length character: logi
저를 위한 결의안은 다음 단계를 포함합니다.
- SSH 키(공개)가 EC2 인스턴스에 추가/업데이트되었는지 확인합니다.
- 인증 에이전트 확인(나의 경우 Festa=)Putty Authentication Agent)가 실행되고 해당 개인 키가 로드됩니다.
git clone의 공용 키에 EC2 SSH 키 ID를 사용합니다.예:
git clone ssh://{SSH Key ID}@someaccount.amazonaws.com/v1/repos/repo1
적었습니다.fatal: protocol error: bad line length character: Pass또한 푸시 후에 다음과 같은 메시지가 표시됩니다.fatal: protocol error: bad line length character: git@ Done.
Windows를 재부팅한 후 "Pu"를 시작해야 했습니다.TTY 에이전트"(pagant.exe)를 다시 입력하고 키 목록에서 사라진 개인 키를 추가합니다.
푸티를 사용한다면요.그런 다음 Festa가 실행되고 개인 키가 Festa에 로드되는지 확인합니다(작업 표시줄에서 Festa 아이콘을 마우스 오른쪽 단추로 클릭하고 팝업되는 메뉴에서 "View key"를 클릭합니다).
그렇지 않은 경우 cmd 단위로 실행합니다.exe:
git clone ssh://name@host:/path/to/git/repo.git
다음 메시지가 표시됩니다. "filename: protocol error: bad line length character:"
원격 컴퓨터에 연결하는 데 사용되는 계정의 시작 파일에서 "echo" 문을 확인합니다.Bash 셸의 경우 .bashrc 및 .bash_profile 등이 됩니다.Edward Thomson의 답변은 옳지만, 제가 경험한 구체적인 문제는 ssh를 통해 서버에 로그인할 때 보일러 플레이트 인쇄가 발생하는 경우입니다.Git는 보일러 플레이트의 처음 4바이트를 얻고 이 오류를 발생시킬 것입니다.이 구체적인 사례에서 저는 "Unab"이 실제로 "Unable"이라는 작품이라고 추측할 것입니다.아마도 Git 호스트에 뭔가 다른 문제가 있다는 것을 의미할 것입니다.
TL;DR: 생략 안 함username@원격 URL에 저장할 수 있습니다.
기본 ssh가 있는 Linux 및 윈도우즈에서는 다음과 같이 원격 URL에서 사용자 이름을 생략할 수 있습니다.
git clone server-name:/srv/git/repo-name
SSH의 기본 동작은 현재 로그인한 사용자 이름을 사용하는 것이기 때문입니다.Windows를한 경우 (윈도우)를 사용합니다.plink.exe이 신이당신로키사수있록도에 할 수 .pageant그러면 이것은 작동하지 않을 것입니다, 왜냐하면plink이와 동일한 자동 사용자 이름 동작이 없으므로 사용자 이름을 묻는 메시지가 표시되므로 암호화된 오류 메시지는 다음과 같습니다.
$ plink server-name
login as: _
비교:
$ plink username@server-name
...logs you in...
이미 리포지토리를 복제한 경우에는 원격을 수정할 수 있습니다..git/config를 username@URL로 합니다. URL로 이동합니다.
저도 가끔 그런 오류를 겪지만, 그럴 때는 제 지점이 최신이 아니라는 뜻이어서 해야 합니다.git pull origin <current_branch>
참고로, 센트를 업그레이드한 후에도 동일한 오류 메시지가 표시됩니다.OS6 컨테이너에서 CentOS7로 -- 컨테이너를 구축할 때 일부 git 작업이 실패하기 시작했습니다.
# 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상위 Docker 파일에 있습니다.그것을 논평하는 것이 오류를 해결했습니다.
저의 경우 문제는 32비트 Putty 및 pagenta.exe였습니다. 이는 64비트 TorothyPlink.exe와 통신할 수 없습니다.32비트 Putty를 64비트 버전으로 교체하면 문제가 해결되었습니다.
저도 같은 오류가 있었습니다."fatal: protocol error: bad line length character: shmi" 곳shmi사용자 이름입니다.SSH를 PuTTY에서 Open으로 전환했습니다.의 »"Git Extensions->Settings->SSH"도움이 되었습니다.
저도 Christer Fernstrom과 같은 문제가 있었습니다.저의 경우 며칠 동안 백업을 하지 않았을 때 백업을 수행하라는 메시지를 .bashrc에 입력했습니다.
다음은 누군가에게 도움이 될 수 있습니다.AWS EC2 인스턴스에 있는 프로젝트를 복제하려고 할 때 다음 오류가 발생했습니다.
Cloning into 'AWSbareRepo'...
fatal: protocol error: bad line length character: Plea
이 문제는 EC2-USER 대신 root로 ssh를 시도하여 발생했습니다. git clone을 수행하지 않고 실제로 ssh를 수행하면..."Please login with ec2-user" 라인을 따라 오류 메시지가 표시됩니다. 일단 ec2-user로 git clone을 실행하면 좋았습니다.
개인 키 인증 설정이 없는 경우 Git는 암호를 묻지 않고 유사한 암호 메시지 "fatal: protocol error: bad line length character: user"로 실패합니다.
https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server 은 서버에서 공개 키를 지정하는 방법을 알려줍니다.기본적으로 공개 키를 ~/.ssh/authorized_keys 또는 ~/.ssh/authorized_keys2에 추가합니다.
저는 윈도우 머신에서 깃배시에 개인 키를 제공하는 방법에 대해 약간 고심해야 했습니다.댄 매클레인의 https://serverfault.com/questions/194567/how-do-i-tell-git-for-windows-where-to-find-my-private-rsa-key/382801#382801 답변은 이를 설명합니다.그의 답변에 추가된 한 가지, 나의 경우 개인 키 파일의 이름은 id_rsa.pub입니다.
개인 키(puttygen으로 변환)를 사용하여 동일한 호스트 세부 정보를 Putty에 추가했습니다.그 이후의 모든 gitbash 명령은 문제가 없었습니다.
비슷한 문제가 있었지만 치명적이었습니다: 프로토콜 오류: 잘못된 줄 길이 문자: 캔과 나는 내가 모든 것을 제거할 때까지 그것을 제거할 수 없었습니다.plink.exe종속성(푸티를 설치했습니다.chocoinstaller했습니다..gitconfig 파일sshCommand = plink -batch.
서버에서 셸 액세스가 허용되는지 확인합니다.
오류 변환 위치: fatal: protocol error: 잘못된 줄 길이 문자: fata
시스템 경로에 git-syslog-pack의 위치를 추가한 후.
문제는 리포지토리 이름 주위에 추가된 아포스트로피입니다.Git 클라이언트가 추가한 프로세스 모니터(시스템 내부에서 제공)와 같은 도구를 사용합니다.그것은 약간 특정한 창 문제인 것 같습니다.
서버의 프롬프트에서 동일한 명령줄을 사용해 보았습니다. 전체 오류는 "치명적: 지정된 리포지토리(또는 상위 디렉토리)가 아님: .git"입니다.
결론적으로, 제가 보기에 그것은 소프트웨어 버그로 보입니다.저는 깃 전문가가 아닙니다. 깃을 사용하는 것은 처음입니다. 저는 전복과 퍼포스에서 왔습니다.
우리도 이것에 부딪혔습니다.
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
무엇이 잘못되었는지에 대한 자세한 내용은 알 수 없지만, 우리의 경우 서버의 디스크가 가득 찼다는 것이 계기가 되었습니다.
컴퓨터에 보안 액세스가 있을 수 있습니다. 미인대회(퍼티 에이전트)를 실행하고 있습니까?
당신은 항상 당신의 git 프로젝트에 http 링크를 가질 수 있습니다.당신은 ssh 링크 대신 그것을 사용할 수 있습니다.이것은 단지 당신이 가지고 있는 옵션입니다.
저도 같은 문제가 있었습니다(Windows 7).암호로 repo를 가져오십시오.Git Bash + Plink (환경변수 GIT_SSH) + Festa 를 사용합니다.GIT_SSH(임시)를 삭제하면 도움이 됩니다.로그인 바이패스와 RSA 로그인을 동시에 사용할 수 없는 이유를 모르겠습니다...
답이 늦었지만, 누군가에게 도움이 되기를 바랍니다.프로토콜 오류인 경우 로컬 깃이 원격 깃과 통신할 수 없는 것과 관련이 있습니다.이 문제는 ssh를 통해 리포를 복제한 후 나중에 리포에 대한 키를 분실했거나 ssh 에이전트가 더 이상 이러한 키를 찾을 수 없는 경우에 발생할 수 있습니다.
해결책
새 키를 생성하여 Git 보고서를 추가하거나 키가 다른 사용자와 함께 있지 않은 경우 키를 로드하도록 SSH 에이전트를 구성합니다. ;)
또 다른 빠른 해결책은 다음 사이트로 이동하는 것입니다.
.git을 합니다.config[remote "origin"] urlgithttp데를 묻는 ."라는 메시지가 표시됩니다.[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/*
언급URL : https://stackoverflow.com/questions/8170436/git-remote-error-fatal-protocol-error-bad-line-length-character-unab
'programing' 카테고리의 다른 글
| 문자열에서 HTML 태그 제거 (0) | 2023.08.24 |
|---|---|
| 하나의 열이 보기에 다른 데이터 정렬로 끝납니다. (0) | 2023.08.24 |
| Android에서 읽기 전용 파일 시스템 (0) | 2023.08.24 |
| jQuery: $().click(fn) 대 $().bind('click',fn); (0) | 2023.08.24 |
| git branch -d는 경고를 줍니다. (0) | 2023.08.19 |