Git n'arrive pas à contacter certains sites IPv6 en SSH.

Le
Charles Plessy
Bonjour Í  tous,

j'ai Í  nouveau la fibre. Et en IPv6 en plus. Mais Git n'arrive plus Í 
contacter des sites distants en SSH.

Curieusement, les sessions SSH interactives ont l'air de s'établir
normalement. Example:

$ ssh -6 git@salsa.debian.org
PTY allocation request failed on channel 1
Welcome to GitLab, @plessy!
Connection to salsa.debian.org closed.

(C'est la réponse attendue).

Par contre:

$ git clone --verbose git@salsa.debian.org:med-team/perlprimer.git
Clonage dans 'perlprimer'

… et ensuite plus rien.

Si je désactive IPv6 pour les connections SSH dans ~/.ssh/config:

Host *
AddressFamily inet

Tout rentre dans l'ordre. Mais ce n'est pas satisfaisant :)

Le problème n'est pas spécifique au réseau Debian; j'ai la même chose
avec branchable.com et gitlab.com. Par contre, ça fonctionne avec
GitHub

Quelqu'un aurait-il une piste ?

Charles

--
Charles Plessy
Nagahama, Yomitan, Okinawa, Japon
  • Partager ce contenu :
Vos réponses
Trier par : date / pertinence
̓‰tienne Mollier
Le #26559582
--FCuugMFkClbJLl1L
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Bonjour Charles,
Charles Plessy, on 2020-11-13 05:22:08 +0900:
j'ai ̓  nouveau la fibre. Et en IPv6 en plus. Mais Git n'arrive plus ̓ 
contacter des sites distants en SSH.
Curieusement, les sessions SSH interactives ont l'air de s'̓©tablir
normalement. Example:
$ ssh -6
PTY allocation request failed on channel 1
Welcome to GitLab, @plessy!
Connection to salsa.debian.org closed.
(C'est la r̓©ponse attendue).
Par contre:
$ git clone --verbose :med-team/perlprimer.git
Clonage dans 'perlprimer'...
Í¢€¦ et ensuite plus rien.

Je n'ai pas rencontr̓© de probl̓¨mes de mon c̓´t̓©. En grattant un
peu, la variable d'environnement GIT_SSH_COMMAND peut ̓ªtre
exploit̓©e pour augmenter le verbiage de ssh:
$ export GIT_SSH_COMMAND='ssh -vvv'
$ git clone :med-team/perlprimer.git
Peut-̓ªtre qu'il en sortira quelque chose d'int̓©ressant ?
Si je d̓©sactive IPv6 pour les connections SSH dans ~/.ssh/config:
Host *
AddressFamily inet
Tout rentre dans l'ordre. Mais ce n'est pas satisfaisant :)
Le probl̓¨me n'est pas sp̓©cifique au r̓©seau Debian; j'ai la m̓ªme chose
avec branchable.com et gitlab.com. Par contre, ̓§a fonctionne avec
GitHub...

De mon point de vue, Github n'est pas accessible en IPv6, ou du
moins, n'en fait pas la publicit̓© :
$ host github.com
github.com has address 140.82.113.3
github.com mail is handled by 10 alt3.aspmx.l.google.com.
github.com mail is handled by 10 alt4.aspmx.l.google.com.
github.com mail is handled by 1 aspmx.l.google.com.
github.com mail is handled by 5 alt1.aspmx.l.google.com.
github.com mail is handled by 5 alt2.aspmx.l.google.com.
Ceci pourrait expliquer cela...
Bonne journ̓©e, :)
--
̓‰tienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
Sent from /dev/pts/7, please excuse my verbosity.
--FCuugMFkClbJLl1L
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEj5GyJ8fW8rGUjII2eTz2fo8NEdoFAl+toDoACgkQeTz2fo8N
EdqqjBAAh1afAHotM1M4906zmkh/8sO8n/Q9wZNetvZ8l1eaJp5U9BxgiMfKgqNr
u3rmOa9crilCxTWR0suH9zIcyDbJNH3vhnMoeePHt0ZO4+QtA1bs+Ga871X+at1l
GKhbiRyxQPmPIZj58YGlusbBtA6cP4Pvj6cH+WDdD2Bp1jtW6zRhREZJVvJhcCkv
vXmfYhY8MGCY4zb4h6+mXjBli1jOJaVSerk+s79mRBzhQo+V0fsIhw5pz+ckpSy/
QRBOSRO5bEJaMXlaFDTpmNHaUsE2yZuyxxrdpzixflECqfRUNgPQvNlMLpRsl+wv
/bWHQdRNqgzBLXIjmpsLdyOZcu75Ri6iOt5TZ0qvrK8HWvhorRj7sCihOGFR3VUe
VI3YHWloeP1jmfc7YoHvbaNpnF1LRHMvu78hlmh8zG2b/9ElMIR0va1yXWo1KOjh
funs9gN+PGpBcAaYpIZ/ugdBFpeEOBxbE2jnKvAMVaMXq1t7NCxbrnJqu8IUIJ1F
cQXZF6y3OwHIQzw+iz8odh46r2bZnlhJPM1zjyDDXX0FDrRjCz/+pbTOBNnVvwlY
0OEcgIappYZuA9iM3bJxMu13a/UMOs+YSA0st7xSFnQ/QJ4ybyYyIA/HO2YbhWhT
cUNNYkP4j4eQTJUMB/TEVyq8hxvDuzK2P140Wt1LQdSPVHo/H0U=vv+5
-----END PGP SIGNATURE-----
--FCuugMFkClbJLl1L--
NoSpam
Le #26559632
Bonjour
Le 12/11/2020 Í  21:22, Charles Plessy a écrit :
Bonjour Í  tous,
j'ai Í  nouveau la fibre. Et en IPv6 en plus. Mais Git n'arrive plus Í 
contacter des sites distants en SSH.
Curieusement, les sessions SSH interactives ont l'air de s'établir
normalement. Example:
$ ssh -6
PTY allocation request failed on channel 1
Welcome to GitLab, @plessy!
Connection to salsa.debian.org closed.
(C'est la réponse attendue).
Par contre:
$ git clone --verbose :med-team/perlprimer.git
Clonage dans 'perlprimer'...
… et ensuite plus rien.
Si je désactive IPv6 pour les connections SSH dans ~/.ssh/config:
Host *
AddressFamily inet
Tout rentre dans l'ordre. Mais ce n'est pas satisfaisant :)
Le problème n'est pas spécifique au réseau Debian; j'ai la même chose
avec branchable.com et gitlab.com. Par contre, ça fonctionne avec
GitHub...
Quelqu'un aurait-il une piste ?

Essaye avec une MTU a 1492
--
Daniel
Fabien R
Le #26559773
On 12/11/2020 21:51, Étienne Mollier wrote:
De mon point de vue, Github n'est pas accessible en IPv6, ou du
moins, n'en fait pas la publicité :
$ host github.com
github.com has address 140.82.113.3
github.com mail is handled by 10 alt3.aspmx.l.google.com.
github.com mail is handled by 10 alt4.aspmx.l.google.com.
github.com mail is handled by 1 aspmx.l.google.com.
github.com mail is handled by 5 alt1.aspmx.l.google.com.
github.com mail is handled by 5 alt2.aspmx.l.google.com.
Ceci pourrait expliquer cela...

J'ai également constaté que dig ne renvoyait aucune donnée AAAA.
--
Fabien
Charles Plessy
Le #26559775
Le Thu, Nov 12, 2020 at 09:51:06PM +0100, Étienne Mollier a écrit :
Je n'ai pas rencontré de problèmes de mon cÍ´té. En grattant un
peu, la variable d'environnement GIT_SSH_COMMAND peut être
exploitée pour augmenter le verbiage de ssh:
$ export GIT_SSH_COMMAND='ssh -vvv'
$ git clone :med-team/perlprimer.git

Merci du tuyau, ça bloque Í :
debug1: Sending command: git-upload-pack 'med-team/perlprimer.git'
debug2: channel 1: request exec confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 1: callback done
debug2: channel 1: open confirm rwindow 0 rmax 32768
Google ou DuckDuckGo ne révèlent rien concernant "git-upload-pack"
"ipv6" "freeze"
(Je n'ai pas encore testé le changement de MTU; je ne sais pas comment
le faire sure une interface wifi gérée par GNOME...)
(Je n'ai pas testé non plus la version 2.29; je suis en 2.27)
Bon week-end !
--
Charles
NoSpam
Le #26559816
Bonjour
Le 14/11/2020 Í  10:23, Charles Plessy a écrit :
[...]
(Je n'ai pas encore testé le changement de MTU; je ne sais pas comment
le faire sure une interface wifi gérée par GNOME...)

en ligne de commande: sudo ip link set mtu 1492 dev <nom d'interface>
--
Daniel
̓‰tienne Mollier
Le #26559838
--CGDBiGfvSTbxKZlW
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Bonjour Charles,
Charles Plessy, on 2020-11-14 18:23:21 +0900:
Le Thu, Nov 12, 2020 at 09:51:06PM +0100, ̓‰tienne Mollier a ̓©crit :
$ export GIT_SSH_COMMAND='ssh -vvv'
$ git clone :med-team/perlprimer.git

Merci du tuyau, ̓§a bloque ̓ :
debug1: Sending command: git-upload-pack 'med-team/perlprimer.git'
debug2: channel 1: request exec confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 1: callback done
debug2: channel 1: open confirm rwindow 0 rmax 32768
Google ou DuckDuckGo ne r̓©v̓¨lent rien concernant "git-upload-pack"
"ipv6" "freeze"

Je s̓¨che. C'est vrai que c'est curieux. On est loin dans
l'ex̓©cution de la commande `git clone` : la connexion SSH est
d̓©j̓  ̓©tablie, et les cl̓©s sont ̓©chang̓©es depuis bien longtemps.
Chez moi, la connexion se poursuit comme suit:
debug1: Sending command: git-upload-pack 'med-team/perlprimer.git'
debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
remote: Enumerating objects: 660, done.
remote: Counting objects: 100% (660/660), done.
remote: Compressing objects: 100% (299/299), done.
Soit la commande "git-upload-pack 'med-team/perlprimer.git'"
ne d̓©marre pas du c̓´t̓© de Salsa, soit elle n'arrive pas ̓ 
utiliser la liaison existante avec votre machine pour renvoyer
la confirmation (paquet type 99).
(Je n'ai pas encore test̓© le changement de MTU; je ne sais pas comment
le faire sure une interface wifi g̓©r̓©e par GNOME...)

La suggestion de Daniel "NoSpam" avec "ip" me semble ̓  explorer.
J'ai des souvenirs d'̓©cole comme quoi IPv6 ne fragmente pas
comme IPv4, et du coup un MTU trop gros peut potentiellement
bloquer si la route se d̓©grade en cours de connexion (je ne suis
pas sp̓©cialiste en r̓©seau, et le souvenir en question date d'il
y a dix ans, donc je peux dire des b̓ªtises).
(Je n'ai pas test̓© non plus la version 2.29; je suis en 2.27)

J'ai test̓© rapidement avec Git 2.20 de Buster, mais je n'ai pas
observ̓© plus de blocages, sinon effectivement, mon test ̓©tait
avec Git 2.29.
Bon week-end !

Merci, ̓  vous de m̓ªme, :)
--
̓‰tienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
Sent from /dev/pts/1, please excuse my verbosity.
--CGDBiGfvSTbxKZlW
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEj5GyJ8fW8rGUjII2eTz2fo8NEdoFAl+wCooACgkQeTz2fo8N
EdpYmQ//YNMhiFG+VS1rFPlzvZNnJw4A2OO5L7b+OJVRJyuITqH3XK7xKpODi7Ks
5PT7VVQ0bnvboMz8902Bm7YuQqaOY8Tne+WLdW6JDrkrBMUDg4ls5/xt4anBD8g8
bxCwWmh40AYhiVZhQPkbeoL1+R8uNYJSdhEZwtw3yJ9MSpQPlEd0bVJYIKBTnxHE
hTenVSB5RyzIOObnyhM66D/VHB1K0jN7ZxA8/7y6oC3nvyt+ipwWbFj+X6hc3ocp
emhIxYpecJEoXpBSMSaGJs8M+Kfs9HLTisNznk5U5BptMe1VKfD0ft1C5nUgxtgv
hS4VSB+wnZ0U9WaBy9O7TiN17A9dDy9Lu8ng18hVodHPxcMrzzmjPKUt0qIAi0K/
e7vlgO6Wg0s7IJXvZ6zB9nQGGyeKCoxNuCW16ZohlFpWfjUpeYcTOYPlBGudoH9m
agZYx03U4r1E1f1/zRF23spvUV+iCsQquPLdfWw/QUgz1NGJSEzVNvHythvEy3e2
niWDupoETQbLpx+4rJvPdXd75XWXYpQFNA7p1n6zPlxXrsao0bQ7lJmxmouJ/REb
PNE/U4urpsABToxGa9xEF792a19KRrloxu2ghjRCckzgSYo9wDQ7xbHs7L1KwmR+
dltYzjTukddv9/PTrscOfPLlexgWFoYdkb5w8dxkqC6evenC9fA=V9gQ
-----END PGP SIGNATURE-----
--CGDBiGfvSTbxKZlW--
Poster une réponse
Anonyme