sftp memberikan kesalahan: "Pesan yang diterima terlalu lama" dan apa alasannya?

Saya dapat melakukan sftpkemarin ke kotak RHEL 5.4 (RedHat) dan hari ini saya tidak bisa.

Pesannya adalah "Received message too long 778199411", dan setelah beberapa penyelidikan, itu karena kotak RHEL saya .bashrcmemiliki garis echo "running .bashrc"- atau menggemakan apa pun, saya pikir.

Jadi mengapa mencetak garis akan memengaruhi sftp? Rasanya agak seperti masalah desain karena mencetak garis dalam .bashrcpekerjaan dalam situasi lain seperti masuk atau sshdan agak sulit untuk melacak ketika sftpgagal karena alasan aneh.

Jadi pertanyaannya adalah, mengapa mencetak garis menyebabkan kesalahan seperti itu dan bagaimana jika kita masih ingin mencetak sesuatu .bashrc? (terutama untuk melihat kapan file ini didapat / dieksekusi).

Ini adalah masalah yang sudah berlangsung lama. Saya menemukannya sepuluh tahun yang lalu ketika saya pertama kali harus mencampur SSH komersial di tempat kerja dan SSH terbuka di rumah. Saya menabraknya lagi hari ini dan menemukan posting ini.

Jika saya telah mencari "sftp / scp gagal tetapi ssh tidak apa-apa" Saya akan segera diingatkan solusinya!

Sederhananya, .bashrc dan .bash_profile dll harus diam atau mereka mengganggu protokol koneksi sftp / scp.

Lihat FAQ SSH terbuka:

2.9 - sftp / scp gagal saat koneksi, tetapi ssh OK.

Setidaknya untuk SFTP ini dapat diperbaiki dengan menggunakan internal-sftpsubsistem, karena tidak membaca .bashrcatau /etc/motd.

Cukup ganti /etc/ssh/sshd_configfile dan ubah subsistem SFTP:

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

Dan kesalahan sudah hilang.

Setiap tanggapan yang saya lihat di mana saja tentang semua ini mengklaim itu adalah hasil cetak yang terlalu banyak melalui /etc/motd, atau .bashrc, dll. Jika Anda memiliki akun yang tidak memiliki .bashrc, yang /etc/motdkosong, dan default .bashrcadalah minimal tanpa hasil cetak ANDA BISA MASIH memiliki masalah. Jika Anda memiliki akun pengguna dengan shell /sbin/nologinatau /bin/falsekesalahan ini masih akan terjadi.

Mengapa kamu melakukan ini ??? Jika Anda mencoba untuk memberikan seseorang root-jailed sftp, tanpa akses secure-shell ini akan terjadi.

Atasi: izinkan sshdan letakkan mereka di root jail juga. Ini adalah masalah yang perlu diatasi ssh, itu terlalu lama datang.

cukup masukkan berikut di atas ~ / .bashrc pada nama pengguna id pada mesin jarak jauh jika id itu menggunakan bash

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

yang hanya keluar lebih awal dari ~ / .bashrc alih-alih mencari seluruh file ... ini menyelesaikan membuat .bashrc diam ketika Anda tidak masuk ke id itu dan hanya menjalankan scp atau sftp dengan nama pengguna itu sebagai id jarak jauh ... mengutip @Peter Scott dalam jawaban lain: "Sederhananya, .bashrc dan .bash_profile dll harus diam atau mereka mengganggu protokol koneksi sftp / scp."

Atau, jika id jarak jauh itu menggunakan zsh maka tuliskan berikut di atas ~ / .zshrc

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

Jika shell pada mesin remote Anda tidak menggunakan ~ / .bashrc kemudian buat edit di atas dalam file ~ / .bashrc_profile atau ~ / .profile atau serupa dengan shell Anda pada kotak remote itu

Mungkin ada satu alasan lagi. Pada RHEL 6 dengan openssh-5.3p1-122.el6.x86_64 kami telah menemukan, bahwa berperilaku salah ketika LOCALE tetap di "C". Ketika diubah dengan:

export LC_ALL="en_US.UTF-8"

Kemudian sftp berperilaku dengan benar. Dalam openssh-5.3p1-118 sebelumnya kami belum mengalami perilaku seperti itu sehingga mungkin ada beberapa bug kecil dalam versi ini.

Dalam kasus saya, untuk membuatnya berfungsi, saya harus menonaktifkan pesan sambutan Ubuntu.