tunnel ssh che rifiuta le connessioni con "canale 2: apertura fallita"

70

Improvvisamente (leggi: senza modificare alcun parametro) la mia macchina virtuale netbsd ha iniziato a comportarsi in modo strano. I sintomi riguardano il tunneling ssh.

Dal mio computer portatile lancio:

$ ssh -L 7000:localhost:7000 user@host -N -v

Quindi, in un'altra shell:

$ irssi -c localhost -p 7000

Il debug ssh dice:

debug1: Connection to port 7000 forwarding to localhost port 7000 requested.
debug1: channel 2: new [direct-tcpip]
channel 2: open failed: connect failed: Connection refused
debug1: channel 2: free: direct-tcpip: listening port 7000 for localhost port 7000, connect from 127.0.0.1 port 53954, nchannels 3

Ho provato anche con localhost: 80 per connettermi al server web (remoto), con risultati identici.

L'host remoto esegue NetBSD:

bash-4.2# uname -a
NetBSD host 5.1_STABLE NetBSD 5.1_STABLE (XEN3PAE_DOMU) #6: Fri Nov  4 16:56:31 MET 2011  root@youll-thank-me-later:/m/obj/m/src/sys/arch/i386/compile/XEN3PAE_DOMU i386

Mi sono perso un po '. Ho provato a correre tcpdumpsull'host remoto e ho notato questi "bad chksum":

09:25:55.823849 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 67, bad cksum 0 (->3cb3)!) 127.0.0.1.54381 > 127.0.0.1.7000: P, cksum 0xfe37 (incorrect (-> 0xa801), 1622402406:1622402421(15) ack 1635127887 win 4096 <nop,nop,timestamp 5002727 5002603>

Ho provato a riavviare il demone ssh senza alcun risultato. Non ho ancora riavviato - forse qualcuno qui può suggerire altri sistemi diagnostici. Penso che potrebbe essere o il driver della scheda di rete virtuale, o qualcuno ha radicato il nostro SSH.

Idee ..?

— lorenzog
fonte

1

Per la risoluzione dei problemi, provare $ ssh -L 7000:127.0.0.1:7000 user@host -N -v -v. (Puoi usare "-v" fino a 3 volte per aumentare la verbosità.) Inoltre, è possibile che ssh sia stato aggiornato di recente?

— Mike Sherrill 'Cat Recall',

Il log di output che ho incollato era già stato raccolto con -v.

— Lorenzog

1

Puoi usare -v fino a tre volte per aumentare la verbosità. Quindi potresti guardare l'output di ssh -L 7000... -N -v -v(due v) o ssh -L 7000... -N -v -v -v.

— Mike Sherrill 'Cat Recall'

@ MikeSherrill'CatRecall 'È possibile utilizzare anche una scorciatoia: -vvv

— jnns

42

Problema risolto:

$ ssh -L 7000:127.0.0.1:7000 user@host -N -v -v

... apparentemente, ' host locale ' non è piaciuto all'host remoto. Tuttavia, il telecomando /etc/hostscontiene:

::1                     localhost localhost.
127.0.0.1               localhost localhost.

mentre l'interfaccia di rete locale è

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33184
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2

Sospiro. così tanto per la taglia di 100rp che ho messo :)

— lorenzog
fonte

1

Ah. Bene, allora, non mi preoccuperò di scrivere il mio commento come risposta. (Cerca se ssh preferisce gli indirizzi ipv6 sul tuo sistema.)

— Mike Sherrill 'Cat Recall'

Bene, hai suggerito di raddoppiare l'opzione -v, ma questo non ha mostrato nulla di nuovo .. tuttavia, facendomi rivedere l'output dopo alcuni giorni mi ha aiutato a individuare il problema. Se vuoi scrivere la risposta, sono più che felice di darti la grazia.

— Lorenzog,

1

In realtà, il punto importante era sostituire "localhost" con "127.0.0.1". Gli argomenti "-v" aggiuntivi potrebbero essere stati utili, ma non erano quelli a cui stavo mirando. Grazie.

— Mike Sherrill 'Cat Recall'

secondo quel post su superutente: superuser.com/questions/346971/ssh-tunnel-connection-refused un programma configurato per ascoltare su un indirizzo specifico ascolterà quell'indirizzo specifico

— jopasserat

1

Per me l'aggiunta del comando ":" funziona in modo che il comando nel tuo caso sia simile al seguente: ssh -L: 7000: 127.0.0.1: 7000 user @ host -N -v -v

— valentt

21

Sebbene il problema di OP sia già stato risolto, ho deciso di condividere la soluzione per il mio problema, perché ho ricevuto lo stesso messaggio di errore da ssh e non ho trovato alcuna soluzione su altri siti.

Nel mio caso ho dovuto connettermi al servizio che ascolta solo su IPv6. Provai:

ssh -f root@192.168.0.18 -L 51005: 127.0.0.1: 51005 -N
ssh -f root@192.168.0.18 -L 51005: localhost: 51005 -N

e alcuni altri modi, ma non ha funzionato. Qualsiasi tentativo di connessione http://localhost:51005causa errori come questo: channel 2: open failed: connect failed: Connection refused

La soluzione è:

ssh -f root@192.168.0.18 -L 51005: [:: 1]: 51005 -N

L'indirizzo IPv6 deve essere tra parentesi quadre.

— rzymek
fonte

1

Cosa succede se si utilizza un file di configurazione ssh? esempio: "LocalForward localhost: 64160 192.168.1.56:3389"

— meffect

Per me l'aggiunta del comando ":" funziona così il comando nel tuo caso sarebbe simile al seguente: ssh -f root@192.168.0.18 -L: 51005: 127.0.0.1: 51005 -N

— valentt

9

Prima proverei questo.

$ ssh -L 7000:127.0.0.1:7000 user@host -N -v -v

Puoi usare "-v" fino a 3 volte per aumentare la verbosità.

Penso che questo messaggio di errore possa sorgere se un firewall blocca la porta 7000, ma l'hai già escluso. (Se i lettori successivi non lo hanno escluso, guarda l'output di netstat --numeric-ports.)

Io penso che avrei potuto vedere questo messaggio di errore molto tempo fa, quando ssh è venuto a conoscenza di indirizzi IPv6 a seguito di un aggiornamento. Potrei sbagliarmi al riguardo. Se hai voglia di sperimentare, puoi provare l'indirizzo di loopback IPV6 "0: 0: 0: 0: 0: 0: 0: 1" (o ":: 1").

— Mike Sherrill 'Cat Recall'
fonte

3

"... apparentemente," localhost "non è piaciuto all'host remoto. Tuttavia, remote / etc / hosts contiene:"

Tranne che stavi eseguendo ssh sul client, quindi 'localhost' non è piaciuto al tuo client. Il file remoto / etc / hosts è per i collegamento a distanza fuori non in arrivo le connessioni.

— baggins bilbo
fonte

1

anche questo mi confondeva. Quando si digita localhost nella macchina locale, viene risolto localmente

— Ahmedov

3

Ho riscontrato questo stesso errore durante il tentativo di connettermi a mysql su un altro server tramite un tunnel SSH. Ho scoperto che il parametro bind-address in /etc/my.cnf sul server di destinazione era associato al mio ip esterno (doppio server NIC) piuttosto che interno, per il quale non avevo alcuna utilità.

Quando ho impostato bind-address = 127.0.0.1, ho potuto usare con successo il mio tunnel ssh come segue:

ssh -N -f -L 3307:127.0.0.1:3306 user@server.name

mysql -h 127.0.0.1 --port=3307 --protocol=TCP -uusername -ppassword

— Tom McQuarrie
fonte

Ha funzionato anche per me. Puoi associare MySQL a un solo indirizzo.

— leeand00,

3

Ho riscontrato questo errore durante l'inoltro delle porte con un nome di dominio completo anziché localhost:

ssh -L 5900:host.name.com:5900 x11vnc

La porta veniva aperta solo per localhost, quindi per accettare connessioni con un nome completo, ho dovuto aggiungere una descrizione della porta vincolante :

ssh -L *:5900:host.name.com:5900 x11vnc

che consentirebbe connessioni da qualsiasi luogo (quindi non è così sicuro, usalo con parsimonia).

— cengique
fonte

2

Per me l'aggiunta di ":" funziona così il comando nel tuo caso sarebbe simile a questo:

ssh -L :7000:localhost:7000 user@host -N -v

— valentt
fonte

È passato troppo tempo e non posso tornare indietro e controllare, ma sembra fantastico.

— Lorenzog,

1

???

canale 2: apertura non riuscita: connessione non riuscita: connessione rifiutata

Alla user@hostporta di ascolto 7000 non c'è nulla, è semplice e basta.

— poige
fonte

1

Non è vero. Esiste un servizio in esecuzione sull'host: 7000. Ho anche provato con altri servizi.

— Lorenzog

2

No, quindi si bloccherebbe semplicemente la connessione.

— Ricky,

4

@RickyA: In realtà, non è vero. Se la porta non è vincolata, la connessione verrà rifiutata. Ho ricevuto questo errore dall'uso della porta interna errata (dove nessun servizio era in esecuzione), l'errore è scomparso quando ho corretto l'errore. poige ha ragione nel dire che se nulla sta ascoltando sulla porta, causerà l'errore.

— ERB

1

Ho ricevuto lo stesso messaggio di errore:

canale 3: apertura non riuscita: connessione non riuscita: connessione rifiutata

E la causa è stata un errore umano: il tentativo di accedere a una porta diversa sull'host remoto rispetto a quello specificato.

Ho pensato che lo condividerò, anche se questo probabilmente non è il motivo per cui molti di voi stanno riscontrando questo errore.

— Roei Bahumi
fonte

Nel mio caso: questo è esattamente quello che stavo facendo. Un errore così stupido ma ci è voluta questa risposta per farmi controllare il porto. Doh.

— Ken Sharp,

1

Per me, stavo provando ssh -L <port>:<remote server IP>:<port> <login>@<remote server IP>quando avrei dovuto farlo ssh -L <port>:127.0.0.1:<port> <login>@<remote server IP>.

Spero che questo aiuti qualcuno!

— ryanwc
fonte

1

L'interpretazione alternativa è, nel mio caso, la digitazione errata.

user@host ~ $ ssh -vvvNL 4444:127.0.0.0.1:4444
...
channel 2: open failed: connect failed: Name or service not known

Quello che succede qui è che l'indirizzo IP ha troppi zeri, quindi non è un indirizzo valido. Quindi ssh lo considera come un nome di dominio invece che non può essere risolto. Oops!

PS: lo complemento, quindi abbiamo un elenco completo di possibili problemi durante la risoluzione degli stessi sintomi.

— Hincor
fonte