Fedora-Fr

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Connexion lente sur un serveur par SSH

Number

Bonjour à tous,

Je viens d'en parler sur le channel irc #fedora-fr mais vu le calme ce matin pas eu de solution, je poste donc sur le forum ça sera plus clair.

Je tente de me connecter sur mon serveur ssh à distance, mais le problème existe aussi en local (exit le problème réseau ? )

Voici les informations :

Connexion via clef rsa :

- 58:00 : J'ai rentré mon utilisateur "number"
- 58:01 : Affichage de Authenticating with public key "imported-openssh-key"
- 58:10 : J'ai une trace de la connexion dans /var/log/secure : sshd[2099]: Accepted publickey for number from ***.***.***.*** port 58931 ssh2
- 58:15 : Autre trace dans les log : sshd[2099]: pam_unix(sshd:session): session opened for user number by (uid=0)
- 58:27 : J'obtient un shell dans putty sous windows ..

Connexion avec un autre utilisateur via user/pwd :

- 59:00 : J'ai rentré mon utilisateur "test"
- 59:05 : J'ai rentré mon password
- 59:19 : Affichage de Authenticating with public key "imported-openssh-key"
- 59:25 : J'ai une trace de la connexion dans /var/log/secure : sshd[2099]: Accepted publickey for number from ***.***.***.*** port 58931 ssh2
- 59:36 : Autre trace dans les log : sshd[2099]: pam_unix(sshd:session): session opened for user number by (uid=0)

Ma connexion prend donc 36 secondes avant d'avoir un shell et 27 via clef..
Le temps d'attente entre le moment ou j'ai donné les informations ( User si connexion par clef, user/pwd si connexion classique) dépasse les 27 secondes à chaque tentative.

Voiçi la config dans /etc/sshd_config :

Protocol 2
SyslogFacility AUTHPRIV
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication yes
ChallengeResponseAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
UsePAM yes
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
X11Forwarding yes
Subsystem       sftp    /usr/libexec/openssh/sftp-server

Et les informations sur les temps dé réponse :

[nummber@soez ~]$ ping client
PING client 56(84) bytes of data.
64 bytes from client: icmp_seq=1 ttl=246 time=44.0 ms
64 bytes from client: icmp_seq=2 ttl=246 time=41.8 ms

[nummber@soez ~]$ ping server
PING server 56(84) bytes of data.
64 bytes from client: icmp_seq=1 ttl=246 time=40.6 ms
64 bytes from client: icmp_seq=1 ttl=246 time=44.8 ms
64 bytes from client: icmp_seq=1 ttl=246 time=45.5 ms

time host client
client.in-addr.arpa domain name pointer client

real    0m0.108s
user    0m0.006s
sys     0m0.004s

time host server
server.in-addr.arpa domain name pointer server

real    0m0.364s
user    0m0.014s
sys     0m0.089s

Et pour finir le serveur va très bien :

top - 14:11:46 up 11 days, 20:13,  1 user,  load average: 0.07, 0.05, 0.02
Tasks: 136 total,   2 running, 134 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.3%us,  0.7%sy,  0.0%ni, 97.7%id,  1.0%wa,  0.3%hi,  0.0%si,  0.0%st
Mem:   1035120k total,   998464k used,    36656k free,    66240k buffers
Swap:  2096472k total,      416k used,  2096056k free,   427620k cached

Il me semble que c'était bien plus rapide avant (il y'a quelque mois)

Une idée ?

Merci à vous

bioinfornatics

et si tu compresse les données de ssh cf l'option une différence?

Number

bioinfornatics wrote:et si tu compresse les données de ssh cf l'option une différence?

Après quelque test , même résultat de latence..

Number

Toujours pas trouvé de solution, des idées ?

Number

Désolé pour la longueur du message, ne sachant pas ce qui peut poser problème j'ai mis l'entièreté du log, j'éditerai ensuite pour réduire

Merci à toi Heldwin pour ta réponse, malheureusement Je ne trouve rien 🙁
Je ne vois pas d'erreur précise :

OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to soez.be [81.247.39.194] port 22.
debug1: Connection established.
debug1: identity file /home/builder/.ssh/identity type -1
debug1: identity file /home/builder/.ssh/id_rsa type -1
debug1: identity file /home/builder/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 134/256
debug2: bits set: 516/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/builder/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /home/builder/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 16
debug1: Host 'soez.be' is known and matches the RSA host key.
debug1: Found key in /home/builder/.ssh/known_hosts:1
debug2: bits set: 527/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/builder/.ssh/identity ((nil))
debug2: key: /home/builder/.ssh/id_rsa ((nil))
debug2: key: /home/builder/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/builder/.ssh/identity
debug3: no such identity: /home/builder/.ssh/identity
debug1: Trying private key: /home/builder/.ssh/id_rsa
debug3: no such identity: /home/builder/.ssh/id_rsa
debug1: Trying private key: /home/builder/.ssh/id_dsa
debug3: no such identity: /home/builder/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
debug3: packet_send2: adding 64 (len 58 padlen 6 extra_pad 64)
debug2: we sent a password packet, wait for reply

Une attente de ~ 10 secondes avant ke prochain message.

debug1: Authentication succeeded (password).
debug2: fd 5 setting O_NONBLOCK
debug3: fd 6 is O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.

Une attente de ~ 15 secondes avant ke prochain message.

debug2: callback start
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug3: Ignored env HOSTNAME
debug3: Ignored env TERM
debug3: Ignored env SHELL
debug3: Ignored env HISTSIZE
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
debug3: Ignored env MAIL
debug3: Ignored env PATH
debug3: Ignored env INPUTRC
debug3: Ignored env PWD
debug1: Sending env LANG = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env LESSOPEN
debug3: Ignored env G_BROKEN_FILENAMES
debug3: Ignored env _
debug1: Sending command: 2
debug2: channel 0: request exec confirm 0
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152

Et ensuite, pour terminer 3 secondes avant d'avoir un shell actif.

tobi1canobe

Essaye sans gssapi
ssh -o GSSAPIAuthentication=no monhote
Quand j'ai des soucis dns sur un serveur c'est en general ce truc qui fait ramer l'auth ssh.
Tobias

Number

Heldwin wrote:Il me semble y avoir un problème de clé non ?

Depuis ma machine virtuel je me connecte avec un user/password je n'ai pas de clef donc forcément il fini par utiliser la méthode user/pass.

Par contre, sur ma machine hôte (Vista) j'utilise putty, qui lui utilise une clef. La lenteur est ressentie sur les deux méthodes...

Heldwin wrote:
debug1: Next authentication method: publickey
debug1: Trying private key: /home/builder/.ssh/identity
debug3: no such identity: /home/builder/.ssh/identity
debug1: Trying private key: /home/builder/.ssh/id_rsa
debug3: no such identity: /home/builder/.ssh/id_rsa
debug1: Trying private key: /home/builder/.ssh/id_dsa
debug3: no such identity: /home/builder/.ssh/id_dsa
debug2: we did not send a packet, disable method
C'est pas ça qui crée ce ralentissement ?

Justement, je ne pense pas.

Heldwin wrote:Si tu désactives l'authentification par mot de passe, la connexion échoue ?

Via machine virtuelle oui, via putty non.

Heldwin wrote:
debug1: identity file /home/builder/.ssh/identity type -1
debug1: identity file /home/builder/.ssh/id_rsa type -1
debug1: identity file /home/builder/.ssh/id_dsa type -1
De plus, il me semble que le type -1 pour les identity file signifie fichier manquant.

Ce qui est donc logique.

tobi1canobe wrote:Essaye sans gssapi
ssh -o GSSAPIAuthentication=no monhote
Quand j'ai des soucis dns sur un serveur c'est en general ce truc qui fait ramer l'auth ssh.
Tobias

Désactive dans /etc/sshd_config déjà 🙁
Résultat en utilisant la ligne de commande : 30 secondes d'attente avant le shell..

Merci pour vos idées/piste !

Number

Pas mieux en désactivant l'identification par password, même après un restart du server ! 🙁🙁🙁

Edit :

Je peux créer un compte guest pour que certain puisse ce rendre compte en fournissant par MP user/pass

Number

En activant le debug sur le serveur SSH on voit plus d'information :

Après avoir réglé un problème d'ipv6 , le soucis reste présent (Mince j'étais certain d'avoir trouvé ):

Jan 11 13:12:22 soez sshd[5579]: debug1: Bind to port 22 on ::.
Jan 11 13:12:22 soez sshd[5579]: Server listening on :: port 22.
Jan 11 13:12:22 soez sshd[5579]: debug2: fd 4 setting O_NONBLOCK
Jan 11 13:12:22 soez sshd[5579]: debug1: Bind to port 22 on 0.0.0.0.
Jan 11 13:12:22 soez sshd[5579]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use

Jan 11 13:36:31 soez sshd[3041]: debug3: mm_request_receive_expect entering: type 48
Jan 11 13:36:31 soez sshd[3039]: debug1: do_pam_account: called
Jan 11 13:36:31 soez sshd[3041]: debug3: mm_request_receive entering
Jan 11 13:36:31 soez sshd[2641]: debug2: channel 0: rcvd adjust 11612
Jan 11 13:36:36 soez sshd[3039]: debug3: PAM: do_pam_account pam_acct_mgmt = 0 (Success)
Jan 11 13:36:36 soez sshd[3039]: debug3: mm_request_send entering: type 48
Jan 11 13:36:36 soez sshd[3039]: Accepted publickey for crupuk from 139.165.96.129 port 30993 ssh2
Jan 11 13:36:36 soez sshd[3039]: debug1: monitor_child_preauth: crupuk has been authenticated by privileged process
Jan 11 13:36:36 soez sshd[3039]: debug3: mm_get_keystate: Waiting for new keys
Jan 11 13:36:36 soez sshd[3039]: debug3: mm_request_receive_expect entering: type 25
Jan 11 13:36:36 soez sshd[3039]: debug3: mm_request_receive entering
Jan 11 13:36:36 soez sshd[3041]: debug3: mm_do_pam_account returning 1
Jan 11 13:36:36 soez sshd[3041]: debug3: mm_send_keystate: Sending new keys: 0x873ac78 0x873b158
Jan 11 13:36:36 soez sshd[3041]: debug3: mm_newkeys_to_blob: converting 0x873ac78
Jan 11 13:36:36 soez sshd[3041]: debug3: mm_newkeys_to_blob: converting 0x873b158
Jan 11 13:36:36 soez sshd[3041]: debug3: mm_send_keystate: New keys have been sent
Jan 11 13:36:36 soez sshd[3041]: debug3: mm_send_keystate: Sending compression state
Jan 11 13:36:36 soez sshd[3041]: debug3: mm_request_send entering: type 25
Jan 11 13:36:36 soez sshd[3041]: debug3: mm_send_keystate: Finished sending state
Jan 11 13:36:36 soez sshd[3039]: debug3: mm_newkeys_from_blob: 0x8748388(139)
Jan 11 13:36:36 soez sshd[3039]: debug2: mac_init: found hmac-sha1
Jan 11 13:36:36 soez sshd[3039]: debug3: mm_get_keystate: Waiting for second key
Jan 11 13:36:36 soez sshd[3039]: debug3: mm_newkeys_from_blob: 0x8748388(139)
Jan 11 13:36:36 soez sshd[3039]: debug2: mac_init: found hmac-sha1
Jan 11 13:36:36 soez sshd[3039]: debug3: mm_get_keystate: Getting compression state
Jan 11 13:36:36 soez sshd[3039]: debug3: mm_get_keystate: Getting Network I/O buffers
Jan 11 13:36:36 soez sshd[3039]: debug3: mm_share_sync: Share sync
Jan 11 13:36:36 soez sshd[3039]: debug3: mm_share_sync: Share sync end
Jan 11 13:36:36 soez sshd[3039]: debug1: PAM: establishing credentials
Jan 11 13:36:41 soez sshd[3039]: debug3: PAM: opening session
Jan 11 13:36:41 soez sshd[3039]: pam_unix(sshd:session): session opened for user crupuk by (uid=0)
Jan 11 13:36:46 soez sshd[3086]: debug1: PAM: reinitializing credentials
Jan 11 13:36:46 soez sshd[3039]: debug2: User child is on pid 3086
Jan 11 13:36:46 soez sshd[3039]: debug3: mm_request_receive entering
Jan 11 13:36:51 soez sshd[3086]: debug1: permanently_set_uid: 500/500
Jan 11 13:36:51 soez sshd[3086]: debug2: set_newkeys: mode 0
Jan 11 13:36:51 soez sshd[3086]: debug2: cipher_init: set keylen (16 -> 32)
Jan 11 13:36:51 soez sshd[3086]: debug2: set_newkeys: mode 1
Jan 11 13:36:51 soez sshd[3086]: debug2: cipher_init: set keylen (16 -> 32)
Jan 11 13:36:51 soez sshd[3086]: debug1: Entering interactive session for SSH2.
Jan 11 13:36:51 soez sshd[3086]: debug2: fd 4 setting O_NONBLOCK
Jan 11 13:36:51 soez sshd[3086]: debug2: fd 6 setting O_NONBLOCK
Jan 11 13:36:51 soez sshd[3086]: debug1: server_init_dispatch_20
Jan 11 13:36:51 soez sshd[3086]: debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384
Jan 11 13:36:51 soez sshd[3086]: debug1: input_session_request
Jan 11 13:36:51 soez sshd[3086]: debug1: channel 0: new [server-session]
Jan 11 13:36:51 soez sshd[3086]: debug1: session_new: init
Jan 11 13:36:51 soez sshd[3086]: debug1: session_new: session 0
Jan 11 13:36:51 soez sshd[3086]: debug1: session_open: channel 0
Jan 11 13:36:51 soez sshd[3086]: debug1: session_open: session 0: link with channel 0
Jan 11 13:36:51 soez sshd[3086]: debug1: server_input_channel_open: confirm session
Jan 11 13:36:51 soez sshd[3086]: debug1: server_input_channel_req: channel 0 request pty-req reply 1
Jan 11 13:36:51 soez sshd[3086]: debug1: session_by_channel: session 0 channel 0
Jan 11 13:36:51 soez sshd[3086]: debug1: session_input_channel_req: session 0 req pty-req
Jan 11 13:36:51 soez sshd[3086]: debug1: Allocating pty.
Jan 11 13:36:51 soez sshd[3086]: debug3: mm_request_send entering: type 26
Jan 11 13:36:51 soez sshd[3086]: debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTY
Jan 11 13:36:51 soez sshd[3086]: debug3: mm_request_receive_expect entering: type 27
Jan 11 13:36:51 soez sshd[3039]: debug3: monitor_read: checking request 26
Jan 11 13:36:51 soez sshd[3086]: debug3: mm_request_receive entering
Jan 11 13:36:51 soez sshd[3039]: debug3: mm_answer_pty entering
Jan 11 13:36:51 soez sshd[3039]: debug1: session_new: init
Jan 11 13:36:51 soez sshd[3039]: debug1: session_new: session 0
Jan 11 13:36:52 soez sshd[2641]: debug2: channel 0: rcvd adjust 8641
Jan 11 13:36:56 soez sshd[3039]: debug3: mm_request_send entering: type 27
Jan 11 13:36:56 soez sshd[3039]: debug3: mm_answer_pty: tty /dev/pts/1 ptyfd 4
Jan 11 13:36:56 soez sshd[3039]: debug3: mm_request_receive entering
Jan 11 13:36:56 soez sshd[3086]: debug1: session_pty_req: session 0 alloc /dev/pts/1
Jan 11 13:36:56 soez sshd[3086]: debug3: tty_parse_modes: SSH2 n_bytes 16
Jan 11 13:36:56 soez sshd[3086]: debug3: tty_parse_modes: 3 127
Jan 11 13:36:56 soez sshd[3086]: debug3: tty_parse_modes: ispeed 38400
Jan 11 13:36:56 soez sshd[3086]: debug3: tty_parse_modes: ospeed 38400
Jan 11 13:36:56 soez sshd[3086]: debug1: server_input_channel_req: channel 0 request shell reply 1
Jan 11 13:36:56 soez sshd[3086]: debug1: session_by_channel: session 0 channel 0
Jan 11 13:36:56 soez sshd[3086]: debug1: session_input_channel_req: session 0 req shell
Jan 11 13:36:56 soez sshd[3129]: debug1: Setting controlling tty using TIOCSCTTY.
Jan 11 13:36:56 soez sshd[3129]: debug3: channel 0: close_fds r -1 w -1 e -1 c -1
Jan 11 13:36:56 soez sshd[3086]: debug2: fd 3 setting TCP_NODELAY
Jan 11 13:36:56 soez sshd[3086]: debug2: channel 0: rfd 8 isatty
Jan 11 13:36:56 soez sshd[3086]: debug2: fd 8 setting O_NONBLOCK
Jan 11 13:36:56 soez sshd[3086]: debug3: fd 7 is O_NONBLOCK

On voit que l'on perd beaucoup de temps à :

- 13:36:31 (5 secondes)
- 13:36:36 (5 secondes)
- 13:36:41 (5 secondes)
- 13:36:46 (6 secondes)
- 13:36:52 (4 secondes)

Donc un peu plus de 25 secondes pour se loguer...

Number

J'ai trouvé :-D:-D:-D

Il suffit de changer dans /etc/ssh/sshd_config :

#UseDNS yes

Par

UseDNS no

Bien que décommenté, le UseDNS doit être a yes par défaut..

Maintenant je suis connecté dans la seconde !!

Merci à tous pour votre aide

Number

D'un coté le serveur SSH est en Fedora 12 et maintenant (sans le problème IPV6 est beaucoup plus rapide)

De l'autre coté, le serveur ssh est un CentOs 5.4 et le problème UseDNS venait de CentOs

(Pas frappé, je sais qu'il existe un forum CentOs, mais le problème était présent aussi sur Fedora je pensais que c'était lié, et bien non.. )

Les deux problèmes semble résolu ! ( Fedora & CentOs )