Dziwny problem z SSH, ssh działa z -t, ale zawiesza się bez niego

Gdy wchodzę sshna jeden z moich serwerów, wydaje się, że loguję, ale potem zawiesza się, zanim poda mi monit ( message debug2: shell request accepted on channel 0 is the last log entry).

Choć dziwne jest to, że ssh -t "/bin/bash"działa ssh.

Czego się dowiedziałem do tej pory

• Mogę normalnie zalogować się poprawnie z serwerów w tej samej lokalizacji geograficznej
• Jeśli ja ssh -t '/bin/bash'- mogę zalogować się idealnie z DOWOLNEJ lokalizacji.
• Jeśli używam rsync do serwera, wydaje się do pracy, a następnie blokuje
• Jeśli używam rsync z serwera, działa bez problemu

Co próbowałem

• usunięcie lub zmiana wszystkich opcji logowania .profile,.bashrc /etc/profile
• Zmiana ssh_config i / lub sshd_config jednego z identycznego serwera, który działa dobrze
• Sprawdziłem routing
• Ekspert od sieci tcpdumpbezskutecznie sprawdził (choć wydaje się, że jest wiele powtórzeń)

Naprawdę nie mogę myśleć o niczym innym

Oprócz podejrzanego sterownika karty sieciowej / oprogramowania układowego.

Może to wynikać z problemu w profilu.
Podczas łączenia ze ssh -t /bin/bash swojej skorupy nie będzie „logowania”, to nie będzie zaopatrywać się /etc/profileani ~/.profilei ~/.bashrc...

Po podłączeniu przełącz powłokę w tryb debugowania, a następnie przeszukaj każdy plik, aby znaleźć to, co blokuje:

set -x 
. /etc/profile 
...and so on

EDYTOWAĆ

Zauważ, że się myliłem, plik .bashrc będzie pochodzić z dowolnej interaktywnej powłoki (więc tylko profil, pliki profile.d mają znaczenie tutaj).

Spróbuj sporządzić listę różnych faz procesu połączenia. Coś takiego

1) łączenie ssh (konfiguracja, ...)
2) logowanie (PAM, tty, wtmp, ...)
3) uruchamianie powłoki (profil, dostęp do katalogu domowego, ...)

Aby sprawdzić (1), możesz uruchomić demona sshd w trybie debugowania. W tym celu musisz uruchomić kolejny sshd, nasłuchując dedykowanego portu (nie na porcie 22, więc nie musisz zatrzymywać zwykłego demona sshd).

# /usr/sbin/sshd -p 2222 -ddd 

To sshd akceptuje tylko jedno połączenie i nie przechodzi w tło. Otwórz inny terminal i połącz się z tą sesją ssh.

# ssh -vvv -p 2222 user@host

Możesz porównać otrzymane wiadomości z innym serwerem tej samej marki. Wtedy będziesz wiedział, czy problem jest po stronie ssh, czy nie.

(-ddd i -vvv to maksymalny poziom debugowania, można go dostroić)

Mam ten link , znacznie bardziej szczegółowy.

Odpowiedź na mój problem Okazuje się, że był to problem z siecią. W końcu dowiedziałem się, że obniżenie MTU wszystkich kart sieciowych sprawiło, że problem zniknął.

Najprawdopodobniej coś jest źle skonfigurowane dla tej sieci, ale teraz mogę to udowodnić i przekazać zespołowi sieci (który ciągle mi mówił, że to problem z serwerem).

Pamiętaj jednak, że jest to ostateczność . Osobliwością było to, że serwer ssh działał w tej samej podsieci, ale nie poza nią, a ssh -t '/ bin / bash' działał z dowolnego miejsca.

Miałem też rsyncs, który zacząłby się dobrze, ale w pewnym momencie po prostu zawiesiłem się lub zrzuciłem połączenie.

Więc jeśli patrzysz na tę odpowiedź, wypróbuj najpierw powyższe i TYLKO, jeśli masz dziwactwa takie jak moje, to może to pomóc.

Dziękuję za wszelką pomoc. Próbowałem wszystkiego i nauczyło mnie to ładunków i pozwoliło mi potwierdzić, że nie miało to nic wspólnego z serwerem (to wszystko, na co liczyłem).

Dziękuję więc wszystkim, którzy pomogli

Gdy to zrobisz ssh some_user@some_host /bin/bash, co robisz jest uruchomienie some_user „s Shell (zgodnie z definicją zawartą w /etc/passwddniu some_host ), a następnie wykonanie danego polecenia /bin/bash, od wewnątrz tej powłoki.

Teraz powłoka some_user (załóżmy, że również bash) nie jest uruchamiana interaktywnie (zamiast tego wykonuje podane polecenie). Więc nie przydziela pty ( pseudo-terminalu ), a to oznacza, że ​​nie ma pty do użycia przez wydane polecenie, więc zaczyna się ono nieinteraktywnie.

W tym przykładzie uruchomiono żądane /bin/bashpolecenie, ale wydaje się, że się zawiesiło.

Możesz to naprawić, prosząc ssho utworzenie pty tak, aby był dostępny dla powłoki i jej procesów potomnych. To właśnie -trobi.

    $ ssh -t some_user@some_host bash

Możesz to również naprawić, zmuszając polecenie do utworzenia pty. Dla bash, możesz to zrobić przekazując -iargument. Powinien również działać następujący wiersz polecenia:

$ ssh some_user@some_host bash -i

Należy jednak pamiętać, że w tym ostatnim przypadku powłoka nie może uzyskać dostępu, /dev/ttyco powoduje ostrzeżenie:

bash: no job control in this shell

Przyczyny tego wyjaśniono tutaj . Może to stanowić problem, w zależności od tego, co planujesz zrobić w powłoce, ale użycie ssh -tprawdopodobnie jest lepszą opcją.

(zwróć uwagę, że możesz przekazać bashto polecenie, ponieważ i tak powinno ono znajdować się na ścieżce domyślnej powłoki użytkownika)

Mam ten sam problem, gdy ostatnio korzystałem z zagnieżdżonej platformy wirtualizacji.

Działa po zmniejszeniu MTU z 1500 do 1400 na serwerze źródłowym lub docelowym.

/sbin/ip link set dev eth0 mtu 1400