Git Remote: Hata: ölümcül: protokol hatası: hatalı satır uzunluğu karakteri: Unab

Bir git sunucusu kuruyorum ve şimdi ilk olarak depomu istemciden göndermek istiyorum. git push origin masterBu hata mesajını kullandım ve aldım:

fatal: protocol error: bad line length character: Unab

Neyin yanlış olduğunu bilmiyorum. "Unab" ın ne olduğunu bilmiyorum. Kabuğu yeniden boyutlandırmaya çalıştım ama hala "Unab". Bu hata mesajı için bir çözüm bulamıyorum.

Sunucuyu "yetkili_keys" ve SSH ile kurdum. (SSH kullanarak ona bağlanabilirim.)

Git sorunu gibi görünüyor?

BTW: Sunucu bir Windows 7 VM'de kuruldu

Bu hata mesajı biraz abartılı ama aslında size anlatmaya çalıştığı şey, uzak sunucunun düzgün bir git yanıtı vermediği. Sonuçta, git-receive-packişlemi çalıştıran sunucuda bir sorun vardı .

Git protokolünde, ilk dört bayt satır uzunluğu olmalıdır. Bunun yerine, onlar karakterdi Unab... ki bu muhtemelen bir tür hata mesajının başlangıcıdır. (yani, muhtemelen " Unable to..." bir şeyler yapmaktır).

Koşarsan ne olur ssh <host> git-receive-pack <path-to-git-repository>? Git istemcinizin açık bıraktığı hata mesajını görmelisiniz ve bunu düzeltebilirsiniz.

Benzer bir sorun yaşadım, ancak tam hata mesajı şuydu:

ölümcül: protokol hatası: hatalı satır uzunluğu karakter: Usin

Bu, Windows'ta, PuTTY'nin GIT_SSHyoluna ayarlanmış plink.exe.

Olası sorunlar ve çözümleri:

• Giden yolun plink.exedoğru olduğundan emin olun . Unix tarzı yol da iyi çalışıyor, örneğin/c/work/tools/PuTTY/plink.exe
• PuTTY ( pageant.exe) anahtar aracısının çalıştığından emin olun
• Anahtar aracının, sunucuya erişmek için geçerli bir anahtar içerdiğinden emin olun

GitExtension kullanıcıları için:

Git'i 2.19.0'a yükselttikten sonra aynı sorunla karşılaştım

Çözüm:

Araçlar> Ayarlar> Git Uzantıları> SSH

[ PuTTY ] yerine [ OpenSSH ] seçin

Windows'a GIT'yi yükledikten sonra da aynı tür bir sorunu yaşadım. İlk başta işe yaradı; sonra, bir gün sonra (bilgisayar yeniden başlatıldıktan sonra) artık olmadı ve şunu anladım:

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

Sorun, yeniden başlatmanın ardından, otomatik olarak başlatılan Putty "pageant.exe" özel anahtarının artık etkin olmamasıydı. Yarışmada bir anahtar eklediğinizde, bu varsayılan olarak kalıcı bir ayar değildir. Anahtarı tekrar eklemek zorunda kaldım ve iyi çalıştı. Bu nedenle, bu durumda, burada tartışıldığı gibi pagenant'ın anahtarı otomatik olarak yüklemesini sağlamak gerekir:

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

Belki sunucunun .bashrc dosyasında çıktı üreten bir deyiminiz vardır. Örneğin şuna sahiptim:

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

Bu durumda, rvm kullanımının çıktısı (yanlış) git'ten geliyormuş gibi yorumlanacaktır. Öyleyse şununla değiştirin:

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

Git Extensions'ta SSH özel anahtarını yükledikten sonra bu sorun çözülür.

Sen gelen herhangi bir çıktı yönlendirebilirsiniz .bashrciçin stderr:

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

git bu sembolleri yok sayacak

Windows'ta Git Bash kullanarak benzer bir sorun yaşadım. Git klonu yapmaya çalışırken bu hatayı almaya devam ettim. Depo, GitLab yüklü bir Linux kutusundaydı.

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

Ssh anahtarının oluşturulduğundan emin oldum. Genel anahtar GitLab'a eklendi. Ssh aracısı çalışıyordu ve üretilen anahtar eklendi ( github bağlantısı ).

Seçeneklerim kalmadı ve sonunda Git Bash'i kapatmayı ve 'Yönetici Olarak Çalıştır'ı sağ tıklayarak tekrar açmayı denedim. Bundan sonra çalıştı.

Benim için kısa süre önce eklediğim için

RequestTTY force

.ssh / config içine

bunu yorumlamak işe yaradı

Bu birine yardımcı olabilir. Bir EC2 bulut sunucusundan bir projeyi klonlamaya çalışırken aşağıdaki hatayı alıyordum:

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

Benim için çözüm aşağıdaki adımları içerir:

1. EC2 bulut sunucusunda SSH anahtarının (genel) eklendiğinden / güncellendiğinden emin olun.
2. Kimlik doğrulama aracısının (benim durumumda onun Pageant = Putty Kimlik Doğrulama Aracısı) çalıştığından ve ilgili özel anahtarın yüklendiğinden emin olun.

3. Git klonu için genel anahtar için EC2 SSH anahtar kimliğini kullanın. Misal:

   git clone ssh: // {SSH Anahtar Kimliği}@someaccount.amazonaws.com/v1/repos/repo1

"Echo" ifadeleri için uzak makineye bağlanmak için kullanılan hesaptaki başlangıç ​​dosyalarınızı kontrol edin. Bash kabuğu için bunlar sizin .bashrc ve .bash_profile dosyanız vb. Olacaktır. Edward Thomson cevabında doğrudur, ancak yaşadığım özel bir sorun, ssh aracılığıyla bir sunucuya giriş yapıldığında bir kazan plakası çıktısı olmasıydı. Git o kazan plakasının ilk dört baytını alacak ve bu hatayı artıracaktır. Şimdi bu özel durumda, "Unab" ın aslında "Unable ..." çalışması olduğunu tahmin edeceğim ki bu muhtemelen Git ana bilgisayarında başka bir sorun olduğunu gösterir.

Benim durumumda sonra yazılmıştır getirme: fatal: protocol error: bad line length character: Pass. Ayrıca itmeden sonra aldım:fatal: protocol error: bad line length character: git@ Done .

Windows'u yeniden başlattıktan sonra, "PuTTY aracısını" (pageant.exe) yeniden başlatmam ve anahtar listesinden kaybolan özel bir anahtar eklemem gerekiyordu.

Bilginize Bir CentOS6 konteynerini CentOS7'ye yükselttikten sonra aynı hata mesajını aldım - bazı git işlemleri konteyneri oluştururken başarısız olmaya başladı, örn.

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

Ssh çalıştırmak bana arayabileceğim bir hata verdi:

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

Bu beni https://github.com/wolfcw/libfaketime/issues/63 adresine götürdü ve burada LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1bir ana Dockerfile dosyam olduğunu unuttuğumu fark ettim . Bunu yorumlamak hatayı düzeltti.

Benim durumumda sorun 32-bit Putty ve pageant.exe idi - 64-bit TortoisePlink.exe ile iletişim kuramıyor. 32-bit Putty'yi 64-bit sürümle değiştirmek sorunu çözdü.

Benim durumumda kullanıcı adı "fatal: protocol error: bad line length character: shmi" nerede ise aynı hatayı shmialdım. SSH'yi PuTTY'den OpenSSH'ye içinde değiştirdim "Git Extensions->Settings->SSH". Yardımcı oldu.

Christer Fernstrom ile aynı sorunu yaşadım. Benim durumumda, .bashrc dosyama koyduğum ve birkaç gün içinde yedekleme yapmadığım halde bir yedekleme yapmayı hatırlatan bir mesajdı.

Aşağıdakiler birine yardımcı olabilir: AWS EC2 bulut sunucumda sahip olduğum bir projeyi klonlamaya çalışırken aşağıdaki hatayı alıyordum:

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

Bunun nedeni, EC2-USER yerine kök olarak ssh'ı denemekti. git klonu yapmadan gerçekten ssh yapıyorsanız ... "Lütfen ec2-user ile giriş yapın" satırlarında bir şeyde msg hatası göreceksiniz. Bir ec2 kullanıcısı olarak git klonu yaptıktan sonra iyi oldu.

Ben de arada bir bu hatayla karşılaşıyorum ama ortaya çıktığında şubemin güncel olmadığı anlamına geliyor bu yüzden yapmalıyım git pull origin <current_branch>

Git parola istemez ve özel anahtar kimlik doğrulama kurulumunuz yoksa, "ölümcül: protokol hatası: hatalı satır uzunluğu karakter: kullanıcı" gibi şifreli bir mesajla başarısız olur .

https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server , sunucuda genel anahtarın nasıl belirleneceğini anlatır. Temel olarak genel anahtarı ~ / .ssh / yetkili_keys veya ~ / .ssh / yetkili_keys2'ye ekleyin

Windows makinesinde Git Bash'e özel anahtarın nasıl sağlanacağı konusunda biraz uğraşmam gerekti. Dan McClain'in /server/194567/how-do-i-tell-git-for-windows-where-to-find-my-private-rsa-key/382801#382801'deki cevabı bunu açıklıyor. Cevabına bir ek, benim durumumda özel anahtar dosyasının id_rsa.pub olarak adlandırılması bekleniyordu

Benim için aynı ana bilgisayar ayrıntılarını özel anahtarla Putty'ye eklemek (puttygen ile dönüştürmek) işe yaradı. Bundan sonraki herhangi bir git bash komutunda sorun yoktu.

Putty kullanırsanız. Ardından Pageant'ın çalıştığından ve özel anahtarınızın Pageant'a yüklendiğinden emin olun (Görev çubuğundaki Pageant simgesine fareyle sağ tıklayın ve açılan menüden "Tuşları Görüntüle" ye tıklayın).

Aksi takdirde cmd.exe'de yaptığınızda:

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

"ölümcül: protokol hatası: hatalı satır uzunluğu karakteri:" mesajını alırsınız

TL; DR: Do not omitusername@ zaman Windows üzerinde uzaktan URL'lerinizdeki.

Linux'ta ve varsayılan ssh ile Windows'ta, aşağıdaki gibi uzak URL'lerden kullanıcı adını çıkarabilirsiniz:

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

Çünkü ssh'nin varsayılan davranışı, şu anda oturum açmış olduğunuz kullanıcı adını kullanmaktır. Windows üzerindeyseniz ve kullanmak için git'i ayarladıysanız plink.exe, bu şekilde anahtarınızı kullanabileceksiniz pageant, o zaman bu çalışmayacaktır, çünkü plinkaynı otomatik kullanıcı adı davranışına sahip değildir ve bu şifreli hata mesajlarına neden olacaktır, çünkü kullanıcı adı istemi:

$ plink server-name
login as: _

Karşı:

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

Bir depoyu zaten bir şekilde klonladıysanız , uzak URL'ye .git/configekleyerek uzaktan kumandaları onarabilirsiniz username@.

Sunucuda Kabuk erişimine izin verilip verilmediğini kontrol edin.

Hata dönüştürülmüş: ölümcül: protokol hatası: hatalı satır uzunluğu karakter: fata

git-upload-pack'in konumunu sistem yoluna ekledikten sonra.

Sorun, depo adının etrafına eklenen bir kesme işareti gibi görünüyor: git istemcisi tarafından eklenen Process Monitor (sys internals'dan) gibi bir araçla bakmak. Git'e özgü bir pencere sorunu gibi görünüyor.

Sunucunun isteminde aynı komut satırını denedim: tam hata "ölümcül: belirli bir depo değil (veya ana dizinlerden herhangi biri): .git"

Sonuç olarak, bana bir yazılım hatası gibi görünüyor. Bir git uzmanı olmadığımı unutma, git'i ilk kez kullanıyorum, yıkıcılıktan ve performanstan geliyorum.

Bununla da karşılaştık.

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

Neyin yanlış gittiğine dair gitty detaylarını bilmiyorum, ama bizim durumumuzda onu tetikleyen, sunucudaki diskin dolu olmasıydı.

Makinenizde bir güvenlik erişimi olabilir, Pageant'ı çalıştırıyor musunuz (bu bir macun ajanıdır)?

git projenize her zaman http bağlantınız olabilir. Bunu ssh bağlantısı yerine kullanabilirsiniz. Bu sadece sahip olduğunuz bir seçenek

Ben de aynı sorunu yaşadım (Windows 7). Depoyu şifreyle almayı deneyin. Git Bash + Plink (ortam değişkeni GIT_SSH) + Pageant kullanıyorum. GIT_SSH'yi (geçici) silmek bana yardımcı oluyor. Neden aynı anda hem parola hem de RSA ile giriş yapamıyorum bilmiyorum ...

Burada geç cevap, ama umarım birine yardımcı olur. Bu bir protokol hatasıysa, yerel git ile uzak git ile iletişim kuramayan bir şey yapması gerekir. Depoyu ssh aracılığıyla klonladıysanız ve bir süre sonra, deponun anahtarlarını kaybettiyseniz veya ssh aracınız artık bu anahtarları bulamıyorsa bu gerçekleşebilir.

Çözüm

1. Yeni bir anahtar oluşturun ve git deponuza ekleyin veya anahtarlar hala yanınızda ve başkasında yoksa anahtarları yüklemek için ssh aracınızı yapılandırın;)

2. Diğer bir hızlı düzeltme, .gitdizininize gidip configdosyanın - [remote "origin"] urldan git- arasında düzenlenmesidir , httpböylece ssh anahtarlarına basmak gerekmez ve kullanıcı adınızı ve parolanızı sormaya geri döner.

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

Değişmek

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

Ssh exectuable'ı yerleşikten nativ'e ayarlar / sürüm kontrolü / git altında değiştirmek benim için hile yaptı.