Forum Linux.debian/ubuntu Proxy socks ssh qui marche plus

Posté par Arathor le 17 septembre 2010 à 19:54.

Étiquettes :

sept.

2010

J'ai un problème bizarre avec ssh. À configuration identique, ça marche sur deux machines mais pas sur une troisième. Mieux : sur la troisième, ça c'est arrêté de marcher du jour au lendemain, apparemment sans raison.

Pour regarder des vidéos géolocalisées, je me sers d'un compte sur une machine debian lenny. J'ai rajouté dans /etc/ssh/sshd_config :
AllowTcpForwarding yes
Sur la machine cliente, je lance la commande suivante :
autossh -D 4444 -N machine_serveur
Ce qui ouvre un proxy socks sur la machine cliente à l'adresse localhost:4444. Le trafic passant par ce proxy sort par la machine serveur, via le tunnel ssh.

Ensuite il reste plus qu'à paramétrer firefox, pour qu'il passe par le proxy. Et tout marchait bien. Mais depuis quelques jours, subitement, ça ne marche plus. Désormais j'obtiens le message suivant quand je veux charger une page :
« Délai d'attente dépassé
Le serveur à l'adresse google.com met trop de temps à répondre. »

Et pourtant je n'avais rien changé. J'ai relancé autossh, rien. J'ai redémarré le sshd du serveur, rien. Je vérifie la config, tout semble normal. J'essaye avec ssh directement, rien. Je vérifie /var/log/aptitude, pas eu de mise à jour de ssh.

Je fais un test en mettant AllowTcpForwarding à yes sur deux autres machines, en lançant un proxy socks sur un autre port : ça marche. Grumpf. Y'a un truc évident qui m'échappe ou quoi ?

# firewall ?

Posté par ze_lionix (site web personnel) le 17 septembre 2010 à 20:16. Évalué à 4.

- Est ce que les 3 machines sont sur le même réseau ?
- As-tu la maîtrise du (des) firewall(s) du réseau où se trouve la machine qui t'embête ?

Parce que moi ça me fait penser à un blocage du ssh en sortant, pour éviter le tunelling...
Fuse : j'en Use et Abuse !
- [^] # Re: firewall ?
  
  Posté par Xaapyks le 18 septembre 2010 à 13:08. Évalué à 4.
  
  Déjà est-ce qu'un simple
  ssh machine_serveur
  
  passe ?
  
  Ce qui me vient à l'esprit : blocage liste d'utilisateur, Blocage par le réseau, ssh bloqué par tcp_wrappers.
  donc verfiie ta config sshd et /etc/hosts.allow , si tu peux pas gerer le firewall, passe par 443 : la solution ultime :D
  - [^] # Re: firewall ?
    
    Posté par Arathor le 19 septembre 2010 à 00:58. Évalué à 2.
    
    Déjà est-ce qu'un simple ssh machine_serveur passe ?
    
    Yep, ça marche.
    
    blocage liste d'utilisateur
    
    J'ai l'utilisateur listé dans AllowUsers.
    
    Blocage par le réseau
    
    Le firewall tu veux dire ? la configuration est bonne. De toutes façons, c'est la même config (ssh et firewall) sur la machine qui merde, et sur les deux où ça marche.
    
    ssh bloqué par tcp_wrappers.
    
    C'est-à-dire ?
    
    si tu peux pas gerer le firewall, passe par 443 : la solution ultime :D
    
    Je suis root sur la machine serveur. Le port ssh est bien ouvert.
- [^] # Re: firewall ?
  
  Posté par Arathor le 19 septembre 2010 à 00:51. Évalué à 3.
  
  - Est ce que les 3 machines sont sur le même réseau ?
  
  Nop
  
  - As-tu la maîtrise du (des) firewall(s) du réseau où se trouve la machine qui t'embête ?
  
  Oui. Mais la session ssh s'ouvre bien, c'est le proxy socks (l'option -D) qui ne marche pas. Firefox n'arrive pas à charger une page quand il passe par le proxy socks ouvert via cette machine. Si je choisis une autre machine comme sortie du proxy socks, ça marche.
  
  Parce que moi ça me fait penser à un blocage du ssh en sortant, pour éviter le tunelling...
  
  Le firewall n'a aucune règle en sortie, tout est en ACCEPT.
  - [^] # Re: firewall ?
    
    Posté par Ecran Plat (site web personnel, Mastodon) le 21 septembre 2010 à 10:02. Évalué à 1.
    
    t'as essayé depuis la machine ou ça marche pas de faire un wget www.lemonde.fr ?
    Histoire de voir si la machine de l'autre côté arrive a sortir sur le net
    - [^] # Re: firewall ?
      
      Posté par Arathor le 25 septembre 2010 à 01:56. Évalué à 2.
      
      Bien sûr, c'est l'une des premières choses que j'avais vérifié.
      
      Le problème est réglé, cf. https://linuxfr.org/comments/1165887.html#1165887
# Un peu plus de détails

Posté par Thibault (site web personnel) le 17 septembre 2010 à 20:23. Évalué à 2.

Salut,

Il faudrait un peu plus de détails. Tu peux lancer ton tunnel avec un petit -v (verbose) pour voir si déjà il te dit qu'il y a quelque chose qui coince. Tu peux vérifier également que le port 4444 est bien ouvert sur ton client.
Essaye aussi avec la commande ssh simple...
- [^] # Re: Un peu plus de détail
  
  Posté par Arathor le 19 septembre 2010 à 01:47. Évalué à 2.
  
  Tu peux vérifier également que le port 4444 est bien ouvert sur ton client.
  
  Quand la commande autossh est lancée :
  
  % nmap -p 4444 localhost Starting Nmap 4.62 ( http://nmap.org ) at 2010-09-18 23:10 CEST Interesting ports on localhost (127.0.0.1): PORT STATE SERVICE 4444/tcp open krb524
  Si je l'arrête, nmap me dit que le port est fermé. Donc pas de processus fantôme a priori.
  
  Essaye aussi avec la commande ssh simple...
  
  Déjà essayé, pas de différence.
  
  Tu peux lancer ton tunnel avec un petit -v (verbose) pour voir si déjà il te dit qu'il y a quelque chose qui coince.
  
  Ah ouais j'ai oublié de regarder avec l'option de debug (pourtant j'avais pensé à regarder les logs au cas où (rien dans syslog)).
  
  Avec juste -v pas de différence avec une machine où ça marche. Par contre avec -vvv, là y'a des trucs louches effectivement. Regarder surtout vers la fin, après la séquence d'initialisation (dans laquelle je vois rien de spécial, mais que je laisse pour un œil plus averti) quand je demande une page dans firefox et qu'il se produit un timeout.
  
  % script ssh -vvv -D 4444 -N machine_serveur OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 Oct 2007 debug1: Reading configuration data /home/XXX/.ssh/config debug1: Applying options for machine_serveur debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to machine_serveur [IP.IP.IP.IP] port PORT. debug1: Connection established. debug1: identity file /home/XXXX/.ssh/identity type -1 debug1: identity file /home/XXXX/.ssh/id_rsa type -1 debug3: Not a RSA1 key file /home/XXXX/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /home/XXXX/.ssh/id_dsa type 2 debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024 debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5 debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 125/256 debug2: bits set: 493/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: put_host_port: [IP.IP.IP.IP]:PORT debug3: put_host_port: [machine_serveur]:PORT debug3: check_host_in_hostfile: filename /home/XXXX/.ssh/known_hosts debug3: check_host_in_hostfile: match line 61 debug3: check_host_in_hostfile: filename /home/XXXX/.ssh/known_hosts debug3: check_host_in_hostfile: match line 62 debug1: Host '[machine_serveur]:PORT' is known and matches the RSA host key. debug1: Found key in /home/XXXX/.ssh/known_hosts:61 debug2: bits set: 505/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/XXXX/.ssh/identity ((nil)) debug2: key: /home/XXXX/.ssh/id_rsa ((nil)) debug2: key: /home/XXXX/.ssh/id_dsa (0xb7f069e8) debug1: Authentications that can continue: publickey debug3: start over, passed a different list publickey debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/XXXX/.ssh/identity debug3: no such identity: /home/XXXX/.ssh/identity debug1: Trying private key: /home/XXXX/.ssh/id_rsa debug3: no such identity: /home/XXXX/.ssh/id_rsa debug1: Offering public key: /home/XXXX/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-dss blen 434 debug2: input_userauth_pk_ok: fp 94:ec:48:38:7b:04:f6:05:4f:bd:30:90:21:e2:62:48 debug3: sign_and_send_pubkey debug1: read PEM private key done: type DSA debug1: Authentication succeeded (publickey). debug1: Local connections to LOCALHOST:4444 forwarded to remote address socks:0 debug3: channel_setup_fwd_listener: type 2 wildcard 0 addr NULL debug1: Local forwarding listening on 127.0.0.1 port 4444. debug2: fd 4 setting O_NONBLOCK debug3: fd 4 is O_NONBLOCK debug1: channel 0: new [port listener] debug1: Local forwarding listening on ::1 port 4444. debug2: fd 5 setting O_NONBLOCK debug3: fd 5 is O_NONBLOCK debug1: channel 1: new [port listener] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. [Fin des messages d'initialisation. Dans firefox je demande lemonde.fr] debug1: Connection to port 4444 forwarding to socks port 0 requested. debug2: fd 6 setting TCP_NODELAY debug2: fd 6 setting O_NONBLOCK debug3: fd 6 is O_NONBLOCK debug1: channel 2: new [dynamic-tcpip] debug2: channel 2: pre_dynamic: have 0 debug2: channel 2: pre_dynamic: have 3 debug2: channel 2: decode socks5 debug2: channel 2: socks5 auth done debug2: channel 2: pre_dynamic: need more debug2: channel 2: pre_dynamic: have 0 debug2: channel 2: pre_dynamic: have 5 debug2: channel 2: decode socks5 debug2: channel 2: socks5 post auth debug2: channel 2: pre_dynamic: need more debug2: channel 2: pre_dynamic: have 17 debug2: channel 2: decode socks5 debug2: channel 2: socks5 post auth debug2: channel 2: dynamic request: socks5 host lemonde.fr port 80 command 1 [À ce moment se produit un timeout d'environ 15s ] [Puis affichage du message d'erreur dans firefox, et la suite :] debug2: channel 2: open confirm rwindow 2097152 rmax 32768 debug2: channel 2: read<=0 rfd 6 len 0 debug2: channel 2: read failed debug2: channel 2: close_read debug2: channel 2: input open -> drain debug2: channel 2: ibuf empty debug2: channel 2: send eof debug2: channel 2: input drain -> closed debug2: channel 2: rcvd eof debug2: channel 2: output open -> drain debug2: channel 2: obuf empty debug2: channel 2: close_write debug2: channel 2: chan_shutdown_write: shutdown() failed for fd6: Transport endpoint is not connected debug2: channel 2: output drain -> closed debug2: channel 2: rcvd close debug3: channel 2: will not send data after close debug2: channel 2: send close debug2: channel 2: is dead debug2: channel 2: garbage collecting debug1: channel 2: free: direct-tcpip: listening port 4444 for lemonde.fr port 80, connect from 127.0.0.1 port 46956, nchannels 3 debug3: channel 2: status: The following connections are open: #2 direct-tcpip: listening port 4444 for lemonde.fr port 80, connect from 127.0.0.1 port 46956 (t4 r0 i3/0 o3/0 fd 6/6 cfd -1) debug3: channel 2: close_fds r 6 w 6 e -1 c -1
  M'en vais chercher « ssh proxy socks Transport endpoint is not connected » sur google, pour voir si ça peut m'aider.
  - [^] # Re: Un peu plus de détail
    
    Posté par Arathor le 19 septembre 2010 à 02:20. Évalué à 2.
    
    M'en vais chercher « ssh proxy socks Transport endpoint is not connected » sur google, pour voir si ça peut m'aider.
    Ben non, rien…
  - [^] # Re: Un peu plus de détail
    
    Posté par Thibault (site web personnel) le 19 septembre 2010 à 16:58. Évalué à 1.
    
    Tiens, juste comme ça, tu peux rajouter ceci dans ton /etc/hosts
    
    195.154.120.129 lemonde.fr www.lemonde.fr
    
    Et retester ?
    
    De mon côté j'ai quasiment les mêmes messages que toi, sauf que :
    
    debug2: channel 3: dynamic request: socks5 host 195.154.120.129 port 80 command 1
    debug2: channel 3: open confirm rwindow 2097152 rmax 32768
    
    Alors je me penche sur un problème de résolution dns (après c'est peut-être pas ça du tout).
    - [^] # Re: Un peu plus de détail
      
      Posté par Arathor le 25 septembre 2010 à 01:55. Évalué à 2.
      
      Alors en fait cette situation découlait d'un tout autre problème.
      
      J'ai deux cartes réseau sur ma machine. L'une était partie en carafe (/etc/init.d/networking restart donnait des messages bizarres). J'ai dû redémarrer la machine (super, on dirait windows).
      
      Du coup y'avait des problèmes avec le firewall, shorewall ne marchait plus. De l'extérieur, on ne pouvait plus pinguer ma machine et apache était injoignable. Et donc, le proxy socks de ssh déconnait.
      
      J'y comprends rien. Je comprends pas comment ça affectait ssh ni comment ça pouvait poser problème avec une seule machine distante, et pas les autres.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.