sftp
Wczoraj 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 .bashrc
ma 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 .bashrc
pracach w innych sytuacjach, takich jak logowanie lub ssh
jest dość trudne do wyśledzenia, gdy sftp
zawodzi 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).
Odpowiedzi:
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.
źródło
ssh yourhost /usr/bin/true
do zbadania wyjścia twojego ssh. W moim przypadku znalazłem jakieś polecenie w ~ / .bashrc zaczęło generować błędy.Przynajmniej w przypadku SFTP można to naprawić za pomocą
internal-sftp
podsystemu, ponieważ nie czyta.bashrc
ani/etc/motd
.Po prostu zmień
/etc/ssh/sshd_config
plik i zmień podsystem SFTP:Błąd zniknął.
źródło
internal-sftp
jest, IMO, lepszym sposobem oferowania wsparcia SFTP. Możesz zobaczyć ten powiązany post: serverfault.com/questions/660160/…Każda odpowiedź widziałem nigdzie na tym wszyscy twierdzą, że jest zbyt dużo wydruku poprzez
/etc/motd
, lub.bashrc
itp nie zawsze prawdziwe. Jeśli masz konto, które nie ma.bashrc
, oznacza/etc/motd
to , że jest puste, a wartość domyślna.bashrc
jest minimalna i nie ma wydruków. Jeśli masz konto użytkownika z powłoką/sbin/nologin
lub/bin/false
ten 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
ssh
im również umieścić je w więzieniu. Jest to problem, którym należy się zająćssh
. Nadchodzi zbyt długo.źródło
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
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
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
źródło
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ą:
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.
źródło
W moim przypadku, aby to działało, musiałem wyłączyć wiadomość powitalną Ubuntu.
źródło