błąd tunelu ssh „ssh_exchange_identification: połączenie zamknięte przez zdalny host”

10

Próbuję użyć tunelu ssh z mojego komputera biurowego do mojego komputera domowego i pojawia się błąd, gdy próbuję go użyć.

To, co robię, to uruchomienie jednej powłoki tak:

ssh -gL 12345:my.home.domain:22 my.home.domain

To daje mi odpowiednią powłokę, nie ma problemu. To, co zwykle robię, to ssh na mój komputer domowy za pośrednictwem tego komputera biurowego, na przykład:

ssh -p 12345 127.0.0.1

To zawsze działało dla mnie, aż do zeszłego tygodnia, kiedy konfigurowałem nowy system na moim komputerze domowym (przejście z Ubuntu na Debian). Teraz pojawia się błąd. Nadal mogę otworzyć początkowe połączenie ssh, ale kiedy próbuję użyć tego tunelu, pojawia się (na komputerze biurowym) ten błąd:

ssh_exchange_identification: Connection closed by remote host

Ponadto, gdy tak się stanie, otwarta powłoka, przez którą mam skonfigurowane tunelowanie, wypluwa tę linię:

channel 3: open failed: connect failed: Connection timed out

W tym momencie jestem zagubiony. Jeśli potrzebujesz więcej informacji, chętnie je opublikuję.

============= ponadto ==============

Po dalszym majstrowaniu, okazało się, że otrzymuję inną odpowiedź od serwera (czyli mojego komputera domowego), kiedy próbuję telnet na różnych portach. Jeśli spróbuję:

telnet my.home.domain 22

Odzyskuję to:

Trying <my ip address>...
Connected to <my domain>.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze2

Tego bym się spodziewał. Po skonfigurowaniu tunelu, a następnie telnettingu, widzę następującą odpowiedź:

Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.

============== i jeszcze dalej ==================

Zgodnie z sugestią Kbulgriena , oto wyjście z komputera klienta z opcją -v:

ssh -vp 24600 127.0.0.1
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 marca 2012
debug1: odczyt danych konfiguracyjnych / etc / ssh / ssh_config
debug1: / etc / ssh / ssh_config wiersz 19: Stosowanie opcji dla *
debug1: Łączenie z portem 24600 127.0.0.1 [127.0.0.1]
debug1: Połączenie ustanowione.
debug1: plik tożsamości /home/jacob/.ssh/id_rsa typ -1
debug1: plik tożsamości /home/jacob/.ssh/id_rsa-cert typ -1
debug1: plik tożsamości /home/jacob/.ssh/id_dsa typ -1
debug1: plik tożsamości /home/jacob/.ssh/id_dsa-cert typ -1
debug1: plik tożsamości /home/jacob/.ssh/id_ecdsa typ -1
debug1: plik tożsamości /home/jacob/.ssh/id_ecdsa-cert typ -1
ssh_exchange_identification: Połączenie zamknięte przez zdalny host

ssh-tunnel

— Jacob Ewing
źródło

Jedna przyczyna ssh_exchange_identification: Connection closed by remote hostbłędu dotyczy hosta łączącego się wymienionego w /etc/hosts.deny.

— Zoredache,

Hm - jeśli I cat /ets/hosts.deny na tej maszynie, każda linia jest zaznaczona.

— Jacob Ewing

Czy mogę zasugerować dodanie -vdo polecenia ssh, które się nie powiedzie? Czy wynikowe dane wyjściowe dają jakiekolwiek inne wskazanie awarii (tj channel 1: open failed: administratively prohibited: open failed.).

— kbulgrien

2

Niestety, przyszło mi do głowy, że warto mieć -vzarówno tunel, jak i nieudane polecenia ssh (szukając czegoś więcej niż channel 3: open failed: connect failed: Connection timed out). Warto wspomnieć, że można dodać wiele -v(do trzech) w celu zwiększenia gadatliwości. Niekoniecznie opublikowałbym całą wylewkę, ale warto zastanowić się nad słowami, które wydają się wskazywać na problem.

— kbulgrien

1

Może jeśli masz więcej niż 10 sesji ssh czekających na wstawienie hasła, masz tego rodzaju błąd, pamiętam, że to był ostatni błąd ssh, jeśli to zweryfikujesz, użyj polecenia poniżej

for i in {1..15};do ssh -fNt pippo@remote.server.com & >/dev/null ;done

— c4f4t0r
źródło

0

Coś takiego miało miejsce podczas ostatniej instalacji. W tej sytuacji /etc/hosts.deny istniał i nie miał żadnych ustawień, które jawnie odmawiały dostępu, więc okoliczności wydają się podobne. Konieczne było zmodyfikowanie /etc/hosts.allow, aby dodać coś takiego:

sshd: 192.168.127.0/255.255.255.128

Szczegóły adresu IP należy dostosować do własnych potrzeb lub zastąpić je, ALLjeśli nie ma obaw o zezwolenie na korzystanie z ssh z dowolnego miejsca.

Po dokonaniu zmian zatrzymaj i uruchom ponownie sshd.

Pozytywne odpowiedzi na następujące pytanie zawierają więcej przykładów.

SSH hosts.deny i hosts.allow

Oto świadectwo innej osoby, które łączy komunikat o błędzie z rozwiązaniem.

Jak naprawić: ssh_exchange_identification: Połączenie zamknięte przez problem hosta zdalnego podczas logowania za pomocą SSH

— kbulgrien
źródło

Hmm - niestety to mnie nie naprawiło. Myślę, że moja sytuacja różni się od tych z przykładu. Jestem w stanie bez problemu podłączyć się do portu 22. Tylko wtedy, gdy próbuję tunelować przez inny port, dostaję wspomniane błędy.

— Jacob Ewing

To prawda, że tunel jest charakterystyczną różnicą. Biorąc to pod uwagę, czy to pomaga: dyskusja.dreamhost.com/thread-97951.html ? Znalazłem również odniesienia do wskazania, że odinstalowanie i ponowne zainstalowanie pakietu sshd w systemach podobnych do Debiana rozwiązuje problem z kluczami, który powoduje opisane zachowanie ( dyskusja.dreamhost.com/thread-97951.html i in.) .

— kbulgrien 10.01.2013

Masz sshd (openssh-server) zainstalowany w obu systemach, prawda?

— kbulgrien

Yupyup. Robiłem to od dłuższego czasu i w zeszłym tygodniu miałem problemy tylko po przejściu na Debiana na moim komputerze domowym (serwerze). Wypróbuję twoją propozycję odinstalowania / ponownego zainstalowania sshd, kiedy wrócę dziś wieczorem do domu.

— Jacob Ewing

0

Miałem ten sam problem i ostatecznie rozwiązałem problem, poprawiając /etc/network/interfaces:

auto eth0
iface eth0 inet static

lub

auto eth0
iface eth0 inet dhcp

bez tej konfiguracji nigdy nie dostanę odwrotnego połączenia z moim tunelem ssh.

— dr4ck0
źródło

0

W moim przypadku musiałem wstawić do /etc/ssh/sshd_configmaszyny bramy następujące linie:

Match User <username>
   GatewayPorts yes

Zobacz więcej szczegółów tutaj

Mam nadzieję że to pomoże!

— floatingpurr
źródło