J'ai chang=C3=A9 de FAI hier, =C3=A7a n'a probablement rien =C3=A0 voir mai=
s y'a quand
m=C3=AAme un truc louche cot=C3=A9 r=C3=A9seau [1].
Quelques heures plus tard, mon PC s'est fig=C3=A9 (image fixe, plus de clav=
ier
ni de souris), et les logs kernel sont curieux, on dirait une mise en
veille [2].=20
Pas moyen de le red=C3=A9marrer au bouton en fa=C3=A7ade (ventilos mais pas=
l'image
habituelle du bios qui pr=C3=A9c=C3=A8de grub, =C3=A9crans noirs), il a fal=
lu couper
l'alim et red=C3=A9marrer. Au red=C3=A9marrage, j'ai comme l'impression que=
le bios
s'est remis avec ses r=C3=A9glages par d=C3=A9faut car il m'a affich=C3=A9 =
l'image du
constructeur au d=C3=A9but du d=C3=A9marrage (que j'avais pas avant).
J'ai boss=C3=A9 qq heures, puis en r=C3=A9digeant ce mail j'ai voulu faire =
un lshw
pour filer plus d'infos et il s'est de nouveau fig=C3=A9, mais sans rien ra=
conter=20
dans les logs (plantage 10 =C3=A0 20s apr=C3=A8s le lancement de `lshw -sho=
rt`, je=20
viens de relancer la commande qui r=C3=A9pond en 1~2s).
C'est une debian stretch classique, avec un 4.9.0-4-amd64, sur un vieux
coucou qui devrait f=C3=AAter bient=C3=B4t ses 10 ans, mais vu qu'il me suf=
fit pour
mon taf quotidien je pensais pas le changer tout de suite :-/
C'est un cpu intel Q9550 avec une CM Asus P5QL PRO, et
network AR8121/AR8113/AR8114 Gigabit or Fast Ethernet
display GF119 [GeForce GT 610]
Une piste ?
[1] Pb github
Apr=C3=A8s changement de box fibre et avoir r=C3=A9cup=C3=A9r=C3=A9 du r=C3=
=A9seau (en laissant
le dhcp g=C3=A9rer le fait que la connexion =C3=A9tait revenue), tout fonct=
ionnait
bien sauf github :
- git clone https://github=E2=80=A6 OK
- git clone git@github.com=E2=80=A6 KO
- commandes git sur mes d=C3=A9p=C3=B4ts locaux avec un remote sur github HS
- commandes git sur mes d=C3=A9p=C3=B4ts locaux avec un autre remote OK
- github.com via un navigateur est chaotique (coupures tcp sur la plupart d=
es
requ=C3=AAtes, login difficile, coupure syst=C3=A9matique sur les sockets=
http)
- depuis mon PC portable qui utilise la m=C3=AAme box en wifi tout =C3=A7a =
fonctionne
normalement
Apr=C3=A8s 2h =C3=A0 chercher, tent=C3=A9 un reboot, =C3=A7a n'a logiquemen=
t rien chang=C3=A9.
Modifier l'adresse mac de ma carte r=C3=A9seau non plus.
[2] logs kernel
Apr 4 03:25:43 quad kernel: [10946.508298] PM: Syncing filesystems ... don=
e.
Apr 4 03:25:43 quad kernel: [10946.524369] PM: Preparing system for sleep =
(mem)
Apr 4 03:25:43 quad kernel: [10946.524561] Freezing user space processes .=
.. (elapsed 0.002 seconds) done.
Apr 4 03:25:43 quad kernel: [10946.526759] Freezing remaining freezable ta=
sks ... (elapsed 0.001 seconds) done.
Apr 4 03:25:43 quad kernel: [10946.527954] PM: Suspending system (mem)
Apr 4 03:25:43 quad kernel: [10946.527988] Suspending console(s) (use no_c=
onsole_suspend to debug)
Apr 4 03:25:43 quad kernel: [10946.531763] serial 00:06: disabled
Apr 4 03:25:43 quad kernel: [10946.531769] serial 00:06: System wakeup dis=
abled by ACPI
Apr 4 03:25:43 quad kernel: [10946.532036] sd 2:0:0:0: [sda] Synchronizing=
SCSI cache
Apr 4 03:25:43 quad kernel: [10946.532056] sd 2:0:1:0: [sdb] Synchronizing=
SCSI cache
Apr 4 03:25:43 quad kernel: [10946.532668] nouveau 0000:01:00.0: DRM: susp=
ending console...
Apr 4 03:25:43 quad kernel: [10946.532672] nouveau 0000:01:00.0: DRM: susp=
ending display...
Apr 4 03:25:43 quad kernel: [10946.532730] nouveau 0000:01:00.0: DRM: evic=
ting buffers...
Apr 4 03:25:43 quad kernel: [10946.535273] sd 2:0:0:0: [sda] Stopping disk
Apr 4 03:25:43 quad kernel: [10946.535417] sd 2:0:1:0: [sdb] Stopping disk
Apr 4 03:25:43 quad kernel: [10947.677212] nouveau 0000:01:00.0: DRM: wait=
ing for kernel channels to go idle...
Apr 4 03:25:43 quad kernel: [10947.677253] nouveau 0000:01:00.0: DRM: susp=
ending client object trees...
Apr 4 03:25:43 quad kernel: [10947.677759] nouveau 0000:01:00.0: DRM: susp=
ending kernel object tree...
Apr 4 03:25:43 quad kernel: [10949.368231] PM: suspend of devices complete=
after 2839.975 msecs
Apr 4 03:25:43 quad kernel: [10949.368725] PM: late suspend of devices com=
plete after 0.492 msecs
Apr 4 03:25:43 quad kernel: [10949.369073] ehci-pci 0000:00:1d.7: System w=
akeup enabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.369107] uhci_hcd 0000:00:1d.2: System w=
akeup enabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.369146] uhci_hcd 0000:00:1d.1: System w=
akeup enabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.369183] uhci_hcd 0000:00:1d.0: System w=
akeup enabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.369357] ehci-pci 0000:00:1a.7: System w=
akeup enabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.369358] uhci_hcd 0000:00:1a.2: System w=
akeup enabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.369411] uhci_hcd 0000:00:1a.1: System w=
akeup enabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.369426] uhci_hcd 0000:00:1a.0: System w=
akeup enabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.388047] PM: noirq suspend of devices co=
mplete after 19.319 msecs
Apr 4 03:25:43 quad kernel: [10949.388862] ACPI: Preparing to enter system=
sleep state S3
Apr 4 03:25:43 quad kernel: [10949.389127] PM: Saving platform NVS memory
Apr 4 03:25:43 quad kernel: [10949.389361] Disabling non-boot CPUs ...
Apr 4 03:25:43 quad kernel: [10949.389640] Broke affinity for irq 16
Apr 4 03:25:43 quad kernel: [10949.389643] Broke affinity for irq 18
Apr 4 03:25:43 quad kernel: [10949.389647] Broke affinity for irq 19
Apr 4 03:25:43 quad kernel: [10949.390662] smpboot: CPU 1 is now offline
Apr 4 03:25:43 quad kernel: [10949.405114] Broke affinity for irq 16
Apr 4 03:25:43 quad kernel: [10949.405118] Broke affinity for irq 18
Apr 4 03:25:43 quad kernel: [10949.405121] Broke affinity for irq 19
Apr 4 03:25:43 quad kernel: [10949.406139] smpboot: CPU 2 is now offline
Apr 4 03:25:43 quad kernel: [10949.428756] Broke affinity for irq 16
Apr 4 03:25:43 quad kernel: [10949.428761] Broke affinity for irq 18
Apr 4 03:25:43 quad kernel: [10949.428764] Broke affinity for irq 19
Apr 4 03:25:43 quad kernel: [10949.429780] smpboot: CPU 3 is now offline
Apr 4 03:25:43 quad kernel: [10949.448219] ACPI: Low-level resume complete
Apr 4 03:25:43 quad kernel: [10949.448219] PM: Restoring platform NVS memo=
ry
Apr 4 03:25:43 quad kernel: [10949.448219] Suspended for 23415.025 seconds
Apr 4 03:25:43 quad kernel: [10949.448219] Enabling non-boot CPUs ...
Apr 4 03:25:43 quad kernel: [10949.460236] x86: Booting SMP configuration:
Apr 4 03:25:43 quad kernel: [10949.460237] smpboot: Booting Node 0 Process=
or 1 APIC 0x1
Apr 4 03:25:43 quad kernel: [10949.463266] cache: parent cpu1 should not =
be sleeping
Apr 4 03:25:43 quad kernel: [10949.463676] CPU1 is up
Apr 4 03:25:43 quad kernel: [10949.476270] smpboot: Booting Node 0 Process=
or 2 APIC 0x2
Apr 4 03:25:43 quad kernel: [10949.479317] cache: parent cpu2 should not =
be sleeping
Apr 4 03:25:43 quad kernel: [10949.479756] CPU2 is up
Apr 4 03:25:43 quad kernel: [10949.492300] smpboot: Booting Node 0 Process=
or 3 APIC 0x3
Apr 4 03:25:43 quad kernel: [10949.495346] cache: parent cpu3 should not =
be sleeping
Apr 4 03:25:43 quad kernel: [10949.495913] CPU3 is up
Apr 4 03:25:43 quad kernel: [10949.503132] ACPI: Waking up from system sle=
ep state S3
Apr 4 03:25:43 quad kernel: [10949.503632] uhci_hcd 0000:00:1a.0: System w=
akeup disabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.503677] uhci_hcd 0000:00:1a.1: System w=
akeup disabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.503721] uhci_hcd 0000:00:1a.2: System w=
akeup disabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.503888] uhci_hcd 0000:00:1d.0: System w=
akeup disabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.503907] uhci_hcd 0000:00:1d.1: System w=
akeup disabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.503936] uhci_hcd 0000:00:1d.2: System w=
akeup disabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.520143] ehci-pci 0000:00:1d.7: System w=
akeup disabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.520250] ehci-pci 0000:00:1a.7: System w=
akeup disabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.524140] PM: noirq resume of devices com=
plete after 20.638 msecs
Apr 4 03:25:43 quad kernel: [10949.524570] PM: early resume of devices com=
plete after 0.405 msecs
Apr 4 03:25:43 quad kernel: [10949.524616] usb usb3: root hub lost power o=
r was reset
Apr 4 03:25:43 quad kernel: [10949.524648] usb usb4: root hub lost power o=
r was reset
Apr 4 03:25:43 quad kernel: [10949.524678] usb usb5: root hub lost power o=
r was reset
Apr 4 03:25:43 quad kernel: [10949.524821] usb usb6: root hub lost power o=
r was reset
Apr 4 03:25:43 quad kernel: [10949.524823] usb usb7: root hub lost power o=
r was reset
Apr 4 03:25:43 quad kernel: [10949.524859] usb usb8: root hub lost power o=
r was reset
Apr 4 03:25:43 quad kernel: [10949.524881] nouveau 0000:01:00.0: DRM: resu=
ming kernel object tree...
Apr 4 03:25:43 quad kernel: [10949.525045] rtc_cmos 00:01: System wakeup d=
isabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.525905] serial 00:06: activated
Apr 4 03:25:43 quad kernel: [10949.526788] i8042: No controller found
Apr 4 03:25:43 quad kernel: [10949.526793] dpm_run_callback(): platform_pm=
_resume+0x0/0x40 returns -19
Apr 4 03:25:43 quad kernel: [10949.526795] PM: Device i8042 failed to resu=
me: error -19
Apr 4 03:25:43 quad kernel: [10949.527415] sd 2:0:0:0: [sda] Starting disk
Apr 4 03:25:43 quad kernel: [10949.527441] sd 2:0:1:0: [sdb] Starting disk
Apr 4 03:25:43 quad kernel: [10949.691717] ata1.00: configured for UDMA/33
Apr 4 03:25:43 quad kernel: [10949.726166] nouveau 0000:01:00.0: DRM: resu=
ming client object trees...
Apr 4 03:25:43 quad kernel: [10949.726473] nouveau 0000:01:00.0: DRM: resu=
ming display...
Apr 4 03:25:43 quad kernel: [10949.764011] usb 1-1: reset high-speed USB d=
evice number 2 using ehci-pci
Apr 4 03:25:43 quad kernel: [10949.831657] nouveau 0000:01:00.0: DRM: resu=
ming console...
Apr 4 03:25:43 quad kernel: [10949.852703] ata6: SATA link down (SStatus 0=
SControl 300)
Apr 4 03:25:43 quad kernel: [10949.863288] ata5: SATA link down (SStatus 0=
SControl 300)
Apr 4 03:25:43 quad kernel: [10950.020025] usb 8-1: reset low-speed USB de=
vice number 2 using uhci_hcd
Apr 4 03:25:43 quad kernel: [10950.164789] ata4.00: SATA link down (SStatu=
s 0 SControl 300)
Apr 4 03:25:43 quad kernel: [10950.164800] ata4.01: SATA link down (SStatu=
s 0 SControl 300)
Apr 4 03:25:43 quad kernel: [10950.812023] usb 8-2: reset low-speed USB de=
vice number 3 using uhci_hcd
Apr 4 03:25:43 quad kernel: [10951.143131] PM: resume of devices complete =
after 1618.557 msecs
Apr 4 03:25:43 quad kernel: [10951.655081] PM: Finishing wakeup.
Apr 4 03:25:43 quad kernel: [10951.655082] Restarting tasks ... done.
Apr 4 03:25:44 quad kernel: [10952.684177] i8042: Can't write CTR while cl=
osing KBD port
Apr 4 03:25:45 quad kernel: [10953.195904] i8042: Can't reactivate KBD port
Apr 4 03:25:46 quad kernel: [10954.730859] i8042: Can't write CTR while cl=
osing AUX port
Apr 4 03:25:47 quad kernel: [10955.242606] i8042: Can't reactivate AUX port
Apr 4 03:25:47 quad kernel: [10955.756376] ata3.00: link is slow to respon=
d, please be patient (ready=3D0)
Apr 4 03:25:48 quad kernel: [10956.265912] i8042: Can't write CTR while cl=
osing AUX port
Apr 4 03:25:48 quad kernel: [10956.777557] i8042: Can't reactivate AUX port
Apr 4 03:25:49 quad kernel: [10958.168058] ata3.00: SATA link up 3.0 Gbps =
(SStatus 123 SControl 300)
Apr 4 03:25:49 quad kernel: [10958.168069] ata3.01: SATA link up 3.0 Gbps =
(SStatus 123 SControl 300)
Apr 4 03:25:49 quad kernel: [10958.170368] ata3.01: ACPI cmd ef/03:45:00:0=
0:00:b0 (SET FEATURES) filtered out
Apr 4 03:25:49 quad kernel: [10958.170371] ata3.01: ACPI cmd ef/03:0c:00:0=
0:00:b0 (SET FEATURES) filtered out
Apr 4 03:25:49 quad kernel: [10958.364702] ata3.01: ACPI cmd c6/00:10:00:0=
0:00:b0 (SET MULTIPLE MODE) succeeded
Apr 4 03:25:49 quad kernel: [10958.364704] ata3.01: ACPI cmd f5/00:00:00:0=
0:00:00 (SECURITY FREEZE LOCK) filtered out
Apr 4 03:25:49 quad kernel: [10958.369384] ata3.00: ACPI cmd ef/03:45:00:0=
0:00:a0 (SET FEATURES) filtered out
Apr 4 03:25:49 quad kernel: [10958.369386] ata3.00: ACPI cmd ef/03:0c:00:0=
0:00:a0 (SET FEATURES) filtered out
Apr 4 03:25:49 quad kernel: [10958.369452] ata3.00: ACPI cmd c6/00:10:00:0=
0:00:a0 (SET MULTIPLE MODE) succeeded
Apr 4 03:25:49 quad kernel: [10958.369455] ata3.00: ACPI cmd f5/00:00:00:0=
0:00:00 (SECURITY FREEZE LOCK) filtered out
Apr 4 03:25:49 quad kernel: [10958.371788] ata3.00: supports DRM functions=
and may not be fully accessible
Apr 4 03:25:49 quad kernel: [10958.377501] ata3.00: supports DRM functions=
and may not be fully accessible
Apr 4 03:25:49 quad kernel: [10958.380793] ata3.00: configured for UDMA/133
Apr 4 03:25:49 quad kernel: [10958.383291] ata3.01: configured for UDMA/133
Apr 4 03:25:49 quad kernel: [10958.441362] ata3.00: Enabling discard_zeroe=
s_data
Apr 4 03:25:50 quad kernel: [10958.556420] ata3.00: Enabling discard_zeroe=
s_data
Apr 4 03:25:50 quad kernel: [10958.626025] IPv6: ADDRCONF(NETDEV_UP): eth1=
: link is not ready
Apr 4 03:25:50 quad kernel: [10958.664130] IPv6: ADDRCONF(NETDEV_UP): eth1=
: link is not ready
Apr 4 03:25:52 quad kernel: [10961.338324] ATL1E 0000:02:00.0 eth1: NIC Li=
nk is Up <1000 Mbps Full Duplex>
Apr 4 03:25:52 quad kernel: [10961.338339] IPv6: ADDRCONF(NETDEV_CHANGE): =
eth1: link becomes ready
Apr 4 03:25:52 quad kernel: [10961.368834] IPv6: ADDRCONF(NETDEV_UP): eth1=
: link is not ready
Apr 4 03:25:52 quad kernel: [10961.369000] ATL1E 0000:02:00.0 eth1: NIC Li=
nk is Up <1000 Mbps Full Duplex>
Apr 4 03:25:52 quad kernel: [10961.369013] IPv6: ADDRCONF(NETDEV_CHANGE): =
eth1: link becomes ready
(ensuite c'est le boot)
--=20
Daniel
L'id=C3=A9e d'une arm=C3=A9e europ=C3=A9enne est vraiment int=C3=A9ressante,
mais pourquoi ne pas aller plus loin en cr=C3=A9ant une arm=C3=A9e
mondiale dont le principal int=C3=A9r=C3=AAt serait qu'elle n'aurait=20
pas d'ennemis.
Philippe Geluck, Le chat
Le 10/04/18 à 15:43, BERTRAND Joël a écrit : BJ> Je ne sais pas sur quoi agit l'option -4 (hormis le fait BJ> s'utiliser IPv4 pour la connexion). Mais je puis t'assurer que même BJ> interrogés en IPv4, certains DNS renvoient des résolutions IP v6 et BJ> c'est au soft de faire le tri dans les réponses. Mais encore une f ois, BJ> je ne sais pas si ssh est assez subtil pour cela. Je pense quand même que même si la requête dns lui renvoyait du AAAA, il n'utiliserait que les champs A pour se connecter. BJ> Peux-tu poster ici un dump réseau complet de quelque chose qui BJ> fonctionne et d'une transaction qui échoue ? Par complet, c'est av ec les BJ> options -v et -e. Avec git on ne peut pas activer -e La même commande env GIT_SSH_COMMAND="ssh -4 -v -o Ciphers®s256-ctr" git pull sur le dépôt qui plante (1) et un qui fonctionne (à conditio n d'imposer le cipher) (2) Pour info, je viens de réinstaller une stretch toute fraîche, pen sant que mes pbs divers étaient peut-être liés à de vieux r ésidus, des modules plus utiles, etc. (car c'est un PC qui a presque 10 ans et je me rappelle pas avoir fait de réinstall from scratch, donc il pouvait avoir des re stes qui remontent à etch, et j'avais déjà eu des pbs d'hibernati on avec lenny ou squeeze de mémoire), mais ça ne change absolument rien :-/ 1) dépôt HS OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017 debug1: Reading configuration data /home/daniel/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to github.com [192.30.253.112] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u3 debug1: Remote protocol version 2.0, remote software version libssh_0.7.0 debug1: no match: libssh_0.7.0 debug1: Authenticating to github.com:22 as 'git' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compressi on: none debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compressi on: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ssh-rsa SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLvi Kw6E5SY8 debug1: Host 'github.com' is known and matches the RSA host key. debug1: Found key in /home/daniel/.ssh/known_hosts:596 debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: debug1: Authentications that can continue: publickey debug1: Offering RSA public key: debug1: Authentications that can continue: publickey debug1: Offering RSA public key: debug1: Authentications that can continue: publickey debug1: Offering RSA public key: debug1: Server accepts key: pkalg ssh-rsa blen 279 debug1: Authentication succeeded (publickey). Authenticated to github.com ([192.30.253.112]:22). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: pledge: network debug1: Sending environment. debug1: Sending env LANG = fr_FR.UTF-8 debug1: Sending command: git-upload-pack 'sesamath/sesalab.git' debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Connection to github.com closed by remote host. Transferred: sent 12336, received 73736 bytes, in 1.0 seconds Bytes per second: sent 12674.8, received 75761.3 debug1: Exit status -1 fatal: The remote end hung up unexpectedly 2) Dépôt qui marche à condition de préciser un cipher a es OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017 debug1: Reading configuration data /home/daniel/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to github.com [192.30.253.112] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u3 debug1: Remote protocol version 2.0, remote software version libssh_0.7.0 debug1: no match: libssh_0.7.0 debug1: Authenticating to github.com:22 as 'git' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compressi on: none debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compressi on: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ssh-rsa SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLvi Kw6E5SY8 debug1: Host 'github.com' is known and matches the RSA host key. debug1: Found key in /home/daniel/.ssh/known_hosts:596 debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: debug1: Authentications that can continue: publickey debug1: Offering RSA public key: debug1: Authentications that can continue: publickey debug1: Offering RSA public key: debug1: Authentications that can continue: publickey debug1: Offering RSA public key: debug1: Server accepts key: pkalg ssh-rsa blen 279 debug1: Authentication succeeded (publickey). Authenticated to github.com ([192.30.253.112]:22). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: pledge: network debug1: Sending environment. debug1: Sending env LANG = fr_FR.UTF-8 debug1: Sending command: git-upload-pack 'sesamath/sesatheque.git' debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Transferred: sent 3632, received 15832 bytes, in 0.8 seconds Bytes per second: sent 4600.2, received 20052.6 debug1: Exit status 0 Déjà à jour. -- Daniel
Le 10/04/18 à 15:43, BERTRAND Joël <joel.bertrand@systella.fr> a écrit :
BJ> Je ne sais pas sur quoi agit l'option -4 (hormis le fait
BJ> s'utiliser IPv4 pour la connexion). Mais je puis t'assurer que même
BJ> interrogés en IPv4, certains DNS renvoient des résolutions IP v6 et
BJ> c'est au soft de faire le tri dans les réponses. Mais encore une f ois,
BJ> je ne sais pas si ssh est assez subtil pour cela.
Je pense quand même que même si la requête dns lui renvoyait du AAAA, il
n'utiliserait que les champs A pour se connecter.
BJ> Peux-tu poster ici un dump réseau complet de quelque chose qui
BJ> fonctionne et d'une transaction qui échoue ? Par complet, c'est av ec les
BJ> options -v et -e.
Avec git on ne peut pas activer -e
La même commande
env GIT_SSH_COMMAND="ssh -4 -v -o Ciphers=aes256-ctr" git pull
sur le dépôt qui plante (1) et un qui fonctionne (à conditio n d'imposer
le cipher) (2)
Pour info, je viens de réinstaller une stretch toute fraîche, pen sant
que mes pbs divers étaient peut-être liés à de vieux r ésidus, des modules
plus utiles, etc. (car c'est un PC qui a presque 10 ans et je me rappelle
pas avoir fait de réinstall from scratch, donc il pouvait avoir des re stes
qui remontent à etch, et j'avais déjà eu des pbs d'hibernati on avec lenny
ou squeeze de mémoire), mais ça ne change absolument rien :-/
1) dépôt HS
OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017
debug1: Reading configuration data /home/daniel/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to github.com [192.30.253.112] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u3
debug1: Remote protocol version 2.0, remote software version libssh_0.7.0
debug1: no match: libssh_0.7.0
debug1: Authenticating to github.com:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compressi on: none
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compressi on: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLvi Kw6E5SY8
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /home/daniel/.ssh/known_hosts:596
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: root@asus17
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: root@quad
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: daniel@lairdutemps.org
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: daniel.caillibaud@sesamath.net
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to github.com ([192.30.253.112]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
debug1: Sending command: git-upload-pack 'sesamath/sesalab.git'
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Connection to github.com closed by remote host.
Transferred: sent 12336, received 73736 bytes, in 1.0 seconds
Bytes per second: sent 12674.8, received 75761.3
debug1: Exit status -1
fatal: The remote end hung up unexpectedly
2) Dépôt qui marche à condition de préciser un cipher a es
OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017
debug1: Reading configuration data /home/daniel/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to github.com [192.30.253.112] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u3
debug1: Remote protocol version 2.0, remote software version libssh_0.7.0
debug1: no match: libssh_0.7.0
debug1: Authenticating to github.com:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compressi on: none
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compressi on: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLvi Kw6E5SY8
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /home/daniel/.ssh/known_hosts:596
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: root@asus17
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: root@quad
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: daniel@lairdutemps.org
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: daniel.caillibaud@sesamath.net
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to github.com ([192.30.253.112]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
debug1: Sending command: git-upload-pack 'sesamath/sesatheque.git'
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 3632, received 15832 bytes, in 0.8 seconds
Bytes per second: sent 4600.2, received 20052.6
debug1: Exit status 0
Déjà à jour.
Le 10/04/18 à 15:43, BERTRAND Joël a écrit : BJ> Je ne sais pas sur quoi agit l'option -4 (hormis le fait BJ> s'utiliser IPv4 pour la connexion). Mais je puis t'assurer que même BJ> interrogés en IPv4, certains DNS renvoient des résolutions IP v6 et BJ> c'est au soft de faire le tri dans les réponses. Mais encore une f ois, BJ> je ne sais pas si ssh est assez subtil pour cela. Je pense quand même que même si la requête dns lui renvoyait du AAAA, il n'utiliserait que les champs A pour se connecter. BJ> Peux-tu poster ici un dump réseau complet de quelque chose qui BJ> fonctionne et d'une transaction qui échoue ? Par complet, c'est av ec les BJ> options -v et -e. Avec git on ne peut pas activer -e La même commande env GIT_SSH_COMMAND="ssh -4 -v -o Ciphers®s256-ctr" git pull sur le dépôt qui plante (1) et un qui fonctionne (à conditio n d'imposer le cipher) (2) Pour info, je viens de réinstaller une stretch toute fraîche, pen sant que mes pbs divers étaient peut-être liés à de vieux r ésidus, des modules plus utiles, etc. (car c'est un PC qui a presque 10 ans et je me rappelle pas avoir fait de réinstall from scratch, donc il pouvait avoir des re stes qui remontent à etch, et j'avais déjà eu des pbs d'hibernati on avec lenny ou squeeze de mémoire), mais ça ne change absolument rien :-/ 1) dépôt HS OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017 debug1: Reading configuration data /home/daniel/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to github.com [192.30.253.112] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u3 debug1: Remote protocol version 2.0, remote software version libssh_0.7.0 debug1: no match: libssh_0.7.0 debug1: Authenticating to github.com:22 as 'git' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compressi on: none debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compressi on: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ssh-rsa SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLvi Kw6E5SY8 debug1: Host 'github.com' is known and matches the RSA host key. debug1: Found key in /home/daniel/.ssh/known_hosts:596 debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: debug1: Authentications that can continue: publickey debug1: Offering RSA public key: debug1: Authentications that can continue: publickey debug1: Offering RSA public key: debug1: Authentications that can continue: publickey debug1: Offering RSA public key: debug1: Server accepts key: pkalg ssh-rsa blen 279 debug1: Authentication succeeded (publickey). Authenticated to github.com ([192.30.253.112]:22). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: pledge: network debug1: Sending environment. debug1: Sending env LANG = fr_FR.UTF-8 debug1: Sending command: git-upload-pack 'sesamath/sesalab.git' debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Connection to github.com closed by remote host. Transferred: sent 12336, received 73736 bytes, in 1.0 seconds Bytes per second: sent 12674.8, received 75761.3 debug1: Exit status -1 fatal: The remote end hung up unexpectedly 2) Dépôt qui marche à condition de préciser un cipher a es OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l 25 May 2017 debug1: Reading configuration data /home/daniel/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to github.com [192.30.253.112] port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/daniel/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u3 debug1: Remote protocol version 2.0, remote software version libssh_0.7.0 debug1: no match: libssh_0.7.0 debug1: Authenticating to github.com:22 as 'git' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compressi on: none debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compressi on: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ssh-rsa SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLvi Kw6E5SY8 debug1: Host 'github.com' is known and matches the RSA host key. debug1: Found key in /home/daniel/.ssh/known_hosts:596 debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 4294967296 blocks debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: debug1: Authentications that can continue: publickey debug1: Offering RSA public key: debug1: Authentications that can continue: publickey debug1: Offering RSA public key: debug1: Authentications that can continue: publickey debug1: Offering RSA public key: debug1: Server accepts key: pkalg ssh-rsa blen 279 debug1: Authentication succeeded (publickey). Authenticated to github.com ([192.30.253.112]:22). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: pledge: network debug1: Sending environment. debug1: Sending env LANG = fr_FR.UTF-8 debug1: Sending command: git-upload-pack 'sesamath/sesatheque.git' debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Transferred: sent 3632, received 15832 bytes, in 0.8 seconds Bytes per second: sent 4600.2, received 20052.6 debug1: Exit status 0 Déjà à jour. -- Daniel
Daniel Caillibaud
Le 10/04/18 à 23:12, BERTRAND Joël a écrit : BJ> Daniel Caillibaud a écrit : BJ> > Le 10/04/18 à 15:43, BERTRAND Joël fr> a BJ> > écrit : BJ> > BJ> Je ne sais pas sur quoi agit l'option -4 (hormis le fait BJ> > BJ> s'utiliser IPv4 pour la connexion). Mais je puis t'assurer que BJ> > BJ> même interrogés en IPv4, certains DNS renvoient des r ésolutions BJ> > BJ> IPv6 et c'est au soft de faire le tri dans les réponses. Mais BJ> > BJ> encore une fois, je ne sais pas si ssh est assez subtil pour BJ> > BJ> cela. BJ> > BJ> > Je pense quand même que même si la requête dns lui ren voyait du AAAA, BJ> > il n'utiliserait que les champs A pour se connecter. BJ> > BJ> > BJ> Peux-tu poster ici un dump réseau complet de quelque BJ> > BJ> chose qui fonctionne et d'une transaction qui échoue ? Par BJ> > BJ> complet, c'est avec les options -v et -e. BJ> > BJ> > Avec git on ne peut pas activer -e BJ> BJ> Je pensais à un tcpdump bien senti. J'avais mis un résumé dans un mail précédent (04/04/18 à 08:35), pour la totale c'est là - connexion git+ssh qui foire https://framadrop.org/r/V20FQ0lVJQ#hUYB/LRdm74/ytm+wl4LllfHIYrIq0QdMsoD Y/az4jA= - connexions du browser qui déconnent aussi https://framadrop.org/r/iLXjIVEK69#xiJSfmU3WB7bDZWvO9WUJAqHz5t5lvYyJvdv AEOdRT4= BJ> > La même commande BJ> > env GIT_SSH_COMMAND="ssh -4 -v -o Ciphers®s256-ctr" git pull BJ> > sur le dépôt qui plante (1) et un qui fonctionne (à co ndition BJ> > d'imposer le cipher) (2) BJ> BJ> Rhohh... Idée ! J'ai eu un truc similaire avec les concetés BJ> debianesques. Il y a des chiffrements qui ont disparu de certaines BJ> versions récentes d'OpenSSL qui m'empêchaient d'envoyer des m ails à BJ> certains (gros) domaines. Il m'a fallu patcher sendmail pour contourner BJ> le problème !... BJ> BJ> Peux-tu compiler un OpenSSL officiel (non patché par Debian) ? Pas la peine, le pb ne peut pas venir de là car - en imposant le cipher, on voit que le handshake ssh se passe bien donc ils ont trouvé un cipher commun - ça fonctionne bien depuis mon portable, qui est aussi sous stretch, avec le même ssh/openssl/clé ssh (et la même connexion, j'ai m ême été jusqu'à lui coller même mac, en utilisant le même cable RJ45 sur le m ême port de la même box) => le pb vient donc de la gestion du réseau par mon desktop vs lapto p. Vu que les deux ont la même debian, reste - le driver de la carte réseau, et je comprends vraiment pas comment ça peut influer sur des échanges chiffrés (à priori lui n'agi t que sur la couche réseau, pas applicative). - le (dé)chiffrement AES par le cpu Y'a moyen de changer des paramètres du kernel pour modifier la gestion AES du cpu ? Vous voyez une autre piste ? BJ> Si c'est bien ce à quoi je pense, il faudrait que des gens qui BJ> ne comprennent pas les implications de leurs patches arrêtent de l es BJ> imposer... Sur la suppression de certains ciphers d'openssl, c'est un choix délib éré je suppose, interdire les connexions qui paraissent sécurisées ma is ne le sont pas car utilisant des ciphers vulnérables. C'est le choix de firefox & chrome par ex, ils refusent désormais les connexions https vers des sites qui ne font pas de TLS ou utilisent des ciphers trop faibles. -- Daniel Le philosophe cherche des solutions aux problèmes et ne trouve que des problèmes sans solutions. Sim
Le 10/04/18 à 23:12, BERTRAND Joël <joel.bertrand@systella.fr> a écrit :
BJ> Daniel Caillibaud a écrit :
BJ> > Le 10/04/18 à 15:43, BERTRAND Joël <joel.bertrand@systella. fr> a
BJ> > écrit :
BJ> > BJ> Je ne sais pas sur quoi agit l'option -4 (hormis le fait
BJ> > BJ> s'utiliser IPv4 pour la connexion). Mais je puis t'assurer que
BJ> > BJ> même interrogés en IPv4, certains DNS renvoient des r ésolutions
BJ> > BJ> IPv6 et c'est au soft de faire le tri dans les réponses. Mais
BJ> > BJ> encore une fois, je ne sais pas si ssh est assez subtil pour
BJ> > BJ> cela.
BJ> >
BJ> > Je pense quand même que même si la requête dns lui ren voyait du AAAA,
BJ> > il n'utiliserait que les champs A pour se connecter.
BJ> >
BJ> > BJ> Peux-tu poster ici un dump réseau complet de quelque
BJ> > BJ> chose qui fonctionne et d'une transaction qui échoue ? Par
BJ> > BJ> complet, c'est avec les options -v et -e.
BJ> >
BJ> > Avec git on ne peut pas activer -e
BJ>
BJ> Je pensais à un tcpdump bien senti.
J'avais mis un résumé dans un mail précédent (04/04/18 à 08:35), pour la
totale c'est là
- connexion git+ssh qui foire
https://framadrop.org/r/V20FQ0lVJQ#hUYB/LRdm74/ytm+wl4LllfHIYrIq0QdMsoD Y/az4jA=
- connexions du browser qui déconnent aussi
https://framadrop.org/r/iLXjIVEK69#xiJSfmU3WB7bDZWvO9WUJAqHz5t5lvYyJvdv AEOdRT4=
BJ> > La même commande
BJ> > env GIT_SSH_COMMAND="ssh -4 -v -o Ciphers=aes256-ctr" git pull
BJ> > sur le dépôt qui plante (1) et un qui fonctionne (à co ndition
BJ> > d'imposer le cipher) (2)
BJ>
BJ> Rhohh... Idée ! J'ai eu un truc similaire avec les concetés
BJ> debianesques. Il y a des chiffrements qui ont disparu de certaines
BJ> versions récentes d'OpenSSL qui m'empêchaient d'envoyer des m ails à
BJ> certains (gros) domaines. Il m'a fallu patcher sendmail pour contourner
BJ> le problème !...
BJ>
BJ> Peux-tu compiler un OpenSSL officiel (non patché par Debian) ?
Pas la peine, le pb ne peut pas venir de là car
- en imposant le cipher, on voit que le handshake ssh se passe bien donc
ils ont trouvé un cipher commun
- ça fonctionne bien depuis mon portable, qui est aussi sous stretch, avec
le même ssh/openssl/clé ssh (et la même connexion, j'ai m ême été jusqu'à
lui coller même mac, en utilisant le même cable RJ45 sur le m ême port de
la même box)
=> le pb vient donc de la gestion du réseau par mon desktop vs lapto p. Vu
que les deux ont la même debian, reste
- le driver de la carte réseau, et je comprends vraiment pas comment ça
peut influer sur des échanges chiffrés (à priori lui n'agi t que sur la
couche réseau, pas applicative).
- le (dé)chiffrement AES par le cpu
Y'a moyen de changer des paramètres du kernel pour modifier la gestion AES
du cpu ?
Vous voyez une autre piste ?
BJ> Si c'est bien ce à quoi je pense, il faudrait que des gens qui
BJ> ne comprennent pas les implications de leurs patches arrêtent de l es
BJ> imposer...
Sur la suppression de certains ciphers d'openssl, c'est un choix délib éré
je suppose, interdire les connexions qui paraissent sécurisées ma is ne le
sont pas car utilisant des ciphers vulnérables.
C'est le choix de firefox & chrome par ex, ils refusent désormais les
connexions https vers des sites qui ne font pas de TLS ou utilisent des
ciphers trop faibles.
--
Daniel
Le philosophe cherche des solutions aux problèmes et
ne trouve que des problèmes sans solutions.
Sim
Le 10/04/18 à 23:12, BERTRAND Joël a écrit : BJ> Daniel Caillibaud a écrit : BJ> > Le 10/04/18 à 15:43, BERTRAND Joël fr> a BJ> > écrit : BJ> > BJ> Je ne sais pas sur quoi agit l'option -4 (hormis le fait BJ> > BJ> s'utiliser IPv4 pour la connexion). Mais je puis t'assurer que BJ> > BJ> même interrogés en IPv4, certains DNS renvoient des r ésolutions BJ> > BJ> IPv6 et c'est au soft de faire le tri dans les réponses. Mais BJ> > BJ> encore une fois, je ne sais pas si ssh est assez subtil pour BJ> > BJ> cela. BJ> > BJ> > Je pense quand même que même si la requête dns lui ren voyait du AAAA, BJ> > il n'utiliserait que les champs A pour se connecter. BJ> > BJ> > BJ> Peux-tu poster ici un dump réseau complet de quelque BJ> > BJ> chose qui fonctionne et d'une transaction qui échoue ? Par BJ> > BJ> complet, c'est avec les options -v et -e. BJ> > BJ> > Avec git on ne peut pas activer -e BJ> BJ> Je pensais à un tcpdump bien senti. J'avais mis un résumé dans un mail précédent (04/04/18 à 08:35), pour la totale c'est là - connexion git+ssh qui foire https://framadrop.org/r/V20FQ0lVJQ#hUYB/LRdm74/ytm+wl4LllfHIYrIq0QdMsoD Y/az4jA= - connexions du browser qui déconnent aussi https://framadrop.org/r/iLXjIVEK69#xiJSfmU3WB7bDZWvO9WUJAqHz5t5lvYyJvdv AEOdRT4= BJ> > La même commande BJ> > env GIT_SSH_COMMAND="ssh -4 -v -o Ciphers®s256-ctr" git pull BJ> > sur le dépôt qui plante (1) et un qui fonctionne (à co ndition BJ> > d'imposer le cipher) (2) BJ> BJ> Rhohh... Idée ! J'ai eu un truc similaire avec les concetés BJ> debianesques. Il y a des chiffrements qui ont disparu de certaines BJ> versions récentes d'OpenSSL qui m'empêchaient d'envoyer des m ails à BJ> certains (gros) domaines. Il m'a fallu patcher sendmail pour contourner BJ> le problème !... BJ> BJ> Peux-tu compiler un OpenSSL officiel (non patché par Debian) ? Pas la peine, le pb ne peut pas venir de là car - en imposant le cipher, on voit que le handshake ssh se passe bien donc ils ont trouvé un cipher commun - ça fonctionne bien depuis mon portable, qui est aussi sous stretch, avec le même ssh/openssl/clé ssh (et la même connexion, j'ai m ême été jusqu'à lui coller même mac, en utilisant le même cable RJ45 sur le m ême port de la même box) => le pb vient donc de la gestion du réseau par mon desktop vs lapto p. Vu que les deux ont la même debian, reste - le driver de la carte réseau, et je comprends vraiment pas comment ça peut influer sur des échanges chiffrés (à priori lui n'agi t que sur la couche réseau, pas applicative). - le (dé)chiffrement AES par le cpu Y'a moyen de changer des paramètres du kernel pour modifier la gestion AES du cpu ? Vous voyez une autre piste ? BJ> Si c'est bien ce à quoi je pense, il faudrait que des gens qui BJ> ne comprennent pas les implications de leurs patches arrêtent de l es BJ> imposer... Sur la suppression de certains ciphers d'openssl, c'est un choix délib éré je suppose, interdire les connexions qui paraissent sécurisées ma is ne le sont pas car utilisant des ciphers vulnérables. C'est le choix de firefox & chrome par ex, ils refusent désormais les connexions https vers des sites qui ne font pas de TLS ou utilisent des ciphers trop faibles. -- Daniel Le philosophe cherche des solutions aux problèmes et ne trouve que des problèmes sans solutions. Sim
BERTRAND Jo=c3=abl
Daniel Caillibaud a écrit :
Le 11/04/18 à 09:34, BERTRAND Joël a écrit : […] BJ> > - ça fonctionne bien depuis mon portable, qui est aussi sous stretch, BJ> > avec le même ssh/openssl/clé ssh (et la même connexion, j'ai même été BJ> > jusqu'à lui coller même mac, en utilisant le même cable RJ45 sur le BJ> > même port de la même box) BJ> > BJ> > => le pb vient donc de la gestion du réseau par mon desktop vs BJ> > laptop. Vu que les deux ont la même debian, reste BJ> > - le driver de la carte réseau, et je comprends vraiment pas comment BJ> > ça peut influer sur des échanges chiffrés (à priori lui n'agit que BJ> > sur la couche réseau, pas applicative). BJ> > - le (dé)chiffrement AES par le cpu BJ> > BJ> > Y'a moyen de changer des paramètres du kernel pour modifier la BJ> > gestion AES du cpu ? BJ> > BJ> > Vous voyez une autre piste ? BJ> BJ> Je sèche. Je n'ai pas quoi ouvrir les fichiers là, tout de BJ> suite. Mais si ce n'est pas une histoire de chiffrement, ça peut BJ> ressembler à une histoire de chemin. Ça pourrait, mais ici ip route me donne la même chose depuis desktop et laptop, ça passe par la même box donc les mêmes routes (j'ai vérifié avec un traceroute).
Je pensais à un truc plus tordu dans les options du noyau (les rp_filter et consorts). <snip>
Ça je suis d'accord, si on élimine des cipher dans openssl, faut aussi virer leur usage dans les paquets qui l'utilisent (mais y'en a bcp), et ça ne devrait se faire que d'une debian à la suivante (mais ça je suppose que c'était le cas). Mais à priori tous les outils qui utilisent openssl commencent par lui demander quels sont les ciphers dispos, donc ça devrait pas poser pb. Mais dans ton cas, ton sendmail devait utiliser les cipher mis à dispo par openssl, ce sont les smtp en face qui devaient pas savoir les gérer.
Et c'est bien le cas. Le fait de virer chez Debian des ciphers arbitrairement fait qu'on peut avoir de sérieux effets de bord avec les serveurs distants. JKB
Daniel Caillibaud a écrit :
Le 11/04/18 à 09:34, BERTRAND Joël <joel.bertrand@systella.fr> a écrit :
[…]
BJ> > - ça fonctionne bien depuis mon portable, qui est aussi sous stretch,
BJ> > avec le même ssh/openssl/clé ssh (et la même connexion, j'ai même été
BJ> > jusqu'à lui coller même mac, en utilisant le même cable RJ45 sur le
BJ> > même port de la même box)
BJ> >
BJ> > => le pb vient donc de la gestion du réseau par mon desktop vs
BJ> > laptop. Vu que les deux ont la même debian, reste
BJ> > - le driver de la carte réseau, et je comprends vraiment pas comment
BJ> > ça peut influer sur des échanges chiffrés (à priori lui n'agit que
BJ> > sur la couche réseau, pas applicative).
BJ> > - le (dé)chiffrement AES par le cpu
BJ> >
BJ> > Y'a moyen de changer des paramètres du kernel pour modifier la
BJ> > gestion AES du cpu ?
BJ> >
BJ> > Vous voyez une autre piste ?
BJ>
BJ> Je sèche. Je n'ai pas quoi ouvrir les fichiers là, tout de
BJ> suite. Mais si ce n'est pas une histoire de chiffrement, ça peut
BJ> ressembler à une histoire de chemin.
Ça pourrait, mais ici ip route me donne la même chose depuis desktop et
laptop, ça passe par la même box donc les mêmes routes (j'ai vérifié avec
un traceroute).
Je pensais à un truc plus tordu dans les options du noyau (les
rp_filter et consorts).
<snip>
Ça je suis d'accord, si on élimine des cipher dans openssl, faut aussi
virer leur usage dans les paquets qui l'utilisent (mais y'en a bcp), et ça
ne devrait se faire que d'une debian à la suivante (mais ça je suppose que
c'était le cas).
Mais à priori tous les outils qui utilisent openssl commencent par lui
demander quels sont les ciphers dispos, donc ça devrait pas poser pb.
Mais dans ton cas, ton sendmail devait utiliser les cipher mis à dispo par
openssl, ce sont les smtp en face qui devaient pas savoir les gérer.
Et c'est bien le cas. Le fait de virer chez Debian des ciphers
arbitrairement fait qu'on peut avoir de sérieux effets de bord avec les
serveurs distants.
Le 11/04/18 à 09:34, BERTRAND Joël a écrit : […] BJ> > - ça fonctionne bien depuis mon portable, qui est aussi sous stretch, BJ> > avec le même ssh/openssl/clé ssh (et la même connexion, j'ai même été BJ> > jusqu'à lui coller même mac, en utilisant le même cable RJ45 sur le BJ> > même port de la même box) BJ> > BJ> > => le pb vient donc de la gestion du réseau par mon desktop vs BJ> > laptop. Vu que les deux ont la même debian, reste BJ> > - le driver de la carte réseau, et je comprends vraiment pas comment BJ> > ça peut influer sur des échanges chiffrés (à priori lui n'agit que BJ> > sur la couche réseau, pas applicative). BJ> > - le (dé)chiffrement AES par le cpu BJ> > BJ> > Y'a moyen de changer des paramètres du kernel pour modifier la BJ> > gestion AES du cpu ? BJ> > BJ> > Vous voyez une autre piste ? BJ> BJ> Je sèche. Je n'ai pas quoi ouvrir les fichiers là, tout de BJ> suite. Mais si ce n'est pas une histoire de chiffrement, ça peut BJ> ressembler à une histoire de chemin. Ça pourrait, mais ici ip route me donne la même chose depuis desktop et laptop, ça passe par la même box donc les mêmes routes (j'ai vérifié avec un traceroute).
Je pensais à un truc plus tordu dans les options du noyau (les rp_filter et consorts). <snip>
Ça je suis d'accord, si on élimine des cipher dans openssl, faut aussi virer leur usage dans les paquets qui l'utilisent (mais y'en a bcp), et ça ne devrait se faire que d'une debian à la suivante (mais ça je suppose que c'était le cas). Mais à priori tous les outils qui utilisent openssl commencent par lui demander quels sont les ciphers dispos, donc ça devrait pas poser pb. Mais dans ton cas, ton sendmail devait utiliser les cipher mis à dispo par openssl, ce sont les smtp en face qui devaient pas savoir les gérer.
Et c'est bien le cas. Le fait de virer chez Debian des ciphers arbitrairement fait qu'on peut avoir de sérieux effets de bord avec les serveurs distants. JKB
Daniel Caillibaud
Le 11/04/18 à 15:01, BERTRAND Joël a écrit : BJ> Je pensais à un truc plus tordu dans les options du noyau (les BJ> rp_filter et consorts). Ça pourrait être de ce coté là, mais réinstaller u ne stretch from scratch en laissant tout par défaut aurait dû régler le pb non ? Comment je peux lister les valeurs de ces différentes options (pour les comparer avec la machine qui fonctionne) ? J'ai regardé un diff sur la sortie de `sysctl -a` des deux machines, e t je vois rien qui différe sur les clés net.* (sur les autres, qq diff érences légères sur ce qui touche à la ram ou au limites de fs, ou l es kernel.sched_domain.cpuX.domainY) la seule différence des clés net.* est net.ipv4.tcp_mem = 93225 124300 186450 vs net.ipv4.tcp_mem = 94365 125823 188730 (net.ipv4.conf.enp2s0 est rigoureusement identique au net.ipv4.conf.eth0 de l'autre) Donc je vois toujours pas… -- Daniel L'avenir est un lieu commode pour y mettre des songes. Anatole France
Le 11/04/18 à 15:01, BERTRAND Joël <joel.bertrand@systella.fr> a écrit :
BJ> Je pensais à un truc plus tordu dans les options du noyau (les
BJ> rp_filter et consorts).
Ça pourrait être de ce coté là, mais réinstaller u ne stretch from scratch
en laissant tout par défaut aurait dû régler le pb non ?
Comment je peux lister les valeurs de ces différentes options (pour les
comparer avec la machine qui fonctionne) ?
J'ai regardé un diff sur la sortie de `sysctl -a` des deux machines, e t je
vois rien qui différe sur les clés net.* (sur les autres, qq diff érences
légères sur ce qui touche à la ram ou au limites de fs, ou l es
kernel.sched_domain.cpuX.domainY)
la seule différence des clés net.* est
net.ipv4.tcp_mem = 93225 124300 186450
vs
net.ipv4.tcp_mem = 94365 125823 188730
(net.ipv4.conf.enp2s0 est rigoureusement identique au net.ipv4.conf.eth0 de
l'autre)
Donc je vois toujours pas…
--
Daniel
L'avenir est un lieu commode pour y mettre des songes.
Anatole France
Le 11/04/18 à 15:01, BERTRAND Joël a écrit : BJ> Je pensais à un truc plus tordu dans les options du noyau (les BJ> rp_filter et consorts). Ça pourrait être de ce coté là, mais réinstaller u ne stretch from scratch en laissant tout par défaut aurait dû régler le pb non ? Comment je peux lister les valeurs de ces différentes options (pour les comparer avec la machine qui fonctionne) ? J'ai regardé un diff sur la sortie de `sysctl -a` des deux machines, e t je vois rien qui différe sur les clés net.* (sur les autres, qq diff érences légères sur ce qui touche à la ram ou au limites de fs, ou l es kernel.sched_domain.cpuX.domainY) la seule différence des clés net.* est net.ipv4.tcp_mem = 93225 124300 186450 vs net.ipv4.tcp_mem = 94365 125823 188730 (net.ipv4.conf.enp2s0 est rigoureusement identique au net.ipv4.conf.eth0 de l'autre) Donc je vois toujours pas… -- Daniel L'avenir est un lieu commode pour y mettre des songes. Anatole France
Daniel Caillibaud
Le 11/04/18 à 21:11, Daniel Caillibaud a écr it : DC> Donc je vois toujours pas… Changer la carte réseau a réglé le souci. Le pb se posait avec l'interface Gbps intégrée à la carte m ère. Une vieille carte 10/100 qui était branchée mais ne servait plus depuis longt emps n'avait pas donné de meilleur résultat (et elle n'était plus reconnue depuis ma réinstall), son clone rigoureusement du même modèl e (SMC 1211) règle le pb ! Je comprends toujours pas pourquoi un pb hardware sur une carte réseau peut donner ces symptômes, tout marche sauf sur un host, et pas tout le tem ps (en https avec le browser, j'arrivais à me logguer en insistant, mais seulement avec chromium, quasi jamais avec firefox), et pas avec tous les dépôts (avec certains ça marchait en forçant le cipher, pas d'autres). Je suppose que ça dépend de la taille des paquets tcp, ou un truc du genre, mais j'y ai laissé qq touffes de cheveux… -- Daniel Méfie-toi des proverbes chinois Proverbe berrichon
Le 11/04/18 à 21:11, Daniel Caillibaud <ml@lairdutemps.org> a écr it :
DC> Donc je vois toujours pas…
Changer la carte réseau a réglé le souci.
Le pb se posait avec l'interface Gbps intégrée à la carte m ère. Une vieille
carte 10/100 qui était branchée mais ne servait plus depuis longt emps
n'avait pas donné de meilleur résultat (et elle n'était plus reconnue
depuis ma réinstall), son clone rigoureusement du même modèl e (SMC 1211)
règle le pb !
Je comprends toujours pas pourquoi un pb hardware sur une carte réseau peut
donner ces symptômes, tout marche sauf sur un host, et pas tout le tem ps
(en https avec le browser, j'arrivais à me logguer en insistant, mais
seulement avec chromium, quasi jamais avec firefox), et pas avec tous les
dépôts (avec certains ça marchait en forçant le cipher, pas d'autres).
Je suppose que ça dépend de la taille des paquets tcp, ou un truc du genre,
mais j'y ai laissé qq touffes de cheveux…
--
Daniel
Méfie-toi des proverbes chinois
Proverbe berrichon
Le 11/04/18 à 21:11, Daniel Caillibaud a écr it : DC> Donc je vois toujours pas… Changer la carte réseau a réglé le souci. Le pb se posait avec l'interface Gbps intégrée à la carte m ère. Une vieille carte 10/100 qui était branchée mais ne servait plus depuis longt emps n'avait pas donné de meilleur résultat (et elle n'était plus reconnue depuis ma réinstall), son clone rigoureusement du même modèl e (SMC 1211) règle le pb ! Je comprends toujours pas pourquoi un pb hardware sur une carte réseau peut donner ces symptômes, tout marche sauf sur un host, et pas tout le tem ps (en https avec le browser, j'arrivais à me logguer en insistant, mais seulement avec chromium, quasi jamais avec firefox), et pas avec tous les dépôts (avec certains ça marchait en forçant le cipher, pas d'autres). Je suppose que ça dépend de la taille des paquets tcp, ou un truc du genre, mais j'y ai laissé qq touffes de cheveux… -- Daniel Méfie-toi des proverbes chinois Proverbe berrichon
