Forum Linux.debian/ubuntu problème connexion SSH

Posté par . Licence CC by-sa
Tags :
1
18
juil.
2017

bonsoir,

j'ai un problème pour me connecter en SSH sur un serveur (raspberry pi).

J'ai deux serveurs chez moi, l'un connecté en filaire (192.168.0.7), l'autre connecté en wifi (192.168.0.12).

J'ai une redirection de port sur ma box, genre 1512 sur le port 22 du 192.168.0.7 et 1513 sur le port 22 du 192.168.0.12

Si je me connecte en local, aucun problème pour accéder au 2 serveurs.

Si je me connecte à distance (testé de 2 endroits différents), je peux me connecter sur 192.168.0.7, mais pas sur 192.168.0.12. Sur ce dernier ça demande bien le mot de passe, ensuite ça reste bloqué sans rendre la main sur le shell à distance.

J'ai essayé en mode verbeux et j'obtiens :
ssh -vv nom@ip -p1513

debug1: Authentication succeeded (password).
Authenticated to ########### ([########]:1513).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768

et ça bloque là.

Encore une fois, depuis une IP locale, aucun problème de connexion.

Ça indique ensuite, en local :

debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0

Les 2 OS sont raspian, mais des version différentes (7 sur le premier, 8 sur celui qui a le problème). Les fichiers de config sur similaires sur les 2 versions.

Une idée d'investigation ?

  • # fichiers de log

    Posté par . Évalué à 3.

    tu peux regarder dans les fichiers de log /var/log/[auth.log|message|syslog]. Peut-être une information utile a extraire.

    • [^] # Re: fichiers de log

      Posté par . Évalué à 3.

      par ailleurs, il est préférable de forcer l'authentification par clé, sauf pour une liste d'adresse IP de confiance :

      # par défaut : pas d'auth par MDP, seulement par clé publique.
      PasswordAuthentication no
      PubkeyAuthentication yes
      
      # mes adresses IP : j'autorise l'authentification par MDP (et par clé)
      Match Address 1.2.3.4,192.168.0.0/24
        PasswordAuthentication yes
      
    • [^] # Re: fichiers de log

      Posté par . Évalué à 3. Dernière modification le 18/07/17 à 09:14.

      Oui, c'est pas bête.
      Pour autant, je ne vois rien de spécial, ça indique que la session s'est bien ouverte, et ce sont les mêmes log que quand je me connecte en local :

      Jul 18 06:45:37 ##### sshd[2878]: Accepted password for pi from ##### port ##### ssh2
      Jul 18 06:45:37 ##### sshd[2878]: pam_unix(sshd:session): session opened for user pi by (uid=0)
      Jul 18 06:45:37 ##### systemd-logind[340]: New session c3 of user pi.
      
      Jul 18 06:45:37 ##### systemd[2883]: Reached target Basic System.
      Jul 18 06:45:37 ##### systemd[2883]: Reached target Default.
      Jul 18 06:45:37 ##### systemd[2883]: Startup finished in 83ms.
      

      J'ai branché la prise ethernet, rajouté une redirection de port vers cette nouvelle IP, faut juste que je redémarre la box pour voir ce que ça donne, mais là je ne peux le faire à distance…

  • # MTU ?

    Posté par . Évalué à 5.

    Ce genre de comportement est typique d'un problème de MTU.

    J'ai eu le cas avec des serveurs dont le MTU était configuré à 9000 (site A) mais dont le lien inter-site était à 1500, ce qui fait qu'on ne parvenait pas à accéder aux serveurs de site B.

    La connexion se bloquait à un moment donné, alors pourtant que l'authentification se passait bien.

    En homogénéisant le MTU, tout s'est résolu.

    Dans ton cas, peut-être faut-il abaisser le MTU.

    Tu peux essayer plusieurs valeurs comme :

    1474, 1480 etc…

    Sinon le web regorge de solutions de ce type.

    Hope this helps.

    • [^] # Re: MTU ?

      Posté par . Évalué à 2.

      C'est pas bête comme idée.
      J'ai passé le MTU à 1468, et maintenant je peux me connecter.

      Seulement je suis repassé ensuite à 1500 (valeur d'origine, apparemment), et je peux encore me connecter.

      Je redémarre le raspberry pi, et ça ne se connecte plus, même en changeant le MTU…

Suivre le flux des commentaires

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