Tout à coup (lire: sans changer aucun paramètre), ma machine virtuelle netbsd a commencé à agir étrangement. Les symptômes concernent ssh tunneling.
Depuis mon ordinateur portable je lance:
$ ssh -L 7000:localhost:7000 user@host -N -v
Ensuite, dans un autre shell:
$ irssi -c localhost -p 7000
Le débogage ssh dit:
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
J'ai aussi essayé avec localhost: 80 de me connecter au serveur Web (distant), avec des résultats identiques.
L’hôte distant exécute 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
Je suis un peu perdu. J'ai essayé de courir tcpdumpsur l'hôte distant, et j'ai repéré ces '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>
J'ai essayé de redémarrer le démon ssh en vain. Je n'ai pas encore redémarré - peut-être que quelqu'un ici peut suggérer d'autres diagnostics. Je pense que cela peut être soit le pilote de la carte réseau virtuelle, ou quelqu'un qui a enraciné notre ssh.
Des idées ..?
networking
ssh
connection
netbsd
lorenzog
la source
la source
$ ssh -L 7000:127.0.0.1:7000 user@host -N -v -v. (Vous pouvez utiliser "-v" jusqu'à 3 fois pour augmenter la verbosité.) Aussi, est-il possible que ssh ait été récemment mis à jour?ssh -L 7000... -N -v -v(deux v) oussh -L 7000... -N -v -v -v.Réponses:
Problème résolu:
... apparemment, l'hôte distant n'aime pas « localhost ». Pourtant, la télécommande
/etc/hostscontient:tandis que l'interface du réseau local est
Soupir. tant pis pour la prime de 100 rp que j'ai mise :)
la source
Bien que le problème d'OP ait déjà été résolu, j'ai décidé de partager la solution à mon problème, car j'ai reçu le même message d'erreur de ssh et je n'ai trouvé aucune solution sur d'autres sites.
Dans mon cas, je devais me connecter au service qui n'écoute que sur IPv6. J'ai essayé:
et quelques autres moyens mais cela n'a pas fonctionné. Toute tentative de connexion
http://localhost:51005entraîne des erreurs comme celle-ci:channel 2: open failed: connect failed: Connection refusedLa solution est:
L'adresse IPv6 doit être entre crochets.
la source
Je voudrais d'abord essayer ceci.
Vous pouvez utiliser "-v" jusqu'à 3 fois pour augmenter la verbosité.
Je pense que ce message d'erreur peut survenir si un pare-feu bloque le port 7000, mais vous l'aviez déjà décidé. (Si les lecteurs ultérieurs ne l'ont pas exclu, regardez le résultat de
netstat --numeric-ports.)Je pense que j'ai peut-être vu ce message d'erreur il y a longtemps, lorsque ssh a découvert pour la première fois les adresses IPV6 à la suite d'une mise à jour. Je peux me tromper à ce sujet. Si vous avez envie d'expérimenter, vous pouvez essayer l'adresse de bouclage IPV6 "0: 0: 0: 0: 0: 0: 0: 1" (ou ":: 1").
la source
"... apparemment, l'hôte distant n'aime pas 'localhost'. Pourtant, le fichier / etc / hosts distant contient:"
Sauf que vous utilisiez ssh sur le client, votre client n'aimait donc pas 'localhost'. Le fichier / etc / hosts distant est destiné à la connexion distante , pas aux connexions entrantes .
la source
J'ai rencontré cette même erreur en essayant de se connecter à mysql sur un autre serveur via un tunnel ssh. J'ai constaté que le paramètre bind-address dans /etc/my.cnf sur le serveur cible était lié à mon adresse IP externe (serveur à deux cartes réseau) plutôt qu'à interne, ce qui ne m'était d'aucune utilité.
Lorsque j'ai défini bind-address = 127.0.0.1, je pouvais utiliser mon tunnel ssh comme suit:
la source
J'ai rencontré cette erreur lorsque je transmettais des ports avec un nom de domaine complet au lieu de localhost:
Le port était ouvert uniquement pour localhost. Pour accepter des connexions avec un nom complet, je devais donc ajouter une description du port de liaison :
ce qui permettrait des connexions de n'importe où (donc ce n'est pas si sûr, utilisez-le avec parcimonie).
la source
Pour moi, ajouter le préfixe ":" fonctionne si bien que la commande dans votre cas ressemblerait à ceci:
la source
???
Sur
user@hostle port d’écoute 7000, rien de plus simple.la source
J'ai reçu le même message d'erreur:
Et la cause était une erreur humaine - moi essayant d'accéder à un port différent sur l'hôte distant que celui que j'ai spécifié.
Je pensais que je partagerais cela, bien que ce ne soit probablement pas la raison pour laquelle la plupart d’entre vous rencontrez cette erreur.
la source
Pour moi, j'essayais
ssh -L <port>:<remote server IP>:<port> <login>@<remote server IP>quand j'aurais dû le fairessh -L <port>:127.0.0.1:<port> <login>@<remote server IP>.J'espère que ça aidera quelqu'un!
la source
Une interprétation alternative est, dans mon cas, votre frappe est incorrecte.
Qu'est-ce qui se passe ici est que l'adresse IP a un trop de zéros, donc pas une adresse valide. Donc ssh le traite plutôt comme un nom de domaine qu’il ne peut pas résoudre. Oops!
PS: Je complète ceci afin que nous ayons une liste complète des problèmes possibles lors du dépannage des mêmes symptômes.
la source