sftp đưa ra một lỗi: Tin nhắn nhận được quá dài và đó là lý do gì?

Tôi đã có thể thực hiện sftpngày hôm qua với hộp RHEL 5.4 (RedHat) và hôm nay tôi không thể.

Thông điệp là "Received message too long 778199411", và sau một vài cuộc điều tra, đó là do hộp RHEL của tôi .bashrccó một dòng echo "running .bashrc"- hoặc lặp lại bất cứ điều gì, tôi nghĩ vậy.

Vậy tại sao in ra một dòng ảnh hưởng sftp? Nó cảm thấy giống như một vấn đề thiết kế khi in ra một dòng trong .bashrccác tác phẩm trong các tình huống khác như đăng nhập hoặc sshrất khó để theo dõi khi sftpthất bại vì một lý do kỳ lạ như vậy.

Vì vậy, câu hỏi là, tại sao in ra một dòng gây ra lỗi như vậy và nếu chúng ta vẫn muốn in ra một cái gì đó trong .bashrc? (chủ yếu để xem khi tập tin này có nguồn gốc / thực thi).

Đây là một vấn đề lâu dài. Tôi đã tìm thấy nó mười năm trước khi lần đầu tiên tôi phải kết hợp SSH thương mại tại nơi làm việc và SSH mở tại nhà. Tôi chạy vào nó một lần nữa ngày hôm nay và tìm thấy bài viết này.

Nếu tôi đã tìm kiếm "sftp / scp fail nhưng ssh vẫn ổn" thì tôi đã được nhắc nhở về giải pháp sớm hơn!

Nói một cách đơn giản, .bashrc và .bash_profile v.v ... phải im lặng hoặc chúng can thiệp vào giao thức kết nối sftp / scp.

Xem Câu hỏi thường gặp về SSH mở:

2.9 - sftp / scp không kết nối được, nhưng ssh vẫn ổn.

Ít nhất là đối với SFTP, điều này có thể được khắc phục bằng cách sử dụng internal-sftphệ thống con, vì nó không đọc .bashrchoặc /etc/motd.

Chỉ cần thay đổi /etc/ssh/sshd_configtệp và thay đổi hệ thống con SFTP:

#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp

Và lỗi đã biến mất.

Mọi phản hồi tôi từng thấy ở bất cứ đâu trên đây đều khẳng định rằng đó là quá nhiều đầu ra được in qua /etc/motd, hoặc .bashrc, v.v. Không phải lúc nào cũng đúng. Nếu bạn có một tài khoản không có .bashrc, tài khoản /etc/motdtrống và mặc định .bashrclà tối thiểu không có đầu ra được in, BẠN CÓ THỂ VẪN gặp sự cố. Nếu bạn có tài khoản người dùng có vỏ /sbin/nologinhoặc /bin/falselỗi này vẫn sẽ xảy ra.

Tại sao bạn sẽ làm điều này ??? Nếu bạn đang cố gắng cấp cho ai đó bị bỏ tù sftp, không có quyền truy cập shell an toàn thì điều này sẽ xảy ra.

Làm việc xung quanh: cho phép sshvà đưa chúng vào một nhà tù gốc. Đây là một vấn đề cần được giải quyết ssh, nó sẽ còn quá lâu nữa.

chỉ cần đặt theo sau vào đầu ~ / .bashrc trên tên người dùng của id trên máy từ xa nếu id đó sử dụng bash

# If not running interactively, don't do anything and return early
[[ $- == *i* ]] || return  

đơn giản là thoát sớm từ ~ / .bashrc thay vì tìm nguồn cung cấp toàn bộ tệp ... điều này giải quyết việc .bashrc im lặng khi bạn không đăng nhập vào id đó và chỉ chạy scp hoặc sftp của bạn với tên người dùng đó làm id từ xa ... để trích dẫn @Peter Scott trong câu trả lời khác: "Nói một cách đơn giản, .bashrc và .bash_profile, v.v. phải im lặng hoặc họ can thiệp vào giao thức kết nối sftp / scp."

Ngoài ra, nếu id từ xa đó sử dụng zsh thì hãy đặt theo sau ở trên ~ / .zshrc của nó

# If not running interactively, don't do anything and return early
[[ -o interactive ]] || exit 0

Nếu hệ vỏ trên máy từ xa của bạn không sử dụng ~ / .bashrc thì hãy chỉnh sửa ở trên trong tệp ~ / .bashrc_profile hoặc ~ / .profile hoặc tương tự để phù hợp với vỏ của bạn trên hộp từ xa đó

Có thể có thêm một lý do. Trên RHEL 6 với openssh-5.3p1-122.el6.x86_64 chúng tôi đã tìm thấy, nó hoạt động sai khi LOCALE vẫn ở "C". Khi thay đổi với:

export LC_ALL="en_US.UTF-8"

Sau đó sftp cư xử chính xác. Trong lần mở cửa trước-5.3p1-118, chúng tôi chưa gặp phải một hành vi như vậy nên có lẽ đó là một lỗi nhỏ trong bản dựng này.

Trong trường hợp của tôi, để làm cho nó hoạt động, tôi cần phải tắt thông báo chào mừng của Ubuntu.