Re: Plantage bizarre

[BERTRAND Joël]

Daniel Caillibaud a écrit :
> 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 IPv6 et
> BJ> c'est au soft de faire le tri dans les réponses. Mais encore une fois,
> 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 , 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 avec les
> BJ> options -v et -e.
> 
> Avec git on ne peut pas activer -e

Je pensais à un tcpdump bien senti.

> 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 (à condition d'imposer
> le cipher) (2)

Rhohh... Idée ! J'ai eu un truc similaire avec les concetés
debianesques. Il y a des chiffrements qui ont disparu de certaines
versions récentes d'OpenSSL qui m'empêchaient d'envoyer des mails à
certains (gros) domaines. Il m'a fallu patcher sendmail pour contourner
le problème !...

Peux-tu compiler un OpenSSL officiel (non patché par Debian) ?

Si c'est bien ce à quoi je pense, il faudrait que des gens qui ne
comprennent pas les implications de leurs patches arrêtent de les imposer...

JKB

Re: Plantage bizarre

[Daniel Caillibaud]

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 IPv6 et
BJ> c'est au soft de faire le tri dans les réponses. Mais encore une fois,
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 , 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 avec 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 (à condition d'imposer
le cipher) (2)

Pour info, je viens de réinstaller une stretch toute fraîche, pensant 
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 restes 
qui remontent à etch, et j'avais déjà eu des pbs d'hibernation 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-sha...@libssh.org
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compression: 
none
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compression: 
none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa 
SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8
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: dan...@lairdutemps.org
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: daniel.caillib...@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 aes

OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l  25 May 2017
debug1: Reading configuration data 

GRUB : listes de blocs, erreur

[andre_debian]

Bonjour,

# grub-install /dev/sda1
me donne ce long message :

"Le système de fichiers NTFS ne prend ps en charge l'empaquetage.
Grub ne doit pas être installé sur cette configuration qu'en utilisant la 
liste de blocs, qui ne sont pas FIABLES donc déconseillées.
Erreur, refus de continuer avec les listes de blocs"

Pourtant, en rebootant, Grub fonctionne,
sauf le menu de boot en caractères ultra petits.

Mon système est Debian Jessie, avec une partition Windows (sda1)
et d'autres partitions de sauvegarde GNU/Linux (sda3, sda4...).

Cette erreur de grub est survenue après un "apt-get upgrade" de Jessie.

Merci,

André

Re: Plantage bizarre

[BERTRAND Joël]

Daniel Caillibaud a écrit :
> Le 10/04/18 à 10:47, BERTRAND Joël  a écrit :
> 
> BJ> Daniel Caillibaud a écrit :
> BJ> > Le 09/04/18 à 19:45, BERTRAND Joël  a
> BJ> > écrit :  
> BJ> > BJ> En d'autres termes, est-ce que le problème persiste en
> BJ> > BJ> désactivant IPv6 sur le poste en question ?  
> BJ> > 
> BJ> > Oui, pour éliminer ça dès le début tous les tests sont en ipv4, j'ai
> BJ> > désactivé l'ipv6 sur l'interface et je fais les tests en passant -4 à
> BJ> > ssh.  
> BJ> 
> BJ>   Même pour la résolution de nom ? Que renvoie un 'host' sur le
> BJ> domaine fautif ? J'ai déjà eu des cas bizarres où le resolver
> BJ> renvoyaient une réponse  sur une machine sans IPv6.
> 
> Oui, mais là dans les traces tcp on voit que la connexion est ouverte puis
> coupée en cours de route.
> 
> Par ailleurs, j'ai un unbound local pour la résolution (j'utilise le dhcp
> pour assigner l'ip uniquement), et le pb se pose sur du `ssh -4`.

Je ne sais pas sur quoi agit l'option -4 (hormis le fait s'utiliser
IPv4 pour la connexion). Mais je puis t'assurer que même interrogés en
IPv4, certains DNS renvoient des résolutions IPv6 et c'est au soft de
faire le tri dans les réponses. Mais encore une fois, je ne sais pas si
ssh est assez subtil pour cela.

Peux-tu poster ici un dump réseau complet de quelque chose qui
fonctionne et d'une transaction qui échoue ? Par complet, c'est avec les
options -v et -e.

Bien cordialement,

JKB

Re: Plantage bizarre

[Daniel Caillibaud]

Le 10/04/18 à 09:05, Eric Degenetais  a écrit :

ED> Le 10 avril 2018 à 08:47, BERTRAND Joël  a
ED> écrit :
ED> > Même pour la résolution de nom ?

ED> Surtout lié à un changement de FAI... j'ai désactivé IPV6 sur mes
ED> systèmes linux pendant plusieurs années parce que ma f... box ne gérait
ED> pas correctement le protocole de transition IPV4/IPV6, donc si pas de
ED> bol la réponse de la requête IPV6 arrivait en premier je me prenais le
ED> mur. Ça a pu s'améliorer ... ou pas en fonction des FAI.

C'est effectivement une piste plausible, mais avec avec du ssh -4 y'a
vraiment aucune raison que ssh utilise de l'ipv6, ou alors un truc
m'échappe (et même si l'appel dns n'était pas restreint à v4, ssh ne se
connecterait pas et le message serait différent).

Et dans mes traces tcpdump, je ne vois que l'ipv4, mais c'est vrai que ça
prouve rien vu que je filtre le snif sur l'ipv4 du host qui m'intéresse…

J'ai désactivé l'ipv6 dans network-manager, mais c'est vrai qu'un ifconfig
continuait de me donner une mac et une adresse ipv6.

Par acquis de conscience, j'ai donc re-testé après

sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.all.autoconf=0
sysctl -w net.ipv6.conf.default.disable_ipv6=1
sysctl -w net.ipv6.conf.default.autoconf=0

et avoir vérifié qu'un ifconfig ne donnait plus de trace d'ipv6 => c'est
pareil.

-- 
Daniel

Je pense qu'il y a sur le marché mondial place pour environ 
cinq ordinateurs. Président du Board of IBM (1943)

Re: Plantage bizarre

[Daniel Caillibaud]

Le 10/04/18 à 10:47, BERTRAND Joël  a écrit :

BJ> Daniel Caillibaud a écrit :
BJ> > Le 09/04/18 à 19:45, BERTRAND Joël  a
BJ> > écrit :  
BJ> > BJ>   En d'autres termes, est-ce que le problème persiste en
BJ> > BJ> désactivant IPv6 sur le poste en question ?  
BJ> > 
BJ> > Oui, pour éliminer ça dès le début tous les tests sont en ipv4, j'ai
BJ> > désactivé l'ipv6 sur l'interface et je fais les tests en passant -4 à
BJ> > ssh.  
BJ> 
BJ> Même pour la résolution de nom ? Que renvoie un 'host' sur le
BJ> domaine fautif ? J'ai déjà eu des cas bizarres où le resolver
BJ> renvoyaient une réponse  sur une machine sans IPv6.

Oui, mais là dans les traces tcp on voit que la connexion est ouverte puis
coupée en cours de route.

Par ailleurs, j'ai un unbound local pour la résolution (j'utilise le dhcp
pour assigner l'ip uniquement), et le pb se pose sur du `ssh -4`.

(mais merci pour la remarque, je tâcherai de m'en souvenir pour commencer
par regarder ça si un truc qui ressemble se produit).

-- 
Daniel

Il vaut mieux être saoul que con, ça dure moins longtemps.
Dicton Breton

Re: Plantage bizarre

[Eric Degenetais]

Le 10 avril 2018 à 08:47, BERTRAND Joël  a écrit
:
> Même pour la résolution de nom ?
Surtout lié à un changement de FAI... j'ai désactivé IPV6 sur mes systèmes
linux pendant plusieurs années parce que ma f... box ne gérait pas
correctement le protocole de transition IPV4/IPV6, donc si pas de bol la
réponse de la requête IPV6 arrivait en premier je me prenais le mur.
Ça a pu s'améliorer ... ou pas en fonction des FAI.
__
Éric Dégenètais

Re: Plantage bizarre

[BERTRAND Joël]

Daniel Caillibaud a écrit :
> Le 09/04/18 à 19:45, BERTRAND Joël  a écrit :
> BJ>   En d'autres termes, est-ce que le problème persiste en
> BJ> désactivant IPv6 sur le poste en question ?
> 
> Oui, pour éliminer ça dès le début tous les tests sont en ipv4, j'ai
> désactivé l'ipv6 sur l'interface et je fais les tests en passant -4 à ssh.

Même pour la résolution de nom ? Que renvoie un 'host' sur le domaine
fautif ? J'ai déjà eu des cas bizarres où le resolver renvoyaient une
réponse  sur une machine sans IPv6.

Bien cordialement,

JKB

Re: Plantage bizarre

[Daniel Caillibaud]

Le 09/04/18 à 19:45, BERTRAND Joël  a écrit :
BJ> En d'autres termes, est-ce que le problème persiste en
BJ> désactivant IPv6 sur le poste en question ?

Oui, pour éliminer ça dès le début tous les tests sont en ipv4, j'ai
désactivé l'ipv6 sur l'interface et je fais les tests en passant -4 à ssh.

-- 
Daniel

Dans la vie il faut faire ce que l'on aime. 
Ce n'est pas une garantie de réussite, mais au moins,
c'est une garantie de non-frustration.
Willy Rozenbaum