Forum Linux.debian/ubuntu problème connexion SSH

Posté par zurvan le 18 juillet 2017 à 00:09. Licence CC By‑SA.

Étiquettes :

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 Marc Quinton le 18 juillet 2017 à 07:07. É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 Marc Quinton le 18 juillet 2017 à 07:11. É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 zurvan le 18 juillet 2017 à 09:13. Évalué à 3. Dernière modification le 18 juillet 2017 à 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…
  
  « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# MTU ?

Posté par Dabowl_75 le 18 juillet 2017 à 12:19. É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 zurvan le 19 juillet 2017 à 23:46. É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…
  
  « Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher