Git Remote: Lỗi: nghiêm trọng: lỗi giao thức: ký tự độ dài dòng kém: Unab

Tôi đã thiết lập một máy chủ git và bây giờ muốn đẩy repo của tôi ban đầu từ máy khách. Tôi đã sử dụng git push origin mastervà nhận được thông báo lỗi này:

fatal: protocol error: bad line length character: Unab

Tôi không biết có chuyện gì. Tôi không biết "Unab" là gì. Tôi đã cố gắng thay đổi kích thước của shell nhưng nó vẫn là "Unab". Tôi không thể tìm thấy giải pháp cho thông báo lỗi này.

Tôi thiết lập máy chủ với "allow_keys" và SSH. (Tôi có thể kết nối với nó bằng SSH.)

Nó có vẻ là một vấn đề git?

BTW: Máy chủ được thiết lập trong máy ảo Windows 7

Thông báo lỗi này hơi khó hiểu, nhưng những gì nó thực sự đang cố gắng cho bạn biết là máy chủ từ xa đã không trả lời bằng phản hồi git thích hợp. Cuối cùng, đã xảy ra sự cố trên máy chủ đang chạy git-receive-packquy trình.

Trong giao thức Git, bốn byte đầu tiên phải là độ dài dòng. Thay vào đó, họ là các ký tự Unab... mà có lẽ là sự khởi đầu của một thông báo lỗi nào đó. (tức là, nó có thể là " Unable to..." làm gì đó).

Điều gì xảy ra khi bạn chạy ssh <host> git-receive-pack <path-to-git-repository>? Bạn sẽ thấy thông báo lỗi mà ứng dụng git của bạn đang bật và bạn có thể sửa nó.

Tôi đã gặp sự cố tương tự, nhưng thông báo lỗi chính xác là:

nghiêm trọng: lỗi giao thức: ký tự độ dài dòng không hợp lệ: Usin

Đây là trong Windows, GIT_SSHđược đặt thành đường dẫn plink.execủa PuTTY.

Các vấn đề có thể xảy ra và giải pháp:

• Đảm bảo rằng đường dẫn đến plink.exelà chính xác. Ví dụ: đường dẫn kiểu Unix cũng hoạt động tốt/c/work/tools/PuTTY/plink.exe
• Đảm bảo rằng tác nhân chính của PuTTY ( pageant.exe) đang chạy
• Đảm bảo tác nhân chính chứa khóa hợp lệ để truy cập vào máy chủ

Đối với người dùng GitExtension:

Tôi gặp phải vấn đề tương tự sau khi nâng cấp git lên 2.19.0

Giải pháp:

Công cụ> Cài đặt> Tiện ích mở rộng Git> SSH

Chọn [ OpenSSH ] thay vì [ PuTTY ]

Tôi đã gặp vấn đề tương tự sau khi cài đặt GIT trên Windows. Lúc đầu nó hoạt động; sau đó, một ngày sau (sau khi PC khởi động lại), nó không còn nữa và tôi nhận được điều này:

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

Vấn đề là sau khi khởi động lại, Putty "pageant.exe" tự động khởi động không có khóa cá nhân hoạt động nữa. Khi bạn thêm khóa trong cuộc thi, nó không phải là một cài đặt liên tục theo mặc định. Tôi chỉ cần thêm khóa một lần nữa và nó hoạt động tốt. Vì vậy, đối với trường hợp đó, cần phải làm cho pagenant tải khóa tự động, như đã thảo luận ở đây:

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

Có thể bạn có một câu lệnh trong .bashrc của máy chủ tạo ra đầu ra. Ví dụ, tôi đã có điều này:

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

Trong trường hợp này, đầu ra từ việc sử dụng rvm sẽ được hiểu (sai) là đến từ git. Vì vậy, hãy thay thế nó bằng:

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

Sau khi tải khóa cá nhân SSH trong Tiện ích mở rộng Git, vấn đề này sẽ được giải quyết.

Bạn có thể chuyển hướng bất kỳ đầu ra từ .bashrcđể stderr:

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

git sẽ bỏ qua các ký hiệu này

Tôi đã gặp sự cố tương tự trên Windows bằng Git Bash. Tôi tiếp tục gặp lỗi này khi cố gắng tạo bản sao git. Kho lưu trữ trên hộp Linux có cài đặt GitLab.

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

Tôi đảm bảo rằng khóa ssh đã được tạo. Khóa công khai đã được thêm vào GitLab. Ssh-agent đang chạy và khóa được tạo đã được thêm vào ( liên kết github ).

Tôi đã hết các tùy chọn và cuối cùng đã thử đóng Git Bash và mở lại bằng cách nhấp chuột phải vào 'Run as Administrator'. Làm việc sau đó.

Điều này có thể giúp ai đó. Khi tôi cố gắng sao chép một dự án từ một phiên bản EC2, tôi đã gặp lỗi dưới đây:

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

Giải pháp cho tôi bao gồm các bước dưới đây:

1. Đảm bảo khóa SSH (công khai) được thêm / cập nhật trong phiên bản EC2.
2. Đảm bảo tác nhân xác thực (trong trường hợp của tôi là Pageant = Putty Authentication Agent) đang chạy và khóa cá nhân tương ứng được tải.

3. Sử dụng ID khóa SSH EC2 cho khóa công khai cho bản sao git. Thí dụ:

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

Đối với tôi, đó là vì tôi đã thêm gần đây

RequestTTY force

thành .ssh / config

bình luận điều này cho phép nó hoạt động

Kiểm tra các tệp khởi động của bạn trên tài khoản được sử dụng để kết nối với máy từ xa để tìm câu lệnh "echo". Đối với Bash shell, chúng sẽ là .bashrc và .bash_profile của bạn, v.v. Edward Thomson trả lời đúng trong câu trả lời của mình nhưng một vấn đề cụ thể mà tôi đã gặp là khi có một số bản in boiler-plate khi đăng nhập vào máy chủ qua ssh. Git sẽ lấy bốn byte đầu tiên của boiler-plate đó và gây ra lỗi này. Bây giờ trong trường hợp cụ thể này, tôi sẽ đoán rằng "Unab" thực sự là tác phẩm "Không thể ..." có thể chỉ ra rằng có điều gì đó sai khác trên máy chủ Git.

Trong trường hợp của tôi sau khi lấy nó được viết: fatal: protocol error: bad line length character: Pass. Ngoài ra sau khi đẩy tôi nhận: fatal: protocol error: bad line length character: git@ Done.

Sau khi khởi động lại Windows, tôi phải khởi động lại "PuTTY agent" (pageant.exe) và thêm một khóa riêng đã biến mất khỏi danh sách các khóa.

FYI Tôi nhận được thông báo lỗi tương tự này sau khi tôi nâng cấp vùng chứa CentOS6 lên CentOS7 - một số hoạt động git bắt đầu không thành công khi xây dựng vùng chứa, ví dụ:

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

Chạy ssh đã cho tôi một lỗi mà tôi có thể tìm kiếm trên:

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

Điều đó dẫn tôi đến https://github.com/wolfcw/libfaketime/issues/63 , nơi tôi nhận ra rằng tôi đã quên rằng tôi có một LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1Dockerfile mẹ. Nhận xét mà ra đã sửa lỗi.

Trong trường hợp của tôi, sự cố là Putty 32-bit và pageant.exe - nó không thể giao tiếp với TortoisePlink.exe 64-bit. Việc thay thế Putty 32 bit bằng phiên bản 64 bit đã giải quyết được vấn đề.

Tôi đã gặp lỗi tương tự "fatal: protocol error: bad line length character: shmi" Trường hợp shmitên người dùng là trong trường hợp của tôi. Tôi đã chuyển SSH từ PuTTY sang OpenSSH trong "Git Extensions->Settings->SSH". Nó đã giúp đỡ.

Tôi đã gặp vấn đề tương tự như Christer Fernstrom. Trong trường hợp của tôi, đó là một thông báo tôi đã đặt trong .bashrc của mình nhắc nhở tôi thực hiện sao lưu khi tôi chưa thực hiện một bản sao lưu trong vài ngày.

Những điều sau có thể giúp ích cho ai đó: Khi cố gắng sao chép một dự án mà tôi có trên phiên bản AWS EC2 của mình, tôi đã gặp lỗi sau:

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

Điều này là do cố gắng ssh dưới dạng root thay vì EC2-USER. nếu bạn thực sự ssh mà không thực hiện nhân bản git ... bạn sẽ thấy thông báo lỗi trong một cái gì đó dọc theo dòng "Vui lòng đăng nhập bằng người dùng ec2" Khi tôi nhân bản git với tư cách là người dùng ec2 thì điều đó là tốt.

Tôi cũng gặp phải lỗi đó một lần, nhưng khi nó xảy ra, điều đó có nghĩa là chi nhánh của tôi không được cập nhật nên tôi phải làm git pull origin <current_branch>

Git không nhắc nhập mật khẩu và không thành công với thông báo khó hiểu tương tự "death: protocol error: bad line length character: user" nếu bạn cũng không có thiết lập xác thực khóa riêng tư của mình .

https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server cho biết cách chỉ định khóa công khai trên máy chủ. Về cơ bản, thêm khóa công khai vào ~ / .ssh / allow_keys hoặc ~ / .ssh / allow_keys2

Tôi đã phải đấu tranh một chút về cách cung cấp khóa cá nhân cho Git Bash trên máy windows. Câu trả lời của Dan McClain trong /server/194567/how-do-i-tell-git-for-windows-where-to-find-my-private-rsa-key/382801#382801 mô tả điều đó. Một bổ sung cho câu trả lời của anh ấy, trong trường hợp của tôi, tệp khóa cá nhân dự kiến ​​sẽ được đặt tên là id_rsa.pub

Đối với tôi, việc thêm các chi tiết máy chủ tương tự vào Putty với khóa riêng (chuyển đổi bằng puttygen) đã hoạt động. Mọi lệnh git bash sau đó đều không có vấn đề gì.

Nếu bạn sử dụng Putty. Sau đó, đảm bảo rằng Pageant đang chạy và khóa riêng của bạn được tải trong Pageant (nhấp chuột phải vào biểu tượng Pageant trên Thanh tác vụ và nhấp vào "Xem các phím" trên menu bật lên).

Nếu không, khi bạn thực hiện trong cmd.exe:

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

bạn nhận được thông báo này "death: protocol error: bad line length character:"

TL; DR: Đỗ không bỏ qua username@trong URL từ xa của bạn khi trên Windows.

Trên Linux và Windows với ssh mặc định, bạn có thể bỏ qua tên người dùng khỏi các URL từ xa, như sau:

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

Bởi vì hành vi mặc định của ssh là chỉ sử dụng bất kỳ tên người dùng nào bạn hiện đang đăng nhập. Nếu bạn đang sử dụng Windows và đã thiết lập git để sử dụng plink.exeđể bạn có thể sử dụng khóa được tải trong của mình pageant, thì điều này sẽ không hoạt động, vì plinkkhông có cùng hành vi tên người dùng tự động này, dẫn đến các thông báo lỗi khó hiểu đó, vì nó sẽ nhắc tên người dùng:

$ plink server-name
login as: _

Đấu với:

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

Nếu bạn đã sao chép một kho lưu trữ bằng cách nào đó, bạn có thể sửa các điều khiển từ xa trong của mình .git/configbằng cách thêm username@vào URL từ xa.

Kiểm tra xem truy cập Shell có được phép trên máy chủ hay không.

Lỗi được chuyển đổi trong: nghiêm trọng: lỗi giao thức: ký tự độ dài dòng không hợp lệ: fata

sau khi thêm vị trí của git-upload-pack vào đường dẫn hệ thống.

Vấn đề dường như là một dấu nháy đơn được thêm vào xung quanh tên kho lưu trữ: Tìm kiếm bằng một công cụ như Process Monitor (từ nội bộ hệ thống), được thêm bởi ứng dụng khách git. Nó có vẻ là một vấn đề cửa sổ cụ thể git.

Tôi đã thử cùng một dòng lệnh trong lời nhắc của máy chủ: lỗi đầy đủ là "nghiêm trọng: không phải là một kho lưu trữ nhất định (hoặc bất kỳ thư mục mẹ nào): .git"

Tóm lại, đối với tôi, nó có vẻ như là một lỗi phần mềm. Xin lưu ý rằng tôi không phải là một chuyên gia về git, đây là lần đầu tiên tôi sử dụng git, tôi đến từ lật đổ và áp lực.

Chúng tôi cũng gặp phải vấn đề này.

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

Tôi không biết chi tiết gitty về những gì đã xảy ra, nhưng trong trường hợp của chúng tôi, điều đã kích hoạt là đĩa trên máy chủ đã đầy.

Đó có thể là quyền truy cập bảo mật trên máy của bạn, bạn có đang chạy Pageant (là một đặc vụ giả mạo) không?

bạn luôn có thể có liên kết http tới dự án git của mình. Bạn có thể sử dụng nó thay vì liên kết ssh. Đây chỉ là một lựa chọn bạn có

Tôi cũng gặp vấn đề này (Windows 7). Cố gắng nhận repo bằng mật khẩu. Tôi sử dụng Git Bash + Plink (biến môi trường GIT_SSH) + Pageant. Xóa GIT_SSH (tạm thời) giúp tôi. Tôi không biết tại sao tôi không thể sử dụng đăng nhập bằng thẻ và đăng nhập bằng RSA cùng một lúc ...

Câu trả lời muộn ở đây, nhưng hy vọng nó sẽ giúp một ai đó. Nếu lỗi giao thức, nó phải làm gì đó với git cục bộ của bạn không thể giao tiếp với git từ xa. Điều này có thể xảy ra nếu bạn sao chép repo qua ssh và đôi khi sau đó, bạn bị mất chìa khóa vào repo hoặc nhân viên ssh của bạn không thể tìm thấy các khóa đó nữa.

Giải pháp

1. Tạo một khóa mới và thêm nó vào kho git của bạn hoặc định cấu hình đại lý ssh của bạn để tải các khóa nếu bạn vẫn còn giữ chìa khóa bên mình & không mang theo người khác;)

2. Một cách khắc phục nhanh chóng khác là truy cập .gitthư mục của bạn và chỉnh sửa configtệp [remote "origin"] urltừ gitthành httpđể không cần phải đẩy các khóa ssh và nó sẽ trở lại yêu cầu tên người dùng và mật khẩu của bạn.

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

Thay đổi thành

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

Thay đổi ssh có giá trị từ nội trang thành nativ trong cài đặt / kiểm soát phiên bản / git đã thực hiện thủ thuật cho tôi.