sftp wyświetla błąd: „Za długo odebrano wiadomość” iz jakiego powodu?

sftpWczoraj mogłem zrobić z urządzeniem RHEL 5.4 (RedHat), a dziś nie mogę.

Wiadomość jest taka "Received message too long 778199411", a po pewnym dochodzeniu wynikała z tego, że moja skrzynka RHEL .bashrcma linię echo "running .bashrc"- lub w ogóle coś echa, tak myślę.

Dlaczego więc miałoby to wpływać na wydrukowanie linii sftp? Wydawało się to trochę problemem projektowym, ponieważ drukowanie linii w .bashrcpracach w innych sytuacjach, takich jak logowanie lub sshjest dość trudne do wyśledzenia, gdy sftpzawodzi z tak dziwnego powodu.

Pytanie brzmi: dlaczego wydrukowanie linii powoduje taki błąd i co jeśli nadal chcemy coś wydrukować .bashrc? (głównie, aby zobaczyć, kiedy ten plik zostanie pobrany / wykonany).

To długotrwały problem. Znalazłem to dziesięć lat temu, kiedy po raz pierwszy musiałem mieszać komercyjny SSH w pracy i open-SSH w domu. Znalazłem go dzisiaj i znalazłem ten post.

Gdybym szukał „sftp / scp nie powiedzie się, ale ssh jest OK”, przypomniałbym sobie o rozwiązaniu wcześniej!

Mówiąc prościej, .bashrc i .bash_profile itp. Muszą być ciche lub zakłócają protokół połączenia sftp / scp.

Zobacz otwarte SSH FAQ:

2.9 - sftp / scp kończy się niepowodzeniem przy połączeniu, ale ssh jest w porządku.

Przynajmniej w przypadku SFTP można to naprawić za pomocą internal-sftppodsystemu, ponieważ nie czyta .bashrcani /etc/motd.

Po prostu zmień /etc/ssh/sshd_configplik i zmień podsystem SFTP:

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

Błąd zniknął.

Każda odpowiedź widziałem nigdzie na tym wszyscy twierdzą, że jest zbyt dużo wydruku poprzez /etc/motd, lub .bashrcitp nie zawsze prawdziwe. Jeśli masz konto, które nie ma .bashrc, oznacza /etc/motdto , że jest puste, a wartość domyślna .bashrcjest minimalna i nie ma wydruków. Jeśli masz konto użytkownika z powłoką /sbin/nologinlub /bin/falseten błąd nadal będzie występował.

Dlaczego miałbyś to zrobić??? Jeśli próbujesz przyznać komuś aresztowanie roota sftp, bez dostępu do bezpiecznej powłoki tak się stanie.

Obejdź: pozwól sshim również umieścić je w więzieniu. Jest to problem, którym należy się zająć ssh. Nadchodzi zbyt długo.

po prostu wstaw następujący znak na początku ~ / .bashrc na nazwie użytkownika id na zdalnym komputerze, jeśli ten identyfikator używa bash

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

który po prostu wychodzi wcześniej z ~ / .bashrc zamiast pozyskiwać cały plik ... rozwiązuje to wyciszenie .bashrc, gdy nie logujesz się do tego identyfikatora i po prostu uruchamiasz scp lub sftp z tą nazwą użytkownika jako zdalnym identyfikatorem ... cytując @Peter Scott w innej odpowiedzi: „Mówiąc wprost, .bashrc i .bash_profile itp. muszą milczeć lub zakłócają protokół połączenia sftp / scp.”

Alternatywnie, jeśli ten zdalny identyfikator korzysta z zsh, umieść następujące na jego ~ / .zshrc

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

Jeśli powłoka na zdalnym komputerze nie używa ~ / .bashrc, wykonaj powyższą edycję w pliku ~ / .bashrc_profile lub ~ / .profile lub podobnym, aby dopasować ją do powłoki na tym zdalnym komputerze

Może być jeszcze jeden powód. Na RHEL 6 z openssh-5.3p1-122.el6.x86_64 stwierdziliśmy, że zachowuje się źle, gdy LOCALE pozostaje w „C”. Po zmianie za pomocą:

export LC_ALL="en_US.UTF-8"

Następnie sftp zachowuje się poprawnie. W poprzednim openssh-5.3p1-118 nie doświadczyliśmy takiego zachowania, więc prawdopodobnie jest to niewielki błąd w tej wersji.

W moim przypadku, aby to działało, musiałem wyłączyć wiadomość powitalną Ubuntu.